I Couldn’t Give Up the Code. Then I Stopped Needing To.

Guest post by Sean Cooper, Your Dev Team Coach.

Today's guest is Sean Cooper, an engineering leader and coach who writes at Your Dev Team Coach. He has spent years on the floor on both the IC and the manager side, and he talks about the move into management the way the best EMs do: honestly, and with the scars to prove it.

I asked Sean Cooper to write this one because he's actually run the play. He spent over a decade with his hands on the code before he led teams, and now he coaches engineering leaders at Your Dev Team Coach. What follows is field-tested, not theory.

It’s an exciting read. Let’s get into it.

---

We were ten minutes into the 1:1 when I said it out loud. I told him I thought he should think about management as a career trajectory. He had every trait I wanted in a manager. Strong empathy. A deep grasp of programming and architecture principles. Fantastic organization. Real dedication to making the team better. He was already the person other engineers went to, already the one who spent his free time thinking about how to make the team more efficient and happier.

He didn’t dismiss it. He sat with it. I could see him weighing it, turning it over, taking it seriously the way he took everything seriously. He understood why I had said it. He could see the version of himself I was describing.

Then he told me, “I just can’t give up the code.”

I knew that feeling cold

I didn’t argue. There was nothing to argue with, because he was right about how it feels. I knew that feeling cold.

Building something by hand is deeply rewarding. Write the function, run it, watch it work. The feedback is, relatively, instant. The control is absolute. You decide, you build, you see the result, and the loop closes in minutes.

I’ve done woodworking on the side, and it scratches the exact same itch. You cut the joint, you fit the joint, and either it seats clean or it doesn’t. The table stands or it wobbles. The wood does not have opinions about your roadmap. I spent over a decade at that bench, and I loved it. So when he told me he couldn’t give it up, I wasn’t hearing an excuse. I was hearing the truth.

It was never about the code

But here is the thing I eventually understood, and the thing I wanted him to understand. It was never about giving up the code. It’s about where your reward comes from.

Building by hand gives you a fast loop and total control. The payoff lands almost immediately. Growing people is the opposite. The loop is slow. The control is mediated. You plant something in a 1:1 and you might not see it bloom for six months. You can coach, you can clear the path, and you can create room, but you cannot type the growth into existence. The reward is real. It just arrives late, and it arrives through someone else.

That gap is the whole problem. The fear of letting go of the code is really the fear of giving up the loop that made you feel competent every single day.

The turn

When I really got strong as an EM was when I lost the need to code.

Not the skill. Not the joy. The need. The day-to-day craving for that instant, hands-on hit of having built the thing myself. Once that loosened its grip, the joy and the satisfaction moved. They moved to what my teams produced. My accomplishments became their accomplishments: the engineer who finally shipped the thing she had been circling for months, the team that delivered without me in the room.

It is a strange thing to describe to someone who hasn’t felt it yet. Your sense of a good day stops being “I closed three tickets” or “I solved this crazy problem” and becomes “she finally owned that design review and crushed it,” “he really nailed that presentation in front of the department,” or “the team just shipped a new feature in record time.” The reward is different. It is bigger. It’s just no longer yours alone, and that is exactly what makes it bigger.

---

Paid subscribers get The Need vs Craft worksheet today. Five questions on letting go of the loop without losing the love.

Here’s what comes with being a member:

• The How to Be Taken Seriously field guide on signup

• A worksheet and short video walkthrough with every weekly article

• A monthly 4,000-word deep-dive, paid subscribers only

• Monthly live office hours with me

Become a paid subscriber →

---

A new mountain

I have always framed my career as climbing mountains. For a long time, every mountain was made of code. A language I had not mastered. An architecture I had never built. A problem nobody on the team could crack. I climbed those for over a decade. At some point I looked around and realized I had climbed all the code mountains I wanted to. I was secure in those skills. The summit did not scare me anymore, so it did not pull at me anymore either.

The new mountain was management. Become a better leader. Build the judgment to grow people. Assemble a team that outperforms anything its members could do alone. That climb is harder than any code mountain I ever faced, and I am still on it. I expect to be on it for the rest of my career.

