On Managing Developers

I’ve been a software engineer, a novelist, a journalist, and a manager–and managing developers is easily the trickiest thing I’ve ever done. (Not the hardest. But the trickiest.) I don’t pretend to be an expert, or a great manager. But I can assure you I am someone who screwed up a lot along the road to being better. Here are some mistakes from which I have learned:

Just Because You’re In Charge Doesn’t Mean You’re In Control

The great irony of management is that the higher up you go, the less actual control you have. When you are but a humble coder, you make the computer do exactly what you want; when you’re a manager, you only hope that people understand what you want, and then trust/pray that they do it both correctly and in a timely manner.

Developers turned managers, especially “full-stack” (aka “dilettante”) developers like me, often have trouble with this. This is especially true when, like me, they’ve spent their career vacillating between 100% coding, 100% managing, and some combination of the two. It’s hard to pull back from the urge to do everything yourself to ensure that it’s done right.

It’s even harder to distinguish between “that’s not how I would have done it” and “that’s wrong and needs to be refactored/rewritten/reassigned” when reviewing someone’s work. But you have to give junior devs room to flex their wings, and senior devs space to fly. You have to deliberately step back and accept that with greater influence comes diminished control.

Engineering managers who don’t come from an engineering background have even less control, along with less understanding of development processes and pitfalls. I’m skeptical of such–but their number includes a few of the best I’ve worked for/with. What they bring is, hopefully, an enhanced ability to think like a client/executive/end-user, and, maybe, a greater capacity to divorce themselves from the illusion of control. Developers-turned-managers tend to think of themselves as a general commanding an army, when really you’re a navigator hoping to guide a ship through a storm. It’s what the crew does that actually matters.

Agile Is Good. What Is Agile?

People talk about process a lot. Too much, if you ask me. In many places, ‘agile development’ has become codified into a fixed, carefully specified process of “standups” and “scrums” and “sprints,” which is darkly ironic given that the key principles of the Agile Manifesto include “value individuals and interactions over processes and tools” and “value responding to change over following a plan.” So what did companies create and fervently follow? Agile processes, tools, and plans. Sigh. If you are a Certified Scrum Master, you are doing it wrong.

Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. People wax enthusiastically about the Lean Startup’s idea of the Minimum Viable Product — but they also speak of this as the Age of Design, and say the design has to be beautiful and perfect out of the gate for a startup to succeed. Face-to-face meetings and “casual collisions” can be extremely potent — but so can 100% remote teams scattered across a dozen time zones. Who’s right? The answer, as always: it really depends.

Don’t get me wrong. I’m not saying you should have no well-defined process at all. I’m saying that the systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context.

Thankfully, I work for an agile development shop that cares about what actually matters. What’s most important about agile development is right there in the name. You’re agile. You move fast. (Oh, and you write tests, pragmatically. That’s not in the name, but it’s pretty important too.) You ship code regularly and frequently. Because if you don’t–well, in my experience, software stagnation is subject to the Lindy Effect; the longer you have stagnated, the longer you will stagnate. Like a shark, if you don’t keep moving, you will soon die.

The Shit Work Is Your Work

Basically a manager’s job is to make other people more productive. What’s one really good way to do that? Do the work that is getting in their way. Which means: find out what kind of important work your developers dislike the most, and do it for them.

Few developers like to write documentation. That means it’s your job. Testing is really important, but few developers like to write tests. That means it’s your job. Not all of the tests, necessarily, but enough to set an example, set the standard, and get the ball rolling. Not a coder yourself? Learn enough to at least write tests. A coder yourself? Build the whole test harness, and make it as easy as possible to add to it. Think QA is someone else’s job, or not part of your job description? Then you’re a really really really bad manager.

You have to do the interpersonal shit work too. If a developer comes to you and says “this is a giant mess and we need to bite the bullet and refactor it and do it right, but it’ll mean a deadline slip,” you probably need to champion that, even if it hurts in the short run. In the long run it will pay off. Only accrue technical debt like that if a risk of there not being a long run is evident.

The summary of the summary of the summary is: people are a problem

Unfortunately, as you probably already know, people suck. People flake, screw up, ignore you, pester you, disappear, quit, and/or lose faith in you, frequently for no good reason. Guess what? Now that you’re a manager, their screwups are your screwups, and their problems are your problems. Get used to it. You need to develop an early-warning sense of people problems and have contingency plans in place.

Also: people work in different ways and at different paces. Which is a polite way to say that hiring well is really important, because, again, most people suck.

But you know how people — surprisingly — often don’t suck? Not to get all wifty and woo on you, but this was the most unexpected lesson of my professional career: once people learn that they can trust you, then you can usually trust them back. No, really. I swear.

So don’t bullshit anyone, ever. (The greatest professional compliment I ever received was from an ex-boss in an exit interview. He mused: “I don’t know how you do it, but when you talk, people drop their bullshit filter.”) Speak the truth as you see it. Speak it diplomatically, don’t get me wrong; but be trustworthy. Only then will you be able to trust others.

You’re basically a mildly glorified technical translator

Managers translate the project’s Big Picture into individual tasks for developers, with their details and interactions specified in minute detail; translate the work done by developers so that clients/executives/users understand it; and, perhaps most importantly, translate the details of errors, roadblocks, and opportunities to client/executive-speak as well. As any professional translator will tell you, this means you need to understand the work more intimately than the author. To them it’s intuitive, but it’s your job to break it down so it makes sense to anyone.

But–and I speak as an author here–translators get essentially zero of the glory and acclaim of having written a book. All the good decisions they make are attributed to the author. Similarly, the founders (or, in our case, the clients) get the acclaim for the creation, and the developers for the code. Nobody sees a beautiful baby and praises the midwife.

So why do it? Because, as I said, individual developers may have more control, but they have far less influence. Unsung and unpraised as they may be, those decisions you make will ultimately determine whether the thing you built is good or bad. And if that doesn’t matter to you, you’re probably not just a bad manager, you’re in the wrong field full stop.