How to Manage a Distributed Development Team
Managing developers is always a challenge, but supervising a distributed development team adds complications and costs. However, with consistency and a little (OK, a lot) of communication, it's a proven approach that can -- among other things -- help you recruit and retain senior developers.
Thu, February 16, 2012
CIO — Despite what you may have heard about distributed development, it's not cheaper, it's much harder, but it's also worth it. That's the message passed on by Zack Urlocker at the Monki Gras conference held in London earler this month. Urlocker's talk, "12 Practical Tips for Managing Distributed Development" combines his experience with the experiences of a number of other managers who work with developers.
Urlocker is currently the COO of Zendesk and formerly executive vice president of products for MySQL. With MySQL and at Zendesk, Urlocker has no small amount of experience with working with distributed development teams. Zendesk, says Urlocker, is staffed with 160 employees and has four offices and two developer centers. MySQL was an "extreme outlier in distributed development" with more than 400 employees in 40 different countries — with 95 percent of developers working from home. The idea was "to hire the best we could, regardless of location."
But how to make that work? A lot of managers have a bias for having employees in the same office. However, you can make better hires and have higher productivity from many developers if they work from home, wherever that may be.
Practical Tips for Managing Distributed Development Teams
One of the first tips, which Urlocker credits to Mark Devisser of Akiban, is that "toolsets define behavior." Companies need to use tools that are "globally accessible" whether a developer is just down the hall or a continent away. It's also vital to use continuous integration tools like Jenkins to ensure that problems are immediately obvious.
He also says that code should be at a "demoable" state at least twice a month. When there are problems with a project, they should be fixed immediately because you can't "catch up" at the end of a development cycle.
Projects should also be distributed from the start. That means using tools like GitHub, Mercurial and other development tools meant for a distributed developer team. Code check-ins need to be well-documented with "brief and to the point" information about new commits.
Communicate, Communicate, But Use Social Media Carefully
Companies do need to be careful of trying to "force fit" social tools. Most of the time, a developer team will naturally gravitate to tools – like IRC — that they prefer. Don't shove Yammer or the 37Signals suite down a team's throat if they're not into using it, but if they're going to use those tools they're probably a worthwhile investment.
Transparency is important even when a team is all in the same location, but when you're dealing with a distributed workforce, it's doubly important. Urlocker cited Steve Wilson for the transparency tip, and says that distributed teams need to spend more time on up-front requirements and written communications. Increased communication is vital when you're working with people remotely.
