Distributed Development Teams

With KC on the road this week, I am encountering the difficulty that more and more Project Managers are running into: a Distributed Development Team. It's every Managers' not-so-secret fear that when the team is seperated by physical distance – and even worse, timezones or cultures – productivity is hurt, communication is weakened, and deadlines can get missed.

There is No Silver Bullet on this one. Sure, as a a boss, I can call my teams every hour. I can email them regularly. I can just tell them to do things. But realistically, does it do anything except annoy them?

I push for a much lighter approach. I make a point of bringing the entire team together – via conference call if I have to – for approximately 15-20 minutes every week and normally longer (1-2 hours) once a month. Each person gets a moment to tell what they're working on, their progress on it, what their priorities are for the next week, and what things are delaying them. At the end, normally a someone pipes up with “oh, I did X. It may be able to help you” and we continue on. By the end of the meeting, people have an idea what's going on, what the focus of the other portions of the team are, and how they can help… or stay out of the way.

Now, back to KC. His fulltime boss has been running him pretty hard with 10+ hour days for the whole week, so he has spent the evenings trying to relax instead of continuing development. Unfortunately this delays our Master Plan(tm), but I believe that the alternative is a unconscious developer putting out crap for code. As an alternative to performing forward development, he has spent a good deal of time hitting our Mantis system logging bugs and comments to bugs for our existing clients. Being away from the core of the system has allowed him to provide some perspective to issues that we had previously overlooked. It's a Forest vs Trees scenario.

In summary, what I'm trying to say is allow your developers to step back from the code once in a while. Make them change their focus to something else for a short period and the new perspective will only deepen their knowledge of the system and allow them to think of and solve problems from a different direction.

This is what we're looking for, right?

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub