I have one job: get out of people’s way. Everything else is just details.
That’s what I told my CEO during my first week as CTO, and his face was priceless. But after two decades of building and leading engineering teams, I’ve learned that the best leaders aren’t the ones with all the answers – they’re the ones who help others find them.
When I stumbled into coaching training a good 10 years ago (mostly to shut up our Head of People who wouldn’t stop recommending it), I didn’t expect it to fundamentally rewire my approach to leadership. But here we are. Let me share four counterintuitive lessons that transformed how I lead.
1. Be the Chaos Translator
We’ve all been there – sitting in a meeting that feels like a verbal mosh pit, everyone talking past each other, and you’re wondering if you’re the only one lost. Plot twist: you’re not.
I used to think being a leader meant having all the answers. Now I realize it’s about asking the right questions and – more importantly – being the person who can distill chaos into clarity.
Example: Last month, our backend team was spiraling into a debate about microservices architecture. Instead of jumping in with my opinion, I simply said: “So what I’m hearing is we’re worried about service boundaries impacting development speed. Is that the core issue here?”
The room went quiet. Then someone said, “Actually, no – we’re more concerned about monitoring overhead.” Boom. Real problem identified, solution found in 20 minutes.
2. Turn Arguments into Investigations
Here’s a radical idea: the next time someone storms into your office fuming about a production issue, don’t match their energy. Instead, get curious.
I learned this the hard way after a particularly heated exchange with our DevOps lead about deployment protocols. Mid-argument, I caught myself and asked, “What’s making this change feel urgent to you?”
Turns out he wasn’t just being difficult – he had spotted a security vulnerability that needed immediate attention. My defensive stance nearly buried critical information.
3. Kill Your Inner Micromanager
“But I’m responsible for the outcome!”
That’s what the voice in your head screams when you see a junior dev taking an approach you wouldn’t. Silence that voice. It’s lying to you.
The truth? Every time you swoop in to “fix” something, you’re teaching your team that:
- Their judgment isn’t trusted
- They don’t need to think things through
- You’ll always be there to clean up
Want to scale your team? Start trusting them to be, as coaching taught me, “naturally creative, resourceful, and whole.”
4. Sometimes the Best Move Is No Move
We’re conditioned to act. Ship features. Fix bugs. Optimize performance. But sometimes, the best thing you can do is… nothing.
I recently watched two senior engineers argue about an architectural decision. My old self would have jumped in with a solution. Instead, I waited. They eventually arrived at a better solution than I would have proposed.
The real skill? Knowing when to:
- Let a team struggle through a problem
- Give space for conflicts to resolve naturally
- Allow people to learn from their mistakes
The meta-lesson underneath all of this? Understanding boundaries. Knowing where your responsibilities end and others’ begin isn’t just good leadership – it’s essential for scaling both your team and yourself.
Think of it this way: your job isn’t to be the smartest person in the room. It’s to create an environment where smart people can do their best work.
PS: Want to test if you’re creating that environment? Take a week off. If everything falls apart, you’re not leading – you’re controlling. Trust me, I learned this one the hard way. Twice.