Be a Leader: Remove Yourself as the Bottleneck
By Darryl Brown
One of the harder lessons of the last two years was realizing that my value wasn’t in solving problems. It was in making sure problems got solved.
Those sound similar. They are not. The first makes you a bottleneck. The second, if you get it right, makes your team stronger every time something goes wrong.
I learned the early version of this lesson before I became CTO, back when I was promoted to Director of Software. I’ve always had strong opinions, and as a senior developer on the team, I was used to voicing them freely and with conviction. When I stepped into that director role, I became aware and concerned that colleagues who were often my equal or superior in pure engineering terms might worry I’d use the position to enforce my views. So I made a conscious decision to take a backseat in technical discussions. To listen before speaking. To let others go first.
What I found surprised me. Most of the time, someone else would voice the opinion I was holding. My input wasn’t necessary. On the occasions when it was, it was usually to break a tie or to bring in context the team wasn’t privy to — the broader company picture, a strategic constraint, something that required the view from my seat rather than just a technical opinion.
There was another benefit I hadn’t anticipated. When I wasn’t the one introducing an idea, I could evaluate it more clearly. If I walked into a discussion with a formed opinion, that opinion carried its own momentum — a subtle pressure to see it validated. When someone else voiced the same thought, I had no stake in defending it. I could weigh it honestly against other ideas. Listening first increased my objectivity and made space for others.
That experience taught me something I wish I’d learned earlier: my voice and opinion were not nearly as important as I thought they were. I had smart people. The answers were already in the room. My job was to create the conditions for them to surface, not to be the one who provided them. Letting go of the need to control outcomes and trusting the team was a challenging lesson, but I’ve come to believe it’s one of the most critical to me in leadership.
That lesson didn’t stay in the Director role. I carried it directly into the CTO seat. The mechanism is the same: in meetings, I listen more than I speak. I try not to voice strong opinions or direct outcomes unless I genuinely believe my perspective is critical and wouldn’t otherwise surface. I respect what others bring to the table, and I’ve found that when I hold back, the table usually has what it needs.
What changed as CTO was the degree of trust. I’m not part of the daily work at this point. Problems get solved without me, not because I removed myself from the process reluctantly, but because the team is capable of solving them. My involvement tends to come when something requires an enterprise perspective: helping frame a situation for a customer, facilitating communication between departments, or bringing strategic context that the team doesn’t have visibility into. Those are the moments where my voice adds something. The rest of the time, the best thing I can do is stay out of the way and let smart people do their jobs.
That said, staying quiet is not the same as being passive. There are ideas I believe in strongly enough to champion — to introduce, repeat, and advocate for until they take hold. AI adoption is a good example. I’ve been pushing for our team to embrace AI tools for over a year, because I believe it’s strategically critical for us to stay competitive. I now have many champions on the team and we’ve adopted it wholeheartedly. That’s a different kind of leadership than solving a daily problem It’s about pointing at something on the horizon and saying, “We need to go there.” Once the team sees it too, they take it from there. I’ll write more about that in the next post.
A developer on our team described this dynamic better than I could when I asked what had driven our transformation:
“Identifying an area where we need improvement and giving team members the space to figure out the ‘how’ around that improvement helps us own the process and desire to optimize it.”
That’s exactly it. My job is to point at the thing that matters. The how belongs to the team. When they figure out the how, they own it. When they own it, they care about whether it works. When they care about whether it works, the quality of what gets built is different than it would have been if I’d handed them a solution.
The behaviors that make this possible are small. I ask more than I answer. When someone proposes a solution, I ask what problem it’s solving before evaluating whether it’s a good solution. When we debrief after an incident, we treat it as useful data and an opportunity to improve, not a mistake to explain away. None of those things require a process or a framework. They require consistent practice over time, and occasional awareness of when I’m defaulting back to the old pattern because the pull toward inserting myself is always there.
When I asked my team what they thought had driven our transformation over the last two years, none of them described a decision I made or a solution I provided. They talked about culture, safety, trust, and experimentation. They described an environment, not a leader with answers, but a set of conditions in which the team could find answers itself.
Some of those answers were generous in ways I won’t pretend not to appreciate. “Change starts at the top” — that’s me, and I’m comfortable owning that. But the more important validation was broader than any comment about my leadership. The culture and safety this team described are a group effort. I’ve played a significant part in building them. So has everyone else on this team. I’m comfortable taking some of the credit and leaving plenty on the table for the team.
Simon Sinek argues in “Leaders Eat Last” that the most effective leaders are not the ones with the best answers but the ones who create environments where people feel safe enough to bring their best thinking, take risks, and solve problems collectively. The title itself captures the principle: a leader’s job is to put the needs of the team first, to absorb uncertainty and pressure so that the people doing the work don’t have to. That framing resonated deeply with me. It’s a human-centric view of leadership that has nothing to do with authority and everything to do with conditions. A leader’s job in that model is not to be the answer. It’s to protect the conditions that allow the group to find the answer itself. That’s the job I’ve been trying to do. I don’t always get it right. But I think it is the right job.
Every problem you solve yourself is one your team doesn’t get to learn from.
The final two posts are about the two biggest bets we’re making on the future — the role AI is beginning to play in how we build software, and engineering quality earlier in the process.
