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.
If necessary, over-communicate. Urlocker says that if left alone, developers “assume the worst.” That means that managers should spend about half their time communicating with their teams. Use tools to screen-share or see demos on a regular basis. If possible, teams should have a 15-minute “daily scrum” or other meeting to keep interaction flowing. But don’t require video conferencing, says Urlocker. “It’s always 3 a.m. for somebody.”
Quality is just as important as quantity. Urlocker says that teams should use “military precision communications,” and include all relevant details when talking about an issue. That means bug numbers, customer IDs, helpdesk tickets, whatever is possible to make sure that an issue can be handed off.
Bring Developers Face-to-Face
Just because you have a distributed workforce, it doesn’t mean you should never get together with the team. Face-to-face time is necessary for team-building and it can be good to get teams together for sprints.
But don’t always make it about bringing developers to you. Urlocker says that “you can’t build a global culture from HQ.” Managers need to get on a plane and break bread and drink beer with their turf. That’s not just true of the development team, Urlocker says that product management and marketing should be in the act as well.
Having worked with distributed teams myself (I haven’t really worked in an office since the late 90s), I can attest that this is vital. You work much more effectively with people you’ve met face to face, and you’re much more invested in a company when you feel a bond with co-workers. It’s not necessary to sit in the same cube farm as everybody else to foster this. A few good visits a year with team members can work wonders.
Measuring Distributed Development Team Success
How do you know you’re successful if you don’t have a way to measure it? Another major tip for distributed teams? Metrics. As Urlocker pointed out “what gets measured gets done.” He also encouraged teams to publish metrics for the entire team to see – and yes, that does mean a “wall of shame” for developers who break builds and so on.
Finally, to be successful, you have to go all-in. Don’t assume one culture or one timezone. Make sure that everybody is using the same tool set, and has full access to the same set of tools.
Along the same lines, Nat Friedman has a tip that applies well here: everybody dials in. Level the playing field for people who are remote, and make sure every participant on a conference all dials in. That means that you don’t have four people in a room shouting over a speaker phone. If you want to make remote workers hate life, make them sit through hour-plus meetings where everyone else sounds like they’re at the end of a wind tunnel.
But, most of all, embrace distributed teams rather than being grudging about it. It may not be simple, but it does have a lot of benefits. You can recruit globally. You can save on rent. You might save money on salary, but you’ll certainly have an easier time recruiting senior developers and the best talent if you don’t restrict your search to people living in (or willing to live in) a single area.
