Why Team Dynamics Matters

A couple of jobs ago I made a terrible mistake. Not of the Fred Brooksian multi-million dollar variety, but one with more modest financial repercussions. I recommended hiring a hotshot who was bright and hardworking, but who was also arrogant, antagonizing, and antisocial. You know the type.

In our field, leaders go through this calculus all the time. Can someone’s domain or technical strengths justify the negative impact their personality -- or lack thereof -- will have on the team? Asked another way, is anyone indispensable? This is the perennial tradeoff question. Experience teaches that the answer is always no. At the time, this was probably obvious to everybody except me.

Even when the answer seems to be yes, it’s really still no. The main reason is Conway’s Law, which holds that organizations produce software systems whose communication pathways reflect the communication pathways of the developers themselves. This notion is a two-sided coin. It predicts that dysfunctional teams will produce bad code. But Conway’s Law can also be used deliberately to make good code.

When it comes to engineering, a couple of developers in front of a whiteboard for five minutes can avert many person-days of barking up the wrong tree. One productive all-hands meeting, even though expensive, can pay for itself by identifying disconnects and misunderstandings early. And many a lunchtime conversation has its eureka moment, when friendly cross-pollination uncovers some useful idea.

Contrast that with my former environment where engineers rarely spoke because it just wasn’t worth the hassle to deal with our sociopathic new hire. Myself, I’m pretty confident and optimistic, but even I dreaded the long walk to the hotshot’s cube, knowing I’d be belittled for asking questions. On projects whose scope exceeds what one genius can deliver, no amount of technical prowess can compensate for the opportunities lost because of such hostility.

Upper management concluded that the answer to the tradeoff question above was “yes” because a working system was delivered, albeit belatedly. However, the product turned out to be a maintenance nightmare. It was brittle, bloated, and non-performant. Maybe in the hotshot’s original vision, it didn’t have to be any of those things, but upon completion it was. The product suffered because of

• The hotshot’s inability to articulate the metaphor for the architecture
• The unwillingness of the team to iterate towards a solution
• Layer upon superfluous layer of indirection in the software itself

As I reflect on that structure now, with wrapper around insulating wrapper, I realize that the software was a perfect reflection of the dysfunctional communication of the team itself. Conway was right. Maintenance costs ran an order of magnitude higher than expected, at least some of which is attributable to the astonishingly high personnel turnover rate that resulted IMHO from the ambience.

More recently, I architected a system with Conway’s Law at the forefront of my mind. I was ridiculed good-naturedly for being an interface chauvinist. I demanded very narrow APIs between the different components, which presumably were to be developed by different people. And there was some chafing, at least at first, about my insistence that the separate components be tested in isolation as a prerequisite for integration. A system was built of cooperating state machines, engineered by cooperating people.

I was a bit heavy handed in enforcing my vision of how the pieces fit together architecturally. But each developer was the tsar of their own component, so there was plenty of room for creativity and meaningful contributions. To the extent to which we all played by the rules, we produced a clean system with fairly high conceptual integrity. Even though geographically distributed, the team members communicated. We produced a top-notch product on a very aggressive schedule, and which beat the performance requirement by an order of magnitude. Conway was right again.

Our humble little team had no indispensable ubermenschen, just decent programmers that enjoyed working together. This time around, that we would be so successful was obvious to nobody. Except me.