Here is the part that sounds like a paradox until you live it. Letting go of the code did not shrink my identity. It moved it. My ego, and I do not mean the braggart’s version, I mean the quiet one, the thing your sense of self actually rests on, stopped depending on the code I wrote and the apps I shipped. It came to rest on how my team performs and how far my people grow. That is not a smaller thing to build a self on. It is a far bigger one.

The nuance that saves all of this

This is the part people get wrong.

I did not stop writing code. Not even close. I still very much enjoy it. I read pull requests. I pair when it helps. I sketch out an approach when a thorny problem needs a second set of eyes. I’ll prototype ideas for the team to refine. The craft did not go anywhere, and I would not want it to.

Need is the thing you give up. Not the craft. The distinction matters, because if you hear “become a manager” as “stop being an engineer,” you will resist it forever, and you should. That trade is a bad one. The real trade is quieter. You keep the love. You release the dependency. I’m fully willing to do everything but code if that’s what my teams need, and I’m just as willing to open the editor when that’s what serves them. The point was never to abandon the code. The point was to stop needing to write it to feel whole.

Back to the bench

I could have that conversation with him only because I had already made the crossing myself.

You cannot walk someone across this line by selling them a title. Nobody crosses it because the org chart promised a bigger box. They cross it when the fear gets named, when the reward gets reframed, and when they see that the person across the table has stood exactly where they’re standing. I didn’t tell him management was better. I told him I had loved the code the same way he did. I told him that there was a time I had been just as sure I could never let it go, and that the letting go turned out to be smaller and stranger than I feared. I kept the craft. I just put down the need.

That’s the part you can only offer if you’ve done it yourself. The reframe doesn’t land as theory. It lands as a scar you’re willing to show.

So I left the choice with him, the way it had to be left. He doesn’t have to give up the code. He never did. He only has to ask himself whether his best days are still going to come from the loop he can close alone, or from the people he could grow if he let his reward come from them instead. He’ll know the answer when he stops needing the bench to feel like himself. And when he gets there, he’ll be ready to sit across from the next developer like him and say the thing out loud.

Final thoughts from Ryan

A few years before I had Sean’s language for it, I had made this crossing myself. The bit I would add, and the bit I wish someone had told me, is that the need does not stay gone. It comes back. Quietly, on the bad weeks, when a project is slipping and a deadline is moving and you cannot fix any of it with your hands. The editor opens itself. The keyboard starts to look like a refuge. You can lose six hours to a problem your team should be solving, because the fast loop Sean describes is the cleanest hit of competence you know how to give yourself, and on the days when nothing else feels under control, it is genuinely tempting. The crossing is not a one-time event. It is a maintenance job. Sean is right that the reward moves and that it gets bigger. The bit I had to learn the hard way is how often that old reward comes knocking even after the crossing, and how good you have to get at recognising it before it has you back at the bench by Tuesday lunchtime.

---

The training I wish someone had given me when I was figuring it out.

The work doesn’t get easier by waiting for the next title to fix it. It gets easier when you stop figuring it out alone.

EM Accelerator is the premium training platform I built for engineering leaders managers who are done piecing this together from podcasts and Twitter threads.

Launch offer 42% off. Reply to this message, and I’ll give you an extra 10% off for this newsletter edition only.

---

Liked this, even a tiny bit or feel sorry for me? Hit the like button ❤️

Think someone else might need to read this, or you just want to make fun of me together? Share this post 🔗

• EM Accelerator is open. Premium training platform for engineering leaders, managers and the people becoming them. Launch offer 42% off. Reply to this and get an extra 10% off.

• Become a paid subscriber and get the How to Be Taken Seriously field guide, weekly worksheets, monthly deep-dives, and monthly live office hours. £8/month or £80/year.

• Find me on LinkedIn. 58,000+ followers and counting.

• New videos every week on YouTube.

• Want to write a guest post? Reply and tell me what you’d write about.