Lessons learned after 10 years as an engineering manager
Non-obvious advice that I wish I learned sooner.
It’s been 10 years since my boss told me we needed to start hiring. And since I was responsible for hiring, I should handle onboarding too… And since I knew the roadmap, I could own that… And since I knew the people, I could coach them in their careers.
I didn’t know at the time, but he was dooming me to be an engineering manager.
Since then, I’ve worked across four companies as a manager and met some amazing people. I will skip the standard advice and lessons on Engineering Management and focus on the non-obvious ones.
1. The “well-defined engineering manager role” is a myth
There is no standardized definition of an Engineering Manager. If you pick two random managers, they can do wildly different things. Even if they are at the same company.
In every company I’ve worked at, my job has never been the same. The only constant is that the role is defined by the team's needs, requiring you to balance across four pillars: Product, Process, People, and Programming.
Some examples:
Large team? Say goodbye to programming. You’ll focus on careers, coordination, and navigating the org to get resources for your team.
Small team? You’ll manage scope to match reality, and with less communication overhead, you might actually code.
No PM? You own the product entirely: validating features, prioritizing the roadmap, and talking to clients. This dominates your time because shipping features with no user value makes everything else pointless.
Reporting to the CEO? You’re now the bridge to sales, operations, and client communications.
The key is identifying where your team’s bottleneck lies. Examine your software development lifecycle. You’ll likely shift between pillars as circumstances change, and that’s the point: the role demands flexibility.
Interview tip: Don’t ask what a manager is expected to do. Some managers assume their experience is industry standard and will look at you funny. Instead, ask about their daily life and what challenges consume most of their time.
2. Everyone needs to care about the Product
A few times in my career as a developer, I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. We were doing it because we were told to. Morale was low. We felt we were working on things that didn’t matter - and we were. Every time, eventually, our disbanded and engineers scattered across other projects.
The most common reason companies fail is building things that don’t provide value to users, who then don’t pay.
“Oh, but I have a PM for that,” you might say. But having a PM is not enough. Everyone needs to care about the product.
Your team isn’t paid to deliver code but to use it to solve problems. Code only has value when it affects the end user. Sometimes a no-code integration beats a custom solution. Sometimes it's better not to do the work at all to avoid maintaining a system.
Teams that understand the problem, not just the spec, can pivot when needed rather than clinging to a bad solution just because the code is already written.
3. There is no free lunch on processes
Every process trades time and attention in exchange for reliability or quality. The problem is when teams stop questioning whether the trade is still worth it. Ceremonies become rituals. Metrics become goals. Nobody remembers why we do the things we do.
Process bloat creeps in slowly. An engineer ships broken UI to production. Designers complain, managers panic, and suddenly every PR needs designer approval. The whole team pays tax for a single isolated incident.
Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. You stop looking at outcomes and just make sure you’re doing the process right. The process is not the thing. It's always worth asking, do we own the process or does the process own us?
— Jeff Bezos, 2016 Letter to Shareholders
The right process depends on context: team size, experience levels, and deadline pressure. What works for a mature team won’t work for a new one. Keep questioning, keep iterating. If a process isn’t making delivery better, cut it.
4. Communicating down needs transparency
Your direct reports are the people who interact with you the most. They look to you for leadership and clarity, and trust that you’ll tell them what they need to know.
That’s why lying or withholding information that affects them causes irreparable damage. They might not leave right away, but they’ll resent you. I have a friend who still resents a manager for a lie told three years ago. They found another company, but they’re still angry about it.
“Trust arrives on foot and leaves by horseback.”
- Old Dutch saying
I've seen some managers describing the role as “a shield that blocks everything from above”, and I disagree. A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them.
Telling the team: “Our users aren’t thrilled so far. We need to find ways to better serve them. The project risks cancellation if we don’t.” That’s fair game. They deserve to know.
When you do deliver hard news, state it plainly, and focus on what the team will do about it. If you act scared, they’ll be scared too. Your job is to get them thinking about the path forward.
5. Communicating up needs a strategy
I see managers walk into exec meetings with “we’re not sure what to do - maybe X, maybe Y?” and walk out told to do Z, which serves neither the team nor the project.
Execs can’t ponder every decision. When a problem reaches them, it’s because a decision needs to be made, and they’ll make one.
People above you have limited time to think about your specific problems. You can’t info dump on them. If they take a misguided action based on what you told them, that’s on you.
If you believe in something, state your case clearly, outlining the advantages and drawbacks. Don’t expect higher-ups to think for you. It’s fine to bounce half-formed ideas off your direct manager, but beyond that, cook a bit more - no one will think harder about your problems than you.
The further up you go, the more this matters. Structure your message plainly: context → problem → plan → what support you need.
By the time you reach a skip-level, the options should be clear. They’re used to situations requiring immediate action, and that’s the response you’ll get.
6. You are 10% player, 30% coach, and 60% cheerleader
Player (10%): Yes, only 10%. You might take on work your team isn’t excited about, but that matters: CI/CD improvements, flaky tests, process tooling. But you need to stay off the critical path. The moment you start taking essential tickets, you’ll block your team when the managerial work pulls you away.
There are many engineers, but only one manager. Keep yourself available for work that only you can do.
Coach (30%): Your output as a manager is the sum of your team’s output. Coaching means ensuring problematic behavior doesn’t become normalized: toxicity, repeated mistakes, consistent under-delivery.
It also means helping engineers grow: stretching them with the right challenges, giving the correct feedback, and building skills they’ll carry forward.
Cheerleader (60%): Praise people more than you think you should. Validation matters. Most engineers prefer feeling celebrated to having a ping-pong table.
But praise genuinely, not reflexively. I once joined a team where retros had 30 minutes of mutual praise - n-squared compliments every week. It felt hollow. Not every week has something grand, and when praise becomes expected, it loses meaning. The hedonic treadmill is real.
Make your engineers’ wins visible beyond your squad. Encourage them to aim for impact outside the team, and celebrate them when they do. Every squad is like a small company within the larger one - its morale often runs independent of the company’s.
7. Your goal is to have your team thrive without you
Most managers don’t plan to become bottlenecks. It happens gradually. A critical tool needs an owner, and you think, “I’ll handle this for now.” Someone needs to be the point of contact for another team, and it’s easiest if it’s you. Technical decisions keep landing on your desk because you’re the one with context. Before you know it, work stops without you.
If you can’t take a month off and return to a well-functioning team, you need to work towards making that possible.
You’re too busy to be the bottleneck. If people keep reaching you for recurring tasks, delegate: teach someone else. Point people directly to each other, or even better, create group chats and let discussions happen naturally.
Don’t become the bus factor of 1. Teach others to do what you do, so things keep moving even when you’re overwhelmed or unavailable.
Avoid making people feel they need your permission for small decisions, especially reversible ones. You want them to have agency. Ask to be kept in the loop on whatever they decide, but let them make the technical decisions.
8. You can’t succeed without trusting your team
Micromanagers micromanage because they don’t trust.
Ask yourself: can you trust every engineer on your team to do their best to complete something without you looking over their shoulder? If not, something needs to change - either in you or in them.
Trust isn’t about technical proficiency. If I told my current engineers (mobile and web devs) to build a Gameboy emulator from scratch, they wouldn’t know where to start. They’d probably take months (some just weeks). But I’m certain they’d try their best to find a way to run Pokémon Gold.
You need to trust both their skills and their honesty. If you can’t trust their skills at their level of seniority, it’s your job to help them improve. If you can’t trust their honesty, and you have clear reasons not to, then you need to part ways.
9. Trust, but verify
Even great engineers get stuck without realizing it. Keeping an eye on progress helps you catch when they need support before others see them as underperforming.
Processes like sprints and OKRs are mostly about the “verify” part (see, your manager is doing this with you too). They’re a shared interface to ensure things get done. This doesn’t mean lack of trust, but accountability.
Verification means using metrics and evidence. There are two kinds: quantitative and qualitative. Quantitative is easy: PRs merged, points completed, code reviewed. You can glance at these, but never base decisions on them alone. If you could derive engineer performance from numbers, managers wouldn’t be necessary.
Qualitative metrics are where you prove you’re worth your salt. “This engineer has fewer PRs, but they’re always watching Slack and hopping into calls to help others.” “This engineer always discusses tickets with product first - their output ends up far better than our original specs.” “This engineer explains complex concepts in ways everyone can understand and makes other teams use our tool better.” These observations require knowing your team.
This is why most “management AI tools” are set up for failure. They only see quantitative metrics. They don’t sit in your standups, don’t watch the Slack channels, don’t know who’s quietly holding the team together. A good manager does.
10. Delegate everything eventually
Stop having pet projects; that’s a Staff Engineer’s domain. For a manager, every project is cattle: it needs to be completed, automated, delegated, or cancelled.
Managers cling to projects for many reasons. Sometimes it’s comfort - you know this system, you built it, it feels good to stay close to it. Sometimes it’s identity - you want to stay “technical” and not lose your edge. Sometimes it’s fear - you don’t trust it’ll be done right without you. None of these is a good reason to hold on.
The “I can do it faster myself” thinking might be correct, but in the long term, it’s not sustainable. Every time you do it yourself, you rob someone of the chance to learn, and you guarantee you’ll be doing it forever.
11. There is no free lunch in reducing risk
Be risk-averse, not risk-paranoid. You can’t account for every variable. Some things you can’t anticipate, and overcorrecting can be worse than the original problem.
Hiring is where I see this most often. After a bad hire, managers start requiring referrals, but almost anyone, no matter how unskilled or dishonest, can find someone to vouch for them. Others add more interviewers to the panel, thinking more eyes means better vetting.
The opposite happens: each interviewer becomes more lax, expecting someone else to be “the bad guy.” Responsibility gets diluted. Three great interviews beat seven mediocre ones.
There’s a worse second-order effect too: while you’re scheduling that seventh round, good candidates are accepting offers elsewhere. The best talent moves fast. A slow, risk-averse process filters out exactly the people you wanted to hire.
If any of this resonated, my free online book goes deeper. If you’re a manager too, I’d love to hear what you’ve learned - drop it in the comments.