Why it works: Numbers perform well, “learned the hard way” creates emotional connection, under 60 characters
Leading a software engineering team is like conducting an orchestra where every musician thinks they could do your job better, half of them are wearing noise-canceling headphones, and the sheet music changes every sprint. After five years of managing engineers—and somehow still being invited to their Slack channels—I’ve learned a few things about keeping both my sanity and their respect intact.
1. Technical Credibility Is Your Currency
You don’t need to be the best coder in the room anymore, but you absolutely need to understand what your team is building. Nothing loses respect faster than a manager who can’t grasp the difference between a database migration and a API endpoint.
I spend 30 minutes every morning reviewing pull requests. Not to micromanage, but to stay fluent in our codebase. When Sarah explains why her refactoring will take three days instead of one, I need to understand whether she’s being thorough or avoiding the grunt work.
The key: Stay technical enough to have credible conversations, but delegate the deep work to people who are better at it than you.
2. Protect Them from the Chaos
Your job isn’t to shield your team from all problems—it’s to shield them from unnecessary problems. Engineers need focus like plants need sunlight. Every context switch costs them an hour of deep work.
When Product wants to “just quickly ask the team” about a feature idea, I redirect it to myself first. When a executive wants a status update, I provide it without pulling three engineers into a meeting. Your team’s calendar should look boring. Your calendar should look like a disaster.
I track “interruption debt” like technical debt. Every unplanned meeting or urgent Slack thread goes on a mental ledger. When it’s too high, I push back harder on new requests.
3. Make Decisions, Then Explain Them
Engineers respect decisiveness, even when they disagree with the decision. What they can’t stand is ambiguity masquerading as collaboration.
Bad approach: “So, what do you all think we should do about the deployment pipeline?”
Better approach: “We’re moving to containerization by Q2. Here’s why, here’s the plan, and here’s where I need your input on implementation.”
Notice the difference? You’re not asking permission—you’re providing direction and inviting expertise. There’s a time for democratic brainstorming, but most decisions need a decider.
4. Career Growth Isn’t Just About Promotion
Not everyone wants to be a senior engineer or tech lead, and that’s perfectly fine. Some people genuinely love solving problems in their current role. Your job is to figure out what each person actually wants.
I have quarterly “career design” conversations that have nothing to do with performance reviews. We talk about what energizes them, what drains them, and what skills they want to build. Then I try to align projects accordingly.
Marcus wanted to get better at system design but hated front-end work. So I staffed him on our API redesign and found someone else who loved React. Everyone’s happier, and the work gets done better.
5. Transparency Builds Trust (Even When the News Is Bad)
I used to think I should only share information once I had all the answers. That was stupid. Engineers are pattern-matching machines—they’ll notice something is off and fill in the gaps with worst-case scenarios.
When our funding got tight last year, I told the team before I had a solution. I shared what I knew, what I didn’t know, and when I’d have more information. The relief was palpable—not because the situation improved, but because they weren’t left wondering.
Bad news delivered honestly is always better than good news delivered late.
6. Code Reviews Are Culture Reviews
How your team conducts code reviews tells you everything about your culture. Are they constructive or condescending? Educational or just critical? Thorough or rubber-stamped?
I make a point to review PRs not just for code quality, but for comment quality. When I see “This is wrong,” I push back: “Can you explain what would be better and why?” When I see someone writing a mini-tutorial in a comment, I publicly thank them.
The tone you set in code reviews will permeate every other interaction your team has.
7. Sometimes the Best Thing You Can Do Is Get Out of the Way
My team once spent two weeks debating whether to use REST or GraphQL for a new service. I had an opinion, but I also noticed something interesting: they were teaching each other. The junior engineers were learning from the seniors, and everyone was researching trade-offs.
So I stayed quiet. When they finally came to me with a decision, it was well-reasoned and had complete buy-in. Could I have saved them time by just choosing? Sure. But they grew more from that debate than from any decision I could have handed down.
Know when to lead from behind.
8. Celebrate the Unsexy Wins
Everyone notices when you ship a big feature. No one notices when you prevent a production incident with good monitoring. No one celebrates the tech debt you paid down or the documentation you actually wrote.
But those are the things that compound. So I make sure we celebrate them. When Jordan spent a week writing comprehensive error handling that prevented three potential bugs, I made sure the whole company knew about it in our demo. When the team hit 90% test coverage, we took an afternoon off for a team outing.
Make the boring work visible and valued.
9. Your Mood Is Contagious
On days when you’re stressed about deadlines or frustrated with stakeholders, your team feels it. They’ll work anxious, code defensive, and communicate less.
I’m not saying fake it. I’m saying be intentional about what you bring to every interaction. Before I join a standup, I take three deep breaths. Before I give feedback, I check: Am I doing this because it needs to be said, or because I’m in a bad mood?
Your team deserves a leader who manages their own emotions, not one who makes their emotions everyone else’s problem.
10. Admit When You’re Wrong (Quickly and Clearly)
Last month I pushed the team to hit an aggressive deadline. We made it, but two people burned out and quit a month later. I was wrong to push that hard, and I told the remaining team exactly that in our retrospective.
“I prioritized the deadline over your wellbeing, and I lost two great engineers because of it. I’m sorry, and here’s what I’m changing going forward.”
Did it undo the damage? No. But it rebuilt trust. Engineers respect leaders who can say “I screwed up” more than leaders who never screw up at all.
The Bottom Line
Leading engineers isn’t about being the smartest person in the room or having all the answers. It’s about creating an environment where smart people can do their best work, protecting them from nonsense, giving them direction when they need it, and getting out of their way when they don’t.
Some days you’ll still want to scream into a pillow. Some days they’ll still think you have no idea what you’re doing. But if you focus on building trust, staying technical enough to be credible, and genuinely caring about their growth, you’ll be fine.
And they might even invite you to the next team happy hour.
What’s been your biggest leadership lesson? Drop a comment below—I’m still learning this as I go.
