Engineering Growth: Learning to Let Go
On ego, trust, and the hardest part of being a principal engineer
I’ve been a principal engineer for almost a year and a half now. And the thing that I find myself struggling with the most isn’t at all what I expected it to be. It’s not working with vagueness or influencing people. It’s about learning to let go.
Not in a passive, step-back-and-hope-for-the-best kind of way. But in the active, daily, uncomfortable way where you watch problems get solved differently than you would solve them and you have to be okay with that. Sometimes you’re genuinely impressed by the approach. Sometimes things go off track and need correction. Both of those are fine. Both are learning opportunities. The hard part is resisting the urge to jump in and steer.
Two Directions, Same Struggle
This happens in two directions that I deal with almost daily.
The first is upward. Will Larson wrote about this in his Staying Aligned with Authority post.
At the staff+ level, you’re expected to have strong opinions. You’ve built judgment over years, and you see patterns, anticipate risks, and have a vision for how things should evolve. But you’re not the final decision maker for everything. Leadership will sometimes go a different direction than what you advocated for. Maybe they have context you don’t see. Maybe they’re optimizing for something different. Or maybe you just disagree.
The challenge isn’t understanding this intellectually. Everyone gets that in theory. The challenge is not letting it turn into resentment. Or an us-against-them feeling. It’s learning to genuinely commit to the direction that was chosen, even when it wasn’t yours, without becoming passive or bitter about it. You still push back when it matters. You still raise concerns. But once the call is made, your job is to make that direction succeed. Not because you gave up on your opinion, but because that’s what the role actually requires.
Larson frames this as authority being “loaned, not owned.” And that framing helped me a lot. Your effectiveness depends on staying tightly aligned with the people who loaned you that authority. The moment you start working against the grain because you think you know better, you’re burning the trust that makes the role work in the first place.
I won’t say I’ve figured this out. There are still days when it’s frustrating. But I’ve been learning to sit with that frustration instead of acting on it. That’s a work in progress.
Downward: The Harder One
The second direction is downward, and this is the one I struggle with more. When you’ve spent your career building strong judgment about how to approach problems, watching someone take a different path triggers something. It’s ego. It’s competitiveness. It’s the instinct that says you could do this faster, or that you already know where this is heading.
It’s fighting the urge to play the hero role
But the job at this level isn’t about your solution anymore. It’s about their growth. And growth doesn’t happen when someone follows your exact blueprint. It happens when they wrestle with the problem, make their own calls, and learn from what comes out of it.
I’ve had cases where I let go and was genuinely impressed by what someone built. Approaches that I wouldn’t have considered, solutions that fit the context better than what I had in mind. And I’ve had cases where things went completely off the rails and needed course correction. Both were good outcomes. The first reminded me that my way is not the only way. The second was a learning moment for everyone, myself included.
The real tension is that you can’t fully disappear. You still need to be present, still need to catch the things that genuinely matter, still have to create conditions for people to succeed. The line between giving space and staying involved is thin, and I get it wrong more often than I’d like.
It’s like learning to become a football coach after being a player your entire career.
The Ego Part
I want to name this directly because I think a lot of engineers at this level feel it but don’t talk about it.
You want to make an impact. You’re competitive. You want to be the one solving the interesting problem. That’s probably part of what got you here. And when you step back to let someone else lead something you could have done yourself, there’s a voice that asks whether you’re still relevant. Whether you’re still contributing enough.
It’s something that every staffplus engineer knows. How to be a multiplier instead of an execution force. The same principle applies here, but at a higher altitude. You’re not just enabling your immediate team, you’re shaping how problems get approached across a wider surface area. And that only works if you learn to let go of being the one who solves them.
How I’m Approaching It
I don’t have a clean framework for this. But two things have been helping me.
The first is encouraging people to seek feedback early. When someone shares their thinking at the rough draft stage, I can give lightweight input without taking over. I can ask questions, flag risks, and then step back. The earlier the feedback happens, the less it feels like me imposing my view and the more it feels like a normal part of how we work together.
The second is being more hands-on. And this is a big shift that’s happening across the industry right now. Over the last couple of years, my productivity has been doubling almost monthly. Using Claude Code, Copilot, and other AI coding assistants has made this possible in a way that wasn’t realistic before. I’m shipping code more than ever, even at the principal level.
This matters because it changes the dynamic of letting go entirely. When you’re contributing tangibly to the codebase, you don’t feel like you’re missing out. You’re not the theoretical architect who reviews from a distance and gives abstract feedback. You’re in the code, you understand the current state of things firsthand, and that gives your input real weight when you do engage with what others are building. People take your feedback differently when they know you’re in the trenches with them.
But it also solves a personal problem. A big part of why letting go is hard is the feeling that you’re losing your identity as a builder. You became a principal because you’re good at solving problems, and suddenly the job asks you to stop doing the thing that got you here.
The taste here, and it’s a real one, is knowing how to do this without slipping back into hero mode. Being hyper-productive as a principal is great until you start absorbing problems that should belong to someone else. The line between “I’m contributing” and “I’m taking over” gets blurry fast when you can move quickly. I’m still learning where that line is.
Together, these two things make letting go feel less like losing control and more like a deliberate way of working where everyone stays connected without anyone being the single point of authority.
Still Figuring It Out
I catch myself wanting to jump in when I should step back. I still feel the pull of wanting to solve the interesting problem myself. And there are days where I tip too far in one direction, either too hands-off or too involved.
But I think that’s the nature of this role. The technical problems at this level are solvable. The human ones, the ones that require managing your own ego and trusting other people’s judgment, those take much longer to get right. I’m not there yet. But I’m working on it, and writing about it is part of how I process it.