I’m sitting in a Starbucks in the ‘Multimedia Gulch’ area of San Francisco, having just shared some fine San Francisco Burritos with Joel Spolsky. It’s been a few years since we last chatted, and much has changed. Joel’s company, Fog Creek Software, has more than doubled in size. They have mostly filled their recently expanded office space and Joel is busy figuring out how much space they should get to accommodate future growth. A new version of FogBugz has just been released and Joel is doing a demo tour. I think he still has space available in a few of his Bay Area demos. If you get a chance, check it out. I’ll be there tomorrow morning in Mountain View.

We explored the question of how big can an engineering group get before it needs formal leadership and management structure. Fog Creek is still below the threshold. When I joined FactSet, we were just getting there. I remember fondly the time when all the projects where single-person affairs. It is a much more efficient way to work, as each person that gets added to the team adds exponentially to the communication overhead. OK, exponential is really more theoretical (think fully connected graph) than practical, but the point remains that as the team gets bigger, more time is spent communicating.

We posited that very often, a company bumps into the need for more ‘management’ or leadership when they take on the task of building the second product. While the company’s original product may have evolved organically over time, starting as the brainchild and fruit of one person and growing head-count slowly, companies often try to accelerate the process with subsequent products. They have the bodies now, so they should be able to build out the product faster by assigning 10 or 20 people to the project from day one; right? Maybe, but such an effort takes leadership. Put 20 brilliant software developers in a room and tell them that the company needs them to build a snazzy new product and you will often get 20 radically different ideas about what that means how they should proceed. This is a perfect recipe for a bunch of thrashing, but not much progress toward a good product.

We sparred a bit over the value of agile development methods, especially Extreme Programming (XP), but that conversation quickly ended with us both agreeing that good teams can use such practices effectively and that dysfunctional teams can abuse them. In the end, it’s the people that matter the most.