Richard Florida has written much about the importance of place. I think he’s on to something – despite the hype about virtual communities, social networking and off-shoring, physical geography is as important as it always has been. Although software developers could choose to live in Wyoming and work remotely with their colleagues in Montana, they don’t. They cluster in cities and regions like Silicon Valley, Austin, Boston and Cambridge, UK. Facebook is never going to change that.
Place is important at another level too. Great software is built by great teams. To build a great team, you clearly need great people. But great people aren’t enough. You also need great interactions, and you can’t get those remotely. Getting people to interact is hard enough if they’re sat feet away in different rooms in the same building, let alone thousands of miles away in different continents.
Thomas Allen wrote about this forty years ago, and web 2.0 hasn’t changed it. The likelihood of two people communicating falls off in proportion to the square of the distance separating them. In fact, once two people are sat more than 25 metres apart, there is a vanishingly small chance that they’ll interact. The ‘nuisance factor’ exacerbates this: throw in a couple of corners to navigate, a door to open or stairs to climb and Alice is even less likely to talk to Bob.
So you need to sit teams together. You can’t outsource QA to India, or even have the test team sat on a different floor to the developers. You lose all those tiny, daily interactions (“Hey Lionel, you’ve just broken the build”; “Jon, stop testing that bit of code – I know it doesn’t work”) that make teams productive.
But the importance of interactions is wider than that. You need to encourage interactions between people in different teams, even different parts of the company. This needs to go beyond formal, sit-down meetings. It’s the random interactions that are valuable – conversations overheard in the kitchen and throw-away comments made over lunch at the pub. That’s why – once you reach a certain size – a foosball table, and a foosball league, are just as important as source control.
Of course, foosball tables also make work a more enjoyable place to be. Over on the forums, Dan Nunan asks "what makes a great office environment for software companies?". If you’ve got an opinion, post it.
Not everybody agrees that place is important though. Jason Fried, for example, argues that working in the same city as somebody is just a distraction. When he and the other founders of 37signals get together, their productivity plummets. You can find out more about Jason’s philosophy – including why he thinks roadmaps, specifications and projections are evil – by watching the video of his BoS 2008 talk.
If you think that place is important, and think that no amount of
virtual networking can replace pizza, beer and conversation, then take
a look at the Business of Software events coming up. There are small groups meeting up in Boston, San Francisco and London. I hope you can make it.
Is place as important as I think it is? Or has technology eliminated geography? Post here …
Want to get this weekly, by e-mail? Sign up to the business of software social network.
Great – if you’ve got a team you can physically fit in a 25m radius. And if the guy you need to use is willing to move to your city.
Sometimes, you’ve got to grow up.
Recognise that there are jobs too big for a 20 person team (like the A380) which is why all that boring systems engineering stuff was invented. Recognise also that the best people or facilities might not be in the city you’re based in.
Now if your project is distributed you need to work constantly (and cleverly) at building “the team”. But you need to get those personal relationships going. (Which may mean flying people around the globe or just sending them up the street for pizza. )
And there are times (such as architecture reviews) when you need to get people in front of the same whiteboard.
Certainly getting small, focused teams physically together for critical periods is the best possible outcome (and will give a great ROI).
There is an art to organising big, distributed, multidisplinary projects.
Unfortunately, a lot of leaders/managers are unable or unwilling to run a multisite project. Or get scared by the “expense” and instead spend $$ hiring the wrong people from the right town.
I’ll also add that developing over three timezones 8 hours apart allows the project to keep steaming 24/6.
It is now more than a decade since I had the eureka moment in which I realised that development can be done anywhere on the planet. (Sales and marketing can’t).
I’ve spent a good portion of that decade doing multisite projects, mostly successfully. I’ve done a fair bit of reading and training on the topic. I figure I’ve got a leg to stand on.
There has been some pretty great software produced by distributed teams, e.g.:
-the linux kernel
-apache
I used to have a top-of-the-line Tornado table when I was single. Man, that table was fast. I got so good at it that it wasn’t fun to play anymore. (not on the subject of team development, just wanted to brag about my foosball abilities.)