Distributed Teams

Andy Singleton is one of my favorite software bloggers.  I believe I've called him out before, but if you missed it then head on over to Assembla.com and check him out.  He doesn't post incredibly often, but when he does he often has very poignant, well-thought out views on the industry.  (As a side note, if you're looking for private Git or Subversion hosting, I've been an Assembla.com customer for several years now and could not be happier with them).

His most recent post concerning the rapid adoption of distributed teams is no different.  I strongly encourage you to read the post for yourself, but for the purposes of this post his general gist is as follows...

1. Distributed teams are not going away
2. They're only getting more common
3. We need to learn how to deal with them rather than pretend it's simply a fad that's going away

As someone who works on a partially distributed team I couldn't agree with Andy more.  Approximately half of our team is based in Chennai, India, and I'm lucky enough to have a standing agreement that I work from home at least one day a week.  In fact, individual members of the rest of our Pittsburgh team often work from home as well, though on a more irregular and occasional basis. 

Distributed teams, often full-time telecommuting positions, were once the type of things geeks only dreamed of.  However, that is changing rapidly.  I attribute at least some of this change to the recent surge in remote out sourcing which taught many managers that although having a geographically and temporally distributed team has it's own set of challenges, that team can also still be an asset to the company.  As the economic downturn continues to gain momentum, I anticipate outsourcing and distributed teams becoming even more attractive to managers looking to cut costs from the company.  This may also be amplified by the recent trend of many companies making an effort to appear more 'green' to the public, and therefore want to cut the carbon emissions of their employee's constant commuting.

We've all heard about the disadvantages of distributed teams.  Tougher communication between team members.  Lessened interaction between team members.  No direct contact between developers and stake holders.  That's all true, and I'm not going to argue any of that.  However, all of those problems are issues that can be fixed, or least mitigated, with simple logistics.  Skype, Yugma, LiveMeeting, or WebEx can all be amazing helps in getting people together virtually.  Heck, even IM and webcams can make a huge a difference.  The point is that all of these problems are easily solvable.

If you'll forgive a slight tangent, I think that most of the backlash of outsourcing arose from the fact that too many companies abused it as a cost-cutting measure.  I hate to be the one to break it to you, but you get what you pay for.  If you're paying 15 to 20 dollars per hour for a software developer, wherever they live, then there's a pretty good chance that you're going to get crap code.  The problem was that way too many US companies tried to view overseas companies as a cheaper alternative to onshore developers while expecting the same quality of work that they received here.  This was exasperated by the rash of overseas companies rushing to to recruit and place unqualified developers to meet this demand.  And before anyone tries to blame this on an 'overseas mentality' I would like to point out the familiar strains between this and what led to the DotCom crash here in the states at the turn of the millennium.  How many 'HTML Programmers' were driving BMWs a decade ago?

The fact is that I've had the pleasure of working with some truly amazing and talented developers from both the US and India.  And I've also had the pleasure of working with some truly horrible ones from both the US and India.  Whether you're an offshore or onshore developer doesn't matter.  I personally feel that at least some of the original fears of outsourcing were slightly nationalistic in nature, and I strongly doubt that if an offshore company was nationally inferior to an onshore company that both Google and Microsoft would not have invested billions of dollars in setting up offshore R&D facilities.  However, I'm willing to bet that a large portion of that money was not spent on brick and mortar facilities, but rather was invested to recruit the best and the brightest to come work with them.  Once again, you get what you pay for folks.

The other side of the coin, that we never seem to hear about, is the advantages that a distributed team has over a co-located team.  That's right, I said advantages. 

How many hours do you spend at work per day?  OK, now how many hours do you actually work during that time.  If your company is like most, an astounding amount of your time is spent every day in meetings.  Not just scheduled formal meetings, but also informal ones.  How many times a day will co-worker drop into your cube to ask you a simple question that they could have solved themselves in 2 minutes on Google?  How many times a day will a co-worker stop on the way back from the coffee room, or the restroom (the un-coffee room) only to regale you with a half-hour discussion of last night's episode of The Office?  Yes, we all think this has been a pretty weak season, but we still want to see what finally happens between Dwight and Angela.

The point is that the workplace is filled with distractions.  I'm all for collaboration, but I also still believe that focus is a developer's most important tool and that he can get much more done when that focus isn't constantly being broken.  As I mentioned before, I regularly work from home each Wednesday.  Glancing over my Subversion logs I can see that I generally have 3 - 4 times the number of commits on Wednesday that I do any other day of the week.  Now I'll be the first to admit that the number of commits aren't everything, I can commit a lot of crap, but I still think it can be a good indicator of velocity.  And velocity is directly proportional to concentration.

The other advantage is talent.  Look around your local developer community.  I'll bet you know some really talented developers.  In fact, I bet that these are people you'd love to have on your team the next time a position opens up, right?  There's only one problem, they're happily married to another job.  Which means that often times you'll have only the--let's call them 'slightly less talented'--masses to choose from.  Why?  Because there's only a fixed number of developers in your area.  Maybe you work for large company who has the resources to recruit nationally, if you do, then more power to you.  But, many of us don't.  Many of us can't afford to fly multitudes of potential candidates in for interviews and then pay to relocate them to beautiful scenic Pittsburgh once they accept the offer.  Many companies simply cannot, or will not, pay to sponsor an international employee to the work in the US.

Now imagine that, instead, you could choose the most talented developers from anywhere in the world.  Imagine that regardless of where you hired someone from, you won't have to pay to relocate them to your stomping grounds.  Imagine hiring an amazingly talented non-US employee, but not having to live in fear of whether or not you and she did the visa dance correctly.

Building a distributed team allows you to choose the best and the brightest from anywhere in the world, without you having to worry about all of the baggage that comes with bringing them from their place in the world to yours.