Things I’ve learned in my 10 years as an engineering manager
Non-obvious advice that I wish I learned sooner.
It’s been a while since my boss told me I needed to start hiring for my team. While I was at it, I should also handle onboarding... Since I knew the roadmap, I could take ownership of that... And because I knew the people, I could coach them in their careers.
I didn’t realize at the time, but he was dooming me to be an engineering manager.
Since then, I’ve worked across four companies as a manager, one as a founder, and another as a manager of managers. 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 standard definition for an Engineering Manager. If you pick two random managers, they can do very different things, even if they are at the same company.
In every company I’ve worked at, my role has never been the same. The only constant is that it’s 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 building careers, coordinating efforts, and navigating the organization to get resources for your team.
Small team? You’ll manage scope to match reality, and with less communication overhead, you might actually do some coding.
No PM? You own the product completely: validating features, prioritizing the roadmap, and talking to clients. This takes up most of your time because shipping features that don’t offer user value makes everything else pointless.
Reporting to the CEO? You’re now the link to sales, operations, and client communications.
The key is to identify where your team’s bottleneck lies in your software development lifecycle. You’ll probably shift between pillars as circumstances change, and that’s the point: the role requires flexibility.
Tip: Never ask the interviewer what they expect from a manager. Some managers assume their experience is industry standard and might find that question odd. Instead, ask about their daily life and the challenges that take up 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. Eventually, our team disbanded, and engineers scattered across other projects.
The most common reason companies fail is creating products that don’t deliver value to users, causing them not to 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 just deliver code but to use it to solve problems.
Code is valuable only when it benefits the end user. Sometimes, a no-code integration can outperform a custom solution. At times, it's better not to create a new feature at all to avoid maintaining a system. Teams that understand the problem, not just the spec, can pivot when necessary.
3. There is no such thing as a free lunch when it comes to processes
Every process trades time and attention for reliability or quality. The problem occurs when teams stop questioning if the trade is still worth it. Ceremonies become rituals. Metrics turn into goals. No one remembers why we spend an hour of our lives on this meeting.
Process bloat creeps in slowly. An engineer ships a broken UI to production. Designers complain, managers panic, and suddenly every PR requires designer approval. The whole team bears the cost of 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 varies based on context: team size, experience levels, and deadline pressure. What works for a mature team might not work for a new one. Keep questioning and iterating. If a process isn’t improving delivery, cut it.
4. Communicating downward requires 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 irreversible damage. They might not leave immediately, but they will 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 describe 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 clearly and focus on how the team will do about it. If you act scared, they’ll be scared too. Your goal is to get them thinking about the next steps.
5. Communicating up requires a strategy
I see managers walk into executive meetings saying, “We’re not sure what to do - maybe A, maybe B?” and then leave with orders to do Z, which doesn’t benefit the team or the project.
Executives can’t think of every possibility in detail - that responsibility lies with you and the person who owns the product (which, as we saw, could be you too). When a problem reaches the executives, it’s because a decision is needed, and they will make one.
People above you have limited time to focus on your specific issues. You can’t info dump on them. If they take a misguided action based on what you tell them, it will be your fault.
If you believe in something, clearly state your case, including the advantages and disadvantages. Don’t expect higher-ups to think for you. It’s okay to bounce rough ideas off your direct manager, but beyond that, refine your thoughts - no one will think harder about your problems than you and your team.
If you need a guideline, a document should be: context → problem → plan / alternatives → what support you need.
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. However, you need to stay off the critical path. As soon as you start handling essential tickets, you’ll block your team when managerial work pulls you away.
Coach (30%): Your performance as a manager is the sum of your team’s output. Coaching involves preventing problematic behaviors from becoming normalized, such as toxicity, repeated mistakes, and consistent underperformance.
It also means supporting engineers' growth by challenging them appropriately, providing the right feedback, and helping them develop skills they’ll carry forward.
Cheerleader (60%): Praise people more than you think you should. Validation is important. Most engineers prefer feeling appreciated over having a ping-pong table.
But give praise genuinely, not automatically. I once joined a team where retrospectives included 30 minutes of mutual praise - n-squared compliments every week. It felt hollow. Not every week has something extraordinary, and when praise becomes expected, it loses its impact. The hedonic treadmill is real.
Make your engineers’ wins visible beyond your team. Encourage them to pursue impact outside the team, and celebrate their achievements when they do.
Every team operates like a small company within the larger organization. I find that its morale also exists independently of the company's overall morale.
7. Your goal is for your team to 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 toward making that possible.
You’re too busy to be the bottleneck. If people keep reaching out to you for recurring tasks, delegate by teaching someone else to handle them. Point team members directly to each other or, even better, create group chats to facilitate natural discussions.
Don’t become the bus factor of 1. Train others so work continues smoothly even when you’re overwhelmed or unavailable.
Avoid making people feel they need your permission for small, reversible decisions. Empower them with agency. Request to stay informed about their decisions, but let them handle the technical side.
The reason you will do this is that managerial work can, and will, appear at the worst time. If you are the bus factor, you will be screwing your team when it happens. There are many engineers, but only one manager. Stay accessible for tasks that only you can handle.
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 without you constantly watching? If not, something needs to change—either in you or in them.
Trust isn’t about just technical skill. If I asked my current engineers (mobile and web developers) to build a Game Boy emulator from scratch, they wouldn’t know where to begin. They’d probably take months (some just weeks). But I’m sure they’d try their best to figure out how to run Pokémon Gold.
You need to trust both their abilities and their honesty:
If you can’t trust their skills at their level of experience, it’s your job to help them get better.
If you can’t trust their honesty, and you have good reasons not to, then you need to part ways.
9. Trust, but verify
Even great engineers get stuck without realizing it. Watching progress helps you spot when they need support before others see them as underperforming.
Processes like sprints and OKRs mainly focus on the “verify” stage (see, your manager does this too). They serve as a shared interface to ensure work gets done. This isn’t about lack of trust but accountability.
Verification involves using metrics and evidence. There are two types: quantitative and qualitative.
Quantitative is simple: PRs merged, points completed, code reviewed. You can glance at these, but decisions shouldn’t be based on them alone. If you could gauge engineer performance from numbers, managers wouldn’t be needed.
Knowing the Qualitative metrics shows a manager's worth. “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 insights depend on truly knowing your team. That’s why most “management AI tools” are doomed to fail. They only focus on quantitative metrics. They don’t attend your standups, don’t conduct 1:1s for you, and don’t know who’s quietly holding the team together. A good manager does.
10. Eventually delegate everything.
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 hold on to projects for many reasons. Sometimes it’s comfort - you know this system, you built it, and 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” mindset might be accurate, but in the long run, it’s not sustainable. Every time you do it yourself, you rob someone else from learning and ensure you’ll be doing it forever.
11. There is no free lunch when it comes to reducing risk
Be risk-averse, not risk-paranoid. You can’t account for every variable. Some things can’t be anticipated, and overcorrecting may be worse than the original issue.
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.
Think about second-order effects too: while you’re scheduling that seventh round, good candidates are accepting offers elsewhere. The best talent moves quickly. A slow, risk-averse process filters out exactly the people you wanted to hire.
If any of this resonated, my free online work-in-progress book goes deeper. If you’re a manager too, I’d love to hear what you’ve learned. Drop it in the comments!
This is really nicely written, and timely advice for me