I’m wired as an engineer.
When someone brings me a problem, my brain immediately switches to solution mode. I start pattern matching. I recall similar situations. I assemble an answer in my head before the person has even finished explaining the context.
It feels productive. It feels like I’m helping. But I’m not.
As a manager, I don’t live in the code anymore. I’m not dealing with the same constraints as an IC. I don’t see the trade-offs the team is making day to day. When I jump straight to a solution, I’m solving a simplified version of the problem — one filtered through my own biases and incomplete information.
Then there’s the authority factor. The voice of the leader carries disproportionate weight, especially if it comes from a respected engineer. Even when it’s presented as “just an idea,” once the boss speaks, the mental frame gets narrower. The team stops expanding the problem space and starts evaluating your solution. And you start getting invested.
Other options, maybe even better options, get killed before they’re even articulated. Engineers shift into execution mode. Ownership drifts upward to me because I authored the direction. Now it’s become “my” solution, and I end up having to drive the execution.
Leadership already means juggling competing priorities, stakeholders, hiring, long-term direction, culture, and risk. Every time I decide that I must personally solve an engineering problem, I add another spinning plate. One more thread to keep in working memory. One more thing to track.
But I don’t have the time for this. And I feel the stress creeping up.
That’s when I realize I’ve been doing it wrong.
My responsibility is not to find the solution. My responsibility is that a solution is found, and that the business need is satisfied.
I am accountable for the outcome, but it doesn’t mean I have to do it myself. That’s what I have a team for — a team that I can trust. They have the time, the context, and the technical depth to find better answers than I can from a distance.
So I step back, and let them do it.
Letting go is hard. But as a leader, my role has shifted from providing solutions to guiding the team towards finding them on their own. Instead, now I focus on asking the right questions.
As a coach, I ask questions that clarify thinking and remove mental biases. What problem are we trying to solve? What constraints are we optimizing for? What assumptions are we making? What would make this approach fail? Often, simply articulating the problem out loud exposes blind spots.
As a facilitator, I make sure friction gets removed. Is information flowing to the right people? Are priorities clear? Is another team blocking progress? Are decisions lingering without closure? Progress accelerates when the path is clear.
As a stakeholder, I question the team’s choices to keep the solution aligned with company goals. Are we solving the right problem? Is the trade-off acceptable for this stage? Are we optimizing for the right outcome?
When it comes down to it, letting the team be the master of its own success isn’t just about relieving me from doing the work I shouldn’t have been doing myself in the first place. It’s about building a group of high performers. You don’t keep teams motivated by having them execute your brilliant plans. You do it by giving them agency, support, and recognition. That’s how people grow.
Yes, sometimes intervention is necessary. Crises, structural risks, ethical boundaries. But those cases are the exception, not the rule.
I’m a problem solver at heart, and I will always be. But when it comes to leadership, I have learned to resist the urge. It’s not my job to solve every problem by myself.
My job is to guide my team to success.