Ask HN: Has anyone had any success with distributed development teams?

My team (me + 3 others) are distributed around the world, everyone is in a different time zone, and most are opposite me.

A few simple rules makes it work:

Only hire “self starters” who you trust to get the job done. This is most important.

Then small operational stuff: Don’t ask to ask. Don’t ask to call. Everyone has Skype open, if you have a question, just call. If you can’t take the call immediately IM back straight away, or call back straight away.

Everything in trello.

Everyone has a “downtime” card in trello. These are tasks that you can go on to if a clients work is waiting on something, or you’re held up. These are kind of like your 20% time things. Can include non-coding activities (swimming, biking, whatever)

I’m gonna push you to grow, that means you get autonomy, mastery and purpose, but I expect excellence in return. Give me the best of you, and in return, I will help you grow and achieve whatever life goals you have.

Have fun! We joke and laugh a lot.

The company I work for, has devs/teams in multiple countries (at least 4 that I know of) and most of us work on the same product. The only people who will find it hard to survive are those who need to be hand held. Personally, I follow "asking for forgiveness is better than permission", except in production and money related activities. If I have an idea to test it, a new library (or design or whatever) to use etc, I rarely ask, I just do it. Once in a while it will be a waste of time, but no one gets upset because I tried something new.

Communicate effectively, be a self starter and above all, organize everything well so people aren't scrambling to find stuff when you are not around. Those would be my tips

Of course, everything in moderation and all that...

Our team at Idea To Startup (https://ideatostartup.org/) is a fully distributed one and we have been running very effectively since last year.

To be effective, we have spent a huge amount of time on hiring the right candidates. (Our acceptance rate is less than 1%). We consider the following factors while deciding the right candidate for a distributed team:

1. Self learner. (Given sufficient time and guidance, you can learn any tech on your own using online resources.)

2. Talented and Hardworking. (Hard work beats talent when talent doesn't work hard. )

3. Responsible. (You take responsibility for all your actions in both success and failure and don't make excuses. )

4. Reliable. (People can rely on you. When given a task, they know you will do it to the best of your abilities)

Hope it helps. -Nikhil

I worked on one for nearly 2 years. We were distributed, but across the same time zone.

Every day for standup we would skype into a standup call. After the meeting we would all leave the call open but put out mics on mute. If I needed someone all I had to do was unmute and say their name.

It gave the benefit of working remote, but being able to communicate like we were working next to each other. It also let us have an "open environment" where I can listen on any conversation but also turn my volume down if it was distracting.

There was also an added benefit that if part of the team was doing a screen share (trying to fix a bug, or go over UX) anyone was able to watch if they were interested.

We two rules and they worked well.

1. If you were going to turn your volume off or leave the call you had to leave a message so the team knew. If someone needed you they could call you directly. 2. Be considerate of chatter. If a conversation or screen share was going to exceed 30 minutes, take it to a private call and leave an open invitation to others. This was so a single conversation couldn't dominate the main call

It was the most effective and performant team I have ever worked on

People who know what they are doing.

Honest communication.

A manager who truly supports both, and who understands the domain thoroughly. And who is willing to -- and politically capable of -- running some interference, when necessary.

100% assignment, or close to it -- a real team. Not 20% this team, 10% that team, and oh help these guys out, but not over 2 hours a week. Yeah, people may get "loaned out" once and a while, for a week or two, maybe even a month. But no steady-state divided loyalty and demands from management.

And even when you're on loan, you know who you belong to. See further, above, re "running interference".

P.S. What I mean in part is, with a seasoned team and good management, this actually facilitates work. People are enabled to solve problems -- including independently. Belonging somewhere, and having effective management, help to keep external BS from gaining too much traction on them. These are people who want to do their job and do it well. And who can think for themselves and make good choices independently, while also communicating them clearly and without feeling -- or feeling the need to be -- overly defensive.

At least, this is what I saw on one of the most effective teams I was assigned to, with several remote members. Physical location didn't matter -- the rest did.

From an enterprise standpoint, I was lead of a team with engineers both in Oregon and Hong Kong. What made us successful was a few key things.

1. We ended up with dedicated BAs and QAs on site in HK so the engineers could get their questions answered in real-time. Those colleagues collaborated with their counterparts in Oregon in the same way the engineers did. I think this was the biggest success factor.

2. We had a daily synch-up video conference at end of day Oregon time, which was beginning of day HK time. This face to face time was great even though most days it was only 5-10 minutes long. It made us feel more like a team and helped morale.

3. The engineers were all self starters (as others have mentioned) meaning they could operate under ambiguity or without direction as needed.

4. I, as lead, managed most of the merging of code (this was before our org used GIT, so we weren't really doing PRs as much as old style, manual code reads).

5. Occasionally, maybe twice a year or so, we'd fly out the HK teams to Oregon to join us for major events (important project meetings, etc...). During those occasions, we'd also hang out after work quite a bit, again to keep up the camaraderie.

Those things worked pretty well for my team.

I'm on a team that's distributed half-way around the world, and everyone is remote. It works fine. None of our problems have had anything to do with remoteness. Everyone just needs to be present and responsive during core hours.

I don't have one yet although I'm slowing transforming my existing team into one.

I'm doing so by.

Communication, communication, communication.

Documentation, documentation, documentation.

I've been working in a company with remote teams for 3 years now.

We try to use Scrum and/or Kanban, and it seems to be reasonably successful. We do struggle constantly with shipping all the features we want introduced in a timely fashion, but I think that is true of all software development.

Here are some pain points, and some partial solutions.

Trying to run meetings over Skype is a pain. It works well enough that you think you are okay, but there are issues. Many times we would start a call, and then need to check who actually made it, and often, hang up and call again so that two more people can join. There was a lot of incidental complexity just getting a meeting together. The chat also gets really cluttered and isn't great for searching.

The best change we made, in my opinion, was switching to Sococo for our meetings. You have a virtual office building, go into a room, summon other people to the room, turn on your microphone (or web cam, or share your screen), and chat. It surprises me how much less friction there is in just talking to someone on the spur of the moment. You just knock on their door, and talk. If you need someone else, you grab them. It is a piece of cake to look and see who is (and is not) in your meeting. We've also got Slack integration working, which helps with recording typed messages and searching them in the future.

(One more nuisance is that are CEOs are often travelling and fail over to Skype when they have poor internet connections. It is a pain.)

Other pain points is that you simply aren't in a room together. Things that would be easy together -- like writing on a whiteboard, or pointing out things on a co-workers screen -- are hard. For just making notes on a whiteboard, and roughing our class diagrams, I like sketchboard.me. For tracking a scrum/kanban board, Youtrack is okay. (I really don't like Jira, and none of the tools I've tried are as simple and flexible as a real whiteboard with cards and swimlanes). Still haven't solved the pairing up issue; we can share screens readily, but typing/pointing/controlling another screen isn't built-in to Sococo, is a little awkward with Zoom.us (because it sends key codes but doesn't compensate for different keyboard layouts), and was okay with, um, TeamViewer.

Being spread around the world is a pain for synchronicity. If you can, get your devs to work core hours together (if they are working in teams, anyways, and not as scattered soloists around the globe). You'll also find that even when you are in the same timezone, different cultures take lunch at different times. (I expect noon in Canada; my coworkers in Mexico want lunch at 2pm). We also try to work on the same days, but you'll find the stat holidays are different; for example, Easter was a week earlier here than in Macedonia, and the mind-numbing start/end times for daylight saving time also differ.

All in all, though, we work together, and ship software, so I think it works :-)