Delivery and Dopamine
I've built my career around being the person that delivers. Throw me into a messy problem and I'll figure it out and make progress.
My performance reviews praised output. Peers trusted me as the person who “got things done”. The system rewarded shipping, and for a long time I used that as my definition of “doing my job well”. I confused visibility with value, and if I’m being totally honest, I was addicted to being the person that everyone pinged.
Then one day, my career stalled. I just couldn't justify another promotion on output alone. Shipping things feels good in a way that designing systems doesn't. Shipping provided that immediate dopamine hit, but system design doesn't work like that. Feedback is delayed and ambiguous, and honestly, things usually get worse before they get better.
You can justify being a player-coach as a manager, senior manager and in some places, even a director. But at some point you need to accept that the best use of your time is to act as a multiplier for the team that you're supporting.
That's where I failed.
Dopamine vs. Leverage
Execution gives you fast feedback. System design demands patience.
When I say “designing systems,” I don’t mean architecture diagrams. I mean the interfaces that shape how the business operates: who makes decisions, how work gets planned and what happens when things break.
Discipline means letting the system converge on an idea and make decisions without you "helping". It means allowing systems to fail without heroics, enabling the organization to understand the flaws in the system. It means trading that dopamine hit for organizational leverage.
It also means being comfortable with feeling like a failure. Letting projects fail felt irresponsible. Not being hands on felt lazy. And if I'm honest, not getting that dopamine hit felt like withdrawal.
The Relapse
When leaders step back, things slow down. Metrics wobble. People complain.
That's the system revealing itself. Heroics are praised, and organizations choose short-term relief over long-term leverage. So when things got messy, I didn’t choose execution, I relapsed into it. It was the easy choice. The safe choice. It was also the wrong choice.
I fell back into being an IC multiple times. Each time the dopamine hit was even bigger. "Things were really going downhill and you turned it around!" Each time, it was even harder to crawl back out of the routine of shipping and start thinking about the overall system.
In one example, there was a last minute tooling update required for a key customer. So I dove in, made the changes, got the relevant approval and shipped a fix within 24 hours. The customer was happy, the account team was happy, the engineering team appreciated not being interrupted... then less than a week later the exact same thing happened again. Everyone's first instinct was to message me. My save the previous week didn’t fix the problem; it taught the organization the workaround.
The "helping" trap
I told myself I was "just helping".
But “helping” was a trap. It kept me focused on solving the immediate problem instead of asking why this problem kept showing up. It made me the bottleneck instead of fixing the decision boundary. It let me feel needed, and in the process I stole learning from the organization. The team didn’t get stronger; the system didn’t improve; I just became the workaround.
I'm not entirely at fault, though. While I was chasing the next hit I was also operating in an environment that was easy to understand. Do good work, get rewarded. Designing systems is filled with ambiguity and risk. System design is political, cross-functional and uncertain. It's also invisible to your stakeholders (until it fails). Execution is visible, measurable and safe.
Build a System That Ships Without You
Building a sustainable system is thankless work. The feedback loop is slow, and the wins are quiet. You don’t measure it by what you shipped - you measure it by what happens when you’re not there.
A system is getting healthier when:
- Recurring fires disappear because you removed root causes instead of treating symptoms.
- Decisions happen without you (and they’re good enough. Not perfect. Good enough).
- Approval paths are explicit: who decides, what “good” looks like, and how long each step should take.
- Leading indicators show up early, so problems surface while they’re still cheap to fix.
If you're looking for a concrete example, we moved approvals from an ad-hoc Slack-based approach with emoji reactions to a weekly forum with named decision owners and SLAs. It felt like more process, but the overall time investment was much lower.
To understand if the system is working, ask yourself "if I take a month off, does the team still make good decisions, ship on time and recover from setbacks?".
(Fun fact! This is one of the reasons I quit my last job. I took 3 months off when my baby was born and when I got back to work it was as though I'd been there the whole time. They no longer needed me, and it was time to go and build systems somewhere else.)
The organization trained me
The org rewarded heroics, and I cashed the checks. Repeatedly.
In many cases a leader is doing what the organization expects of them. It's not that they can't let go of execution, it's that no-one tells them that they should. So we keep delivering, getting that dopamine hit and feeling effective.
Until organizations realize that leadership is about designing systems that enable the work, rather than doing it, they'll keep celebrating productivity and wondering why nothing scales.
We have to fix the incentives. Evaluate leaders based on team throughput and decision quality, not individual output. Celebrate recurring fires that no longer happen. Put “eliminated dependencies” and “decisions made without me” into performance reviews. Heroic saves should result in a postmortem and a system fix, not a medal.
If heroics are the path to praise, leaders will keep relapsing (even when they know better). If you keep rewarding people for being the system rather than building the system you won’t get leaders.
You’ll get bottlenecks with better titles.