Being Successful as a Distributed Team

Campfire, IRC, IM, Skype and active chat email lists are all great for feeling connected to people, but the first time I really felt part of the company itself - not just a remote node on a graph - was when I covered an event and hung out/coordinated with a load of other bloggers doing so. It really instilled a sense of camaraderie - it was a very high pressure task and it was great that we had been working together virtually for so long (and that some of the others had worked together in person before too), as that avoided some of the uncomfortable situations that can occur if a group of strangers tries to achieve something in a short space of time.

Obviously this only really worked for the blogging/journalis model, but sending a group of devs to an engineering conference, having a team retreat (we also did this but as I was in the UK, I never got to go) and generally finding excuses to hang out productively a couple times a year really makes a big difference to the team feeling, in my experience. It might be slightly different if you're writing code, not articles; mind you, at least if you end up disliking your cow-orkers in person, you don't have to spend that much time with them!

I wish there was a job board that highlighted companies that use distributed teams and are looking to draw talent without requiring re-location.

If you are working on the kind of project that needs to ramp quickly, then the whole project should try to adhere to agile practices. Agile practices have 2 main hopes:

1.) to allow a fast-forming team to quickly become highly-productive.

2.) to control costs by ensuring discipline in regards to goals and deadlines.

I use the word “hopes” instead of “goals” because the ultimate aim of agile practices is more of an ideal to be aspired to rather than a reality that can be achieved, and by that, all I mean is that we are constantly learning more about what these practices mean, and in the future we can reasonably hope to do better than we are doing today.

Programming is an art, and art needs passion. Many agile practices are aimed at soliciting a greater emotional commitment from the programmers. I might write “For an agile project to go well, the programmers need to emotionally commit to it” but that isn’t quite right. What would be more correct would be “For an agile project to go well, the programmers need to emotionally commit to their own professional ideal.” That is, they need to care about the craft of programming. They need to be constantly pushing themselves to always be better programmers.

I would never argue that agile practices are needed on every project. If a project is routine, then long-distance, non-agile practices might be perfect. For instance, suppose you decide to launch a new online magazine. After researching your options, you decide you will use WordPress as the software that powers your site. I’d suggest you find a good designer, local to you, and work with them to come up with the design. Once you have the design, the rest of the process is mundane. You could certainly hire a team in India to install WordPress and implement your design for you. And you would not need agile practices for such a project. In fact, you do not even need great programmers for such a task. Mediocre programmers can do a reasonable job with tasks that are standard, routine and mundane.

However, I would argue that agile practices are needed at projects that need to be fast moving (this would include most start-ups), or at any project where the aim is to create something altogether new and unique. If your project is venturing out into the great unknown, if you are going where no one has ever gone before, you will need a team of excellent, committed adventurers to go along with you.

Many agile practices depend on physical proximity. The programmers need to be able to meet, preferably every day (”every day” in the sense of casual conversation, not “every day” in the sense of “let’s have a formal meeting”). Consider some of these practices:

1.) pair programming (two people looking at the same screen, checking for errors)

2.) the use of index cards to map objects

3.) stand up meetings (meetings kept short and lively because everyone is standing)

None of these make any sense if the programmers are in different countries (or different parts of one country).

Again, for routine work, I think a distributed team can be fine. But for a startup, I would always insist that the team be in physical proximity.

On the "People management" I think that the key thing is finding the right people. I manage our software development team and there is a big difference to being in the same room, or the same building, which I have done at previous startups, with several of the same team members.

You have to trust people and you have to allow them to do the job. I have always tried to hire people I trust to do the job, but when they are anything from one to nine time zones away there is no conceivable way I could "monitor" them and make sure they do their work. If I tried to suggest something like Webspy (as suggested in the article) to "check up on them" I would be first in line to kick myself out of the room. It is all results based. Did you get what you expected at the end of the day/week?

There are certainly drawbacks with not being in the same room. How I would love to be able to round em all up more often and have a whiteboard session (not sure they want that too though... :)). But on the other hand you get very independent and self propelled colleagues instead.

We try to have a group get together every 6 months, but it isn't always feasible, but you really notice the increase in "bandwidth" when everyone is in the same room for a couple of days to a week.

Would I want all of my team in the same town? You bet. Could I have assembled my team or one like it in the same town? With great difficulty. So, overall, we are better of with a distributed team, as the alternative would be to have no team. But it isn't always super easy.