Solve It So You Can Hand It Over

There’s a trap that catches almost every strong engineer on their way to lead.

You’re good at solving things. An incident happens and you take it - mitigate it, root cause it, write the actions and close it out. A nasty integration needs doing and you do it. A migration nobody owns lands in your lap and you make it work.

Because you’re good at this, people seek you out. Your competence makes you the obvious person to hand things to. And slowly, almost imperceptibly, you become the owner of everything you’ve ever touched.

Then one day something breaks in a system you fixed eight months ago, and the only person who knows how it works is you.

The Flip

The move from individual contributor to lead is not “solve bigger problems”. It’s a change in the question you ask.

An IC asks: how do we do this?

A lead asks: who can do this?

It’s one of the hardest transitions in an engineering career - because it means doing less of the thing you’re best at, and were rewarded for.

Look One Move Ahead

When you get pulled into something like that orphaned migration, the natural reflection afterwards is “I should have seen this coming.” That’s not quite the lesson. The lesson is that there was a next move you weren’t looking at.

The move after “solve the problem” is “something goes wrong, and someone comes looking for you, because you did it and nobody else knows how.” If you can see that move coming, you can plan for it. Solve the problem in a way that can be handed to someone else. Document it as you go. Pair someone in. Name the owner before you finish, not after.

The Goal Is Zero

When I say hand it over, people often hear “find a co-owner” or “make sure someone else knows about it”. Those are good first steps. They are not the goal.

The goal is to get it entirely off you.

A common response is “the aim isn’t to cut myself out completely, just to make it sustainable.” I disagree. The aim is absolutely to cut yourself out completely. Not because sustainability doesn’t matter, but because you have a finite capacity. Every small recurring thing you keep a thread on - the periodic audit, the vendor relationship, the batch job that falls over every so often - adds up. It doesn’t matter how small each one is.

Together they’re the reason you can’t take on anything new - you’re too exhausted to explore those new ideas, finish those proposals you’ve been meaning to get to, and so on. Things that you probably promised yourself you would do because it’s what’s important for your growth.

The only sustainable way to grow is to wholly remove work - not just dilute it.

You Don’t Have to Do It Alone

Handing things over isn’t solely your job, and you don’t need authority to start.

You can:

• Suggest an owner yourself. “I think this belongs with team X, because they own that part of the user journey.”
• Recruit an owner directly. “I’ve got this thing, and I need someone to share it with. Interested?” You’d be surprised how often the answer is yes.
• Insist that someone decides. Message your lead and theirs: “I need you to find an owner for this.” You don’t have to be the one who picks. You just have to refuse to let it stay unowned.

Leads: this is where you come in. When a strong engineer says “I need an owner for this”, the right response is not “can you just keep an eye on it for now”. It’s to take the question to wherever ownership gets decided, and get an answer.

Start Reactive, Become Proactive

If you’re reading this and realising you have six things that keep coming back to you - good. That’s your practice ground.

Don’t worry about doing this proactively yet. Start with the things already boomeranging. Each one is a chance to practise the skill: find the owner, transfer the context, make the handover stick. Once you’ve done it a few times, you’ll start seeing the next move before you take on the work, and you’ll plan for it from the beginning.

Anything that keeps coming back to you is something you haven’t finished giving away.

Finish giving it away.