So Happy Together

Bobby Knight. You either love him or hate him. I’m from Indiana, so I love him. But that doesn’t mean I don’t recognize his significant shortcomings. To call him a flawed hero is an understatement.

There’s one thing that is beyond dispute, however. Bobby Knight valued team play above individual achievement. He naturally recruited highly talented players, but what he looked for more than anything else were players who would put the team above their own ambitions. More than once he led an undertalented team that was high in discipline and teamwork deep into the NCAA tournament.

We need to learn a lesson from The General.

We’re better together than we are by ourselves. Period.

Software development is a team sport. Period.

Beware A Guy In A Room

I once heard a talk at a conference by a Microsoft manager who admonished us as development team members, “Beware of a guy in a room!” What he was talking about is the lone wolf programmer who sequesters himself or herself to work on a key part of the project and either emerges six months later with a solution incompatible with the rest of the system, or never emerges at all. Sometimes he leaves the company and the team doesn’t find out until weeks later. Ok, I made that last part up, but I always wondered if that ever happened.

This sounds ridiculous, but anyone who has read The Phoenix Project knows what a ‘Brent’ is. In the story, a high-profile software project dragged on for years partially because one of the key developers, Brent, was at the beck and call of every manager in the company and spent 100% of his time fighting fires. He had become indispensable. This wreaked havoc across the entire enterprise. One of the major turning points in the book was when Brent was freed up to work on the Phoenix Project.

We’re All Brents

The truth is that we’re all Brents. We may or may not want to be indispensable—seems like too much work to me. But even if we don’t, our attitude is frequently like the surly partner in every buddy movie you’ve ever seen: “I work alone.”

Of course, we say the right things in an interview. We love working in teams. We’re equally comfortable on a team or as an individual contributor. We’re real team players.

What we really want is to be given some work and to be left alone to do it. We think pairing is a waste of time, collaboration is overrated, and we’d be better off with the minimum amount of interaction with others so we can "get stuff done.”

We can’t admit this, of course, because we’re agile and if people knew what we really thought, we’d have to put up with a constant stream of chatter aimed at persuading us of the error of our ways.

It’s Complicated

Of course, I’ve overstated the case and erected bit of a straw person here. Many of us do like working on teams and aren’t being deceitful in interview. We are team players.

But we’re also techies. We weren’t drawn to extroverted jobs like recruiting or sales. We like wrestling with technical issues and solving hard problems. We enjoy heads down, focused work that produces a satisfying solution.

What complicates this further is that we feel like we’re not evaluated on our team skills, but on our individual technical skills. When stories move across the board and eventually into the “Done” column, my name is on the story, not the folks I collaborated with.

You Might Be A Brent If…

There’s no easy answer to this tension we feel between individual and team contribution. You may be in a situation where you are the only developer on the team, or even in the entire organization, so you better be able to work alone.

In today’s climate, however, it’s more likely you’re part of a team. In that case, how do I know if I’m being a Brent?

Here are some indicators:

1. You refuse or prefer not to pair.
2. When you do pair and you’re the one on the keyboard, you just start typing away without communicating with your partner at all.
3. When you pair and your partner is on the keyboard, you are impatient with your partner and eventually just take the keyboard away from them.
4. You think story refinement is an interruption to your workflow rather than an integral part of it.
5. You don’t participate in retros, or you give such little thought to what went well, what went poorly, and what the team could improve upon that you can’t give meaningful input.
6. When you’re assigned a story, you create a feature branch, pull up your IDE, and start typing. Little or no thought is given to design, and you don’t ask another developer to walk through what you should do with you. Sometimes you don’t even read the acceptance criteria.

Lest you think I’m being unfair or overly harsh, these are just a sampling of the sins I have committed over time and that I struggle with.

What Now?

What do we do now? How do I become a better team player?

The easy answer is to look at the list of indicators above and don’t do those things. The problem is, this list is neither comprehensive nor can I claim it is representative of what all developers face. It’s just a list of my major neuroses.

What I can say is to give it some reflection and see where you might be falling short as a team member. And talk to your team. If you can’t talk to your team, that’s probably an indicator in itself.

Finally, here’s an aphorism I’ve heard in several different contexts, but it applies here very well:

If you want to go fast, travel alone.

If you want to go far, travel together.