
Ask HN: Has anyone had any success with distributed development teams? - skyisblue
What are your tips for a effective distributed development team?
======
malux85
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.

~~~
partisan
I ran a distributed team for the better part of three years. I think all of
this advice is right on the mark.

The one thing I would say is that everyone worked the clients hours, for the
most part, with at least a 4 hour overlap. That meant that I would often find
myself checking and answering chat messages around the clock because a single
question could easily lead to a 24 hour delay. I would do my best to clear
whatever roadblocks came up as soon as they did to avoid this. I also think we
all became better at thinking through the work we had scheduled since it meant
we would identify the issues upfront when possible.

The last bit about having fun was the most rewarding for me. I made a few good
friends and we spent a lot of time laughing over Skype as we faced down the
pressures of software delivery.

~~~
twunde
I ran a semi-distributed team. 4 hours seems to be the sweet spot. Once you
start moving to 5 hours, it's just a little too far to do easily and some
things start being dropped. One thing I found helpful was to have flexible
hours as well. When I was 4 hours away, I would start work at 10 or 11 local
time (or 6am client hours).

------
justaguyhere
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...

------
nikhildaga
Our team at Idea To Startup
([https://ideatostartup.org/](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

------
jotato
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

------
pasbesoin
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.

------
vlaak
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.

~~~
jackgolding
We have our IM/BA with our devs overseas while our product team (product write
cards) and business are onshore. Was pretty rough to begin but I think we have
figured it out.

I HATE conference calls but daily standup infront of a cisco screen between 2
teams is pretty good.

------
psyc
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.

------
segmondy
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.

------
armagon
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
:-)

