Code is Easy, People Are Hard
What engineering doesn’t tell you about leadership, and why we often chase the wrong kind of success.
I once interviewed a CTO on my podcast, you can find the episode here, and something he said caught me off guard.
He told me that his best days in engineering were when he was still an IC (individual contributor).
Not when he was managing big teams. Not when he had final say. But when he was simply writing code.
“Those were the best days because success felt tangible,”
“You push, you ship, you win.”
He wasn’t dismissing leadership. He was illuminating a truth I’ve since come to understand deeply: the higher you go, the fuzzier success gets and the more it depends on things you can’t control.
The Durability of Success
A mental model has stuck with me ever since: the durability of success factors.
Ask yourself these two questions:
What determines my success right now?
And how much of that do I actually control?
As an IC, your inputs and outcomes are often tightly coupled. Ship features, write tests, fix bugs…success flows from your keyboard.
But as you grow in leadership, that coupling stretches. You start managing dependencies. Timelines. Team dynamics. Emotional weight. Stakeholder expectations.
Suddenly, your success hinges on how well others are doing — and whether they trust you enough to let you help.
Let Me Tell You a Story
There was a time in my career, early days of a fast-growing product, where we were close to launch but behind schedule. The pressure was insane. The team was tired.
And I…didn’t write a single line of code.
Instead, I made sure stand-ups were clear, blockers were unblocked, the team wasn’t getting fried, and leadership had transparency without panic.
We launched on time. But no one clapped for me. The win belonged to the team.
And yet, that week taught me the true job of an engineering leader: to multiply output, not to create it yourself.
Are You Sure That’s What You Want?
It’s easy to fall into destination bias, the idea that the next role, next title, next jump will finally feel like success.
But sometimes we’re just climbing ladders we never meant to climb.
Management is not a promotion. It’s a career change.
So many brilliant engineers take the leap, only to find themselves missing the clarity and flow of their IC days. They miss the adrenaline of closing a ticket at 1 AM. The joy of solving a gnarly bug no one else could. The pride of owning something end-to-end.
Leadership trades adrenaline for ambiguity.
You’re not paid to do - you’re paid to think, enable, and trust.
Engineering Is a People Problem
The deeper I go into engineering leadership, the more I realize this:
The real work isn’t the architecture. It’s the alignment.
The hardest bugs to fix are team dynamics. Miscommunication. Silent tension. Lack of ownership.
That’s the real tech debt.
If you’re thinking about stepping into a leadership role, ask yourself this:
Do I love empowering others more than I love being the smartest person in the room?
If the answer is yes, you’re ready.
If it’s not, that’s okay too. There’s incredible value in staying close to the craft.
A Book That Helped Me
If this resonated, here’s a book that’s shaped how I think about engineering leadership:
📚 Systems of Engineering Management by Johan Larrson
It’s not just about managing people. It’s about thinking in systems, aligning clarity, culture, and technical decisions to create velocity at scale.
Because great engineering teams don’t run on code. They run on trust.
Code is easy. People are hard. But people are also the most rewarding part of the job.
If you’re building teams or thinking about your next step, I hope this gave you something to reflect on.
Have you transitioned from IC to leadership? What surprised you the most?