Welcome to management

I have been working in startup tech for over 25 years now, about half that time as a manager. After being an IC for such a long time, I was frankly excited to learn some new skills. I wanted to be a manager because I thought I could have more impact that way. And also, because I had had so many bad or mediocre managers, that I wanted a shot at creating a great environment for the people on my team. An environment like the one I'd always wanted.

I tried to do the right stuff to level up. I had been following Michael Lopp's blog for years. (His book, Managing Humans is fun, engaging, and informative.) He once turned me down for a position on his team at Apple. (I can pinpoint the exact moment during the interview process that he decided I was a no-hire. But that's a story for another time.) I had some great managers in my time, and when a difficult decision came my way, I might ask myself (for example) "what would Ted do?" And try to ape the decision-making process, or the insight of the awesome managers. Sometimes, it even worked.

I've managed ICs, and I've managed managers. It can be incredibly rewarding to coach a person through that same transition from IC to manager. It can be a weird process to go through, and I'm absolutely not saying anything new here, when I point out that the skills that get you promoted into engineering management (coding and engineering) are not the skills you need as a great engineering manager (organizing and communicating). Granted, if you're a solid, producty engineer, there is overlap in the skill sets. But the focus of the two positions is very different.

Baby engineering managers invariably go through what I call the Three Stages of Management (rather like the Five Stages of Grief). When it comes to how the people on their team write their code:

1. Control: "I need this done my way. It's important."
2. Tolerance: "Do it your way, I guess. Just don't break anything."
3. Zen: "Feel free to break it. Mistakes are how we get better."

Engineering managers become less attached as they go through the stages. It's a process of learning outcome independence. It's not that you don't care how things turn out; you do care, very much. You just realize your agency is limited, so you exert what influence you can in the moment-by-moment, but recognize the limitations. Ultimately that gives you more leverage in the long term.

Sometimes they don't ask. They just do some stuff, and it goes bad. You find out about it after the fact. In those cases, you just help with the cleanup, and try to add some prevention. But sometimes you can see it happening, as it's happening. They come to talk to you about stuff first.

When a junior engineer on my team comes to me to ask some advice, they get the benefit of a long line of my previous fuckups. Awesome, right? Let's avoid those! Sometimes you can tell they've already made up their mind what they're going to do, and are just asking because they hope you'll agree with them. Sometimes you don't agree. You tell them, "yeah, I did that one time, and it turned out like this. It wasn't great." In some cases, you can tell they're going to go do it anyway. And you can't really stop them from doing it. They go ahead and do it, and stuff turns out the way you told them it would. Hopefully, they learned something, and the next time, they are somewhat more likely to listen to you.

At my very first startup, a very early compliance e-learning company in the 90s, our engineering team was managed by a completely non-technical person. But she was a phenomenal manager, made the team vastly more effective than we were without her. At one point, there was one of the inevitable arguments on technical approach, and on one side was the designer and me (we were right, by the way), and on the other side, was one of the engineers who rarely spoke up. We were at loggerheads, and our manager had to break the tie. She chose the other side, the clearly incorrect side. (I'm pretty sure she knew he was wrong, or at least, less right.)

It was at that point I realized she was optimizing for a different thing from what we were. This technical argument — although it didn't seem like it at the time — was a tiny blip, a nothing, in overall the lifetime of this team. She was optimizing for the team dynamic, our overall effectiveness, and it worked. That quiet engineer was a lot more engaged, and our overall output and productivity increased. It didn't matter if he was technically less correct, made a mistake. It's way better to optimize for the long-term result, not the immediate technical minutia.

And a little perspective on mistakes, breakage, delays: your work is important, yes, but none of this stuff is the end of the world. Do your work in a deliberate, thoughtful way. The end result will be vastly better. I remember the guy who hired me at OSAF saying, in a meeting, with Mitch Kapor sitting at the table, "We're not taking food out of the mouths of starving orphans if this release is delayed." That's a pretty great sense of perspective.

The current context for this post, the whole reason for bringing up the Three Stages of Management, is what I am seeing on Twitter — tons of developers going through those Stages in realtime. These folks using agentic coding (Sorry, Steve, not calling it CHOP) are having an identity crisis because the skill they thought was important, coding, is no longer what makes them valuable. Their primary value is now is in coordination and communication. ("Yyyyyyyeeeeaaahhhhh ….")

"I don't know what's going on in the codebase line-by-line anymore."
"I don't 100% follow this execution flow right now."
"I haven't actually read all the tests myself."

These are the kinds of things new engineering managers say, when they have code produced by a team of people who report to them. It can be pretty disorienting, going from having total understanding of your particular slice of the world, to having a somewhat ill-defined, second-hand understanding of the entire world. Yes, yes, you should read PRs, and yes, yes, you absolutely should be writing code, as a manager. But it's not your job to write all the code anymore — it's to facilitate, to "scale yourself" by helping the team be successful writing the code. ("If you could write some tests for that, that would be greeeeaaaaat.")

Sure, okay, there are differences. LLMs can't actually learn from their mistakes, not yet anyhow ("you're absolutely right to call me out on that," etc.), so mistake mitigation is different from working with people on a team. The best you can do is an entry in an MD file that you hope the agent will pay attention to. For humans, making the same catastrophic error twice is a firing offense. (Or it sure as shit should be. I remember the poor guy at Yammer who merged the wild-west staging branch into our main development branch. Twice. Aaaaaand fired.) But you can't fire an agent for hallucinating Postgres UUIDs over and over. Or for using the same wrong command-line flag over and over. And on and on. You do have more responsibility as a manager of AI agents, than as a manager of actual people. But that's what you are. You're not a coder, you're a manager.

At Yammer, when someone got promoted into management (not me, I was a lowly IC for my entire tenure there), they would get "congratulations / I'm sorry" messages from the other engineers. Very apt. So, to all of you waking up to this new reality of agents doing the grunt work (even if it is the grunt work that you used to enjoy), congratulations, and I'm sorry. Your job is not the micro, but the macro. ("Not X, but Y.") You are a builder now, not a coder. Get used to it. This genie is out of the bottle. And sure, this genie sometimes fucks the wishes up pretty badly. But what it can do now is already borderline miraculous, and we're just getting started. Welcome to management.