Five years ago, I became a Technical Manager. I had strong opinions about software architecture, database design, and engineering best practices. I had much weaker opinions about people management, organizational design, and executive communication.
That imbalance nearly cost me. Here's what I've learned.
Leadership Is About Who You Develop, Not What You Build
In the first year, I measured my success by the quality of the systems I was involved in designing.
That's the wrong metric.
As a Technical Manager, you build leverage through people. The question isn't "did I make a good technical decision?" It's "did I develop engineers who make good technical decisions?"
The shift from maker to multiplier is real, and it's harder than anyone tells you.
Psychological Safety Isn't Soft — It's Infrastructure
I used to roll my eyes at "psychological safety." It sounded like HR language for avoiding hard conversations.
I was wrong.
Psychological safety is the condition that allows your team to tell you the truth — about technical debt, about unrealistic timelines, about their concerns with a technical direction. Without it, you're leading with incomplete information.
How you respond when someone brings you bad news determines whether you'll hear bad news in the future.
The Executive Communication Gap
Most engineers who become managers underestimate how much of the job is communicating upward.
Executives speak in outcomes, not implementations. They want to know:
- What business problem does this solve?
- What's the timeline and the risk?
- What does success look like?
- What do you need from me?
Learning to translate between engineering reality and executive language took me two years. It's the skill I wish I'd developed faster.
The key insight: executives aren't asking for less detail because they're unsophisticated. They're asking for the right level of abstraction for their decision. Master that abstraction, and you become their most trusted technical partner.
Delivery Management Is a Skill
I thought delivery management was project management — Gantt charts and status updates.
It's actually about:
- Identifying the critical path (what must happen for everything else to happen)
- Removing blockers before they block
- Making the right trade-offs when scope, time, and quality are in tension
- Communicating realistic timelines without sandbagging
The most dangerous person on a team is the engineer who says "it's almost done" for three weeks in a row. Part of your job is creating an environment where people surface delays early, so you can adjust rather than react.
Culture Is What You Tolerate
You don't build culture by putting values on a wall. You build it through thousands of small decisions.
- Do you tolerate late code reviews? You're building a culture of slow feedback.
- Do you tolerate blame in post-mortems? You're building a culture of fear.
- Do you tolerate "this is how we've always done it"? You're building a culture of stagnation.
The inverse is equally true. When you celebrate when someone raises a concern early, when you thank someone for admitting they don't know something, when you publicly recognize great work — you're building the culture you actually want.
The Hardest Conversations Are the Most Important Ones
Performance issues don't resolve themselves. The engineer who's struggling doesn't suddenly figure it out. The team lead who's not growing into the role doesn't magically develop the skills.
Avoiding difficult feedback is a kindness that feels kind in the short term and is profoundly unkind over time. You rob people of the information they need to grow.
I've had to tell engineers their job was at risk. I've had to tell team leads they weren't ready for the next level. Every time, I did it with specificity, with care, and with a genuine belief that feedback is a gift.
Not every one of those conversations ended well. But every one of them was the right conversation to have.
What Makes a Great Engineering Culture
After five years, here's my shortlist:
High bar, high support. High standards without support breed burnout. Support without standards breeds mediocrity. Both together create excellence.
Blameless post-mortems. Systems fail. People make mistakes. The question is what you learn, not who to punish.
Ownership, not just execution. Engineers who own outcomes think differently than engineers who just execute tasks. Build ownership.
Disagreement is welcome, decision is final. Great teams debate hard. But once a decision is made, everyone executes it. Passive resistance is corrosive.
Write things down. Decisions, context, architecture rationale. Teams with good institutional memory are dramatically more effective.
Five years in, I'm still learning. The engineering part I mostly have figured out. The leadership part — I suspect that one never stops being a work in progress.
That's what makes it interesting.