After years of leading engineering teams, I've learned that the best managers don't manage work — they create the conditions where great work happens naturally. The distinction sounds subtle, but it changes everything about how you spend your time.
Context over control
Early in my leadership journey, I made the classic mistake: I tried to be involved in every decision. I reviewed every pull request. I weighed in on every architecture discussion. I thought thoroughness was the same as effectiveness.
It wasn't. What I was actually doing was creating a bottleneck — and worse, signaling to my team that I didn't trust their judgment.
The shift came when I started focusing on context instead of control. Rather than telling people what to do, I made sure they understood:
- What problem we were solving and why it mattered
- What constraints we were operating under
- What success looked like from the customer's perspective
- What trade-offs were acceptable and which weren't
Armed with context, smart people make good decisions. You don't need to make the decisions for them.
The power of one-on-ones
If I had to keep only one management practice, it would be weekly one-on-ones. Not status updates — those belong in standups. Real conversations about growth, challenges, and what's on someone's mind.
The most important question I've learned to ask is simply: "What's on your mind?" Then listen. Really listen. Not to formulate a response, but to understand.
The quality of your relationships with your direct reports is the single best predictor of your effectiveness as a leader.
Over time, these conversations build a foundation of trust that makes everything else easier — difficult feedback, ambitious goals, navigating uncertainty.
Protect the team's time
One of the most undervalued things a manager can do is say "no" to things so their team doesn't have to. Every meeting that doesn't need to happen, every status report that no one reads, every process that exists because "we've always done it" — these are taxes on your team's ability to do meaningful work.
I've made it a habit to audit my team's calendar and commitments quarterly. The question isn't "is this useful?" — almost everything is somewhat useful. The question is "is this the best use of their time given what we're trying to accomplish?"
Hire for trajectory
When building a team, I've learned to weight trajectory over current skill. Someone who's grown significantly in the last two years and is hungry to learn will often outperform someone with more experience but less momentum.
This doesn't mean credentials don't matter. But the best hires I've made were people who were clearly on an upward arc — curious, self-aware, and resilient. Those traits compound over time in ways that raw technical skill alone doesn't.
Make it safe to fail
Innovation requires experimentation, and experimentation requires failure. If failure carries consequences — social, professional, or otherwise — people will stop taking risks. And a team that doesn't take risks doesn't build anything remarkable.
This doesn't mean accepting carelessness. It means distinguishing between failures of effort and failures of learning. The first is a problem. The second is an investment.
Leadership isn't about having all the answers. It's about creating an environment where the team can find the answers together — and enjoy the journey of getting there.