Atlas Compiled: On Carrying Software Development Teams

6 minutes read

If you’re a software developer/engineer, you’ve probably heard of the “10x Developer”. You’ve might mistakenly believe that they’re as mythical as a compassionate conservative or a rational liberal. Such developers are miracle workers, allegedly capable of doing by themselves the work of at least ten common developers. Not only do a lot of tech companies want to hire them but they’ll do almost anything to keep the ones they’ve got on the payroll.

I’m probably not a “10x Developer”, but there are occasions when I can be said to have “carried the team”. Based on those experiences, which a Reddit post asking, “What sort of gratification (if any) do you get from carrying someone?” brought to mind even though the submitter was probably asking about carrying people in the literal sense rather than the figurative one.

The Short Version

I used to aspire toward being acknowledged as the “most valuable player” when I was a younger and less experienced programmer. However, as I got older and gained experience I came to suspect that being the MVP was a burden I might be better off without.

I’ve also come to suspect that while it’s often useful for athletic teams to acknowledge particular athletes as MVPs if they’re especially effective offensive or defensive players, such internal competition might be counterproductive in a business setting.

The Long Version

While I lack the physical strength to physically carry somebody, I’ve carried teams of software developers in the figurative sense by being the guy management comes to when they need somebody they can rely upon to solve problems and debug code that “nobody else can”.

While I think management is unfair to the other developers on my team by assuming that they can’t do everything I can, the truth is that while the other developers can do everything I can do, it usually takes them at least twice as long. It used to take them at least five times as long, but I like to share what I’ve learned over the years and help my teammates improve.

One of my reasons for helping other developers get better is that teaching others helps me learn. The other is that I honestly don’t like being the go-to guy for everything any longer.

It was great in my 20s because I thought it meant I was indispensable, but now that I’m pushing 40 it feels like I’m Herakles taking the world on my shoulders every time a manager says something like, “I need you on this project because I know I can count on you to write better code faster than the other guys.”

Sure, it’s flattering as hell and I like to have my ego stroked as much as the next guy, but I’ve been on enough projects to get nervous when management mistakes me for a 10x developer and puts me on a project that threatens to run behind schedule/over budget (even worse, if it already has) and expects me to suddenly turn things around.

The general rule is called “Brooks’ Law”. It comes from Fred Brooks’ The Mythical Man-Month, a classic text on managing software development projects published in 1975. It goes like this: “Adding manpower to a late software project makes it later.”

There are times when I’ve been called upon to implement from scratch a complex feature for a product that should have shipped last week on an extremely tight deadline with no information about the requirements but a note written on a bar napkin and pulled it off without breaking at least a dozen other critical features in the process, but such successes are few and far between. I’m extremely fortunate in that my managers tend to forget all the occasions when they asked me to duck into the men’s room and pull a miracle out of my ass, only to have me come out with a hand full of shit.

I’m not a rockstar developer. I’m experienced, competent, and opinionated, so not only do I tend to speak up often, but people often listen to me and give my words more weight than they might deserve. I’m also careful and reliable, so I tend to save time by avoiding mistakes and writing code the other developers can easily read and understand.

Coming back to Brooks’ Law from The Mythical Man-Month: adding me to your late project will still make it later, but it won’t be as late as it might be if you add one or more developers with less experience. I already know the ropes, and I’m comfortable jumping in and figuring things out while reaching out to subject-matter experts as needed.

Unfortunately, it’s hard to explain to managers that it’s dangerous to expect one developer to carry an entire team and project on their shoulders. Professional software development for governments and enterprises (or even major consumer-grade applications) is a team effort, and it’s dangerous to let any particular developer become irreplaceable, even me.

I won’t go prima donna and threaten to jump ship unless the firm makes me a partner and pays me half a million a year to sit on my ass and bash out code, and and I don’t think I’m likely to get hit by a bus or suddenly drop dead of a heart attack, but I’m still only human. Maybe I’m swamped. Maybe I’m just having an off day. Hell, maybe the sci-fi novel I’m currently writing on my lunch breaks will turn out to be the New York Times bestselling, Nebula award-winning basis for a blockbuster movie with a soundtrack by a dozen different Grammy award-winning heavy metal bands that finally lets me quit my day job.

Sure, I’d give notice and finish my current project before leaving because I’ve got an old-fashioned sense of loyalty and professionalism and don’t believe in shafting people who have done right by me, but that’s beside the point. If a business is so dependent on my continued presence on the payroll that I’m not merely invaluable but irreplaceable, then somebody in management fucked up. If a business has a bunch of absolutely irreplaceable workers, then they’ve set the stage for the sort of clusterfuck MBA students will still be studying ten thousand years later if all those “irreplaceable” workers decide to form a union and go on strike, look for better positions at other companies, retire, or all get on the same airplane that some right-wing nutjob hijacks for use in a kamikaze attack on the Federal Reserve.

Bringing somebody like me aboard and telling the other developers that I’m some kind of miracle worker who will succeed where they failed isn’t going to inspire them. If anything, it will demoralize them, and lead to them caring more about covering their own asses to avoid losing their jobs than they do about producing a quality product that delivers on the client’s requirements. Teams with bad morale deliver bad products, if they deliver at all.

I don’t want to tear down other developers. Nor do I want my presence on a team to have the tacit effect of making other developers feel like they’re being torn down. I would rather lift up other developers and help them reach my level or even surpass it, because it that’s a better way to ensure that the business delivers a quality product than asking me to play the hero.

I’m no hero. People shouldn’t mistake me for one, even if I do rock a flowing mane of shimmering hair that looks badass on a sunny, breezy day. Instead of trying to recruit a MVP developer who can compensate for an otherwise weak team, managers should work toward building better teams where every member is a solid performer and each has individual strengths and perspectives that complement those of their teammates.