I've tried to write this post many times. Each attempt sprawled into something either too abstract or too specific to a single situation. So instead of a manifesto, here are ten lessons I keep coming back to. I'm sure I'll keep refining them over the years.
Some context on where I sit. I work on a roughly 40-person engineering team, assist four other experienced EMs, work in DevTools SaaS, am venture-backed, and try to hire extremely competent and experienced people. The exact answer here is subjective and dependent on who's in the room, what the team is building, the industry, and more. But these ten things feel durable.
Make the company successful
The number one job of an engineering manager is to make the company successful. Not to protect your reports and make sure they have a great time. Not to create perfect product or maximize uptime. Those are implementation details. The root goal is company success.
Hopefully this is nearly perfectly aligned with making your boss happy. Everyone has a boss. ICs have EMs. EMs have directors. Directors have founders or VPs. Those execs have board members. Board members have LPs. It's bosses all the way down.
In good organizations, the motivations of folks higher in the chain are ideally very pure and balanced. Founders tend to have extremely pure incentives because they're entirely paid in equity, for example. In cases where you as an EM disagree on what's most important, it's worth having a healthy conversation and sharing your earnest thoughts - though keep in mind that others might have a wider situational view.
Regardless, the goal is to constantly execute in the best interest of the company.
The worst thing you can be is chill
A chill manager is a bad manager. Intensity is good. Smart, ambitious people want an intense manager. They want someone who challenges them to reach their best work, who sets up fair constraints and tees up big goals. They want a manager who calls out mistakes and is direct when others don't try hard enough.
Think about a sports coach from a movie. Upper-end software engineering is much like a sport - groups of highly paid superstars collecting onto a team to see what's possible if they all work together hard. And as an EM, you get to be the coach.
A chill coach does not make for a championship team. The best players won't join a team with a laidback, disengaged, shy coach. Be intense. Lean in.
There's always time to be human
Intensity needs balance. Intensity doesn't mean being mean. You can always get coffee with someone after a tough meeting. You can always give someone a call and talk it out. You can fire someone, but still check in with them on a human level and do your best to help them forward. You can ask about life outside of work. You can make friendships. You can be vulnerable and empathetic with the people you work with.
You're not a machine. You're a real person with quirks and emotions - and so is everyone else. It's a failure to hide these things, to shy away from it, to be robotic. The world's best manager is tactful and professional, but also vulnerable, honest, and human.
Charisma matters
Charisma is a real skill. But I never see it explicitly show up on an interview scorecard or performance review. Nearly every function at a company benefits from charisma, but as an EM it matters a ton.
You're in the business of building humans, teams, and alignment. You chat with people to learn information, think about it, and pass it back out. You recruit, welcome, give feedback, and fire. You help people who are having bad days, and you make yourself part of why others don't quit.
All of these actions benefit from being simply charismatic. Be a good listener. Say things well, in a way that makes others feel good. Be someone folks want to talk to and spend time with. Be magnetic and motivating. Be someone that others want to work with, and you'll magnetize incredible people onto your team.
A charismatic engineering manager is an amazing recruiter, retains well, has their feedback more deeply received, and can have hard decisions better accepted.
Map out the world
As a manager, your job is to build and maintain immense context about everything happening within the company. Who is building what? Who are the key managers? Who are the key ICs that everyone mentions deferring to - the super nodes? When a decision is being made, who needs to sign off? What is the shadow org chart? How are headcount decisions made? Comp? How does the company fire people? How does the sales team talk to the engineering team? When does design get involved on projects? What are the biggest grievances on the team? Where is the current bottleneck within EPD?
The list goes on. There's a perpetual project around meeting everyone possible at the company, trying to fill in the map of the world. This is a hard and long project, but an incredibly valuable one that your ICs have no time to do. If you can grok the org map and all of its nuances, you become an invaluable router and advisor. When people ask you a question, you know the spicy nuance behind different answers. You know who cares about different outcomes. And when you don't know the answer, you know exactly who does - and you've already had coffee with them and can quickly DM.
With incredible context on the company, you can better guide IC projects within your sphere. You can nudge towards impact, consider who will love and hate different choices, publicize correctly, and unblock by cutting to exactly the right person and concern.
It's not that ICs can't build context on the company - any smart person can - but ICs don't have time. They need to actually build. Focus in on the weeds and code. So we divide and conquer, and managers take on the critical responsibility of assembling org context.
Hire great people and fire low performers
Part of being an amazing manager is cultivating an incredible team. There are three ways to do it: hire great players, grow existing players, and fire the lowest performers.
An amazing manager does all three. When bringing on new players, the goal is to raise the average of the team. This is easier said than done - you might not have access to incredible candidate flow, or your average might already be very high. There are challenges around quantity versus quality, differences between level and slope, and spiky versus smooth skill sets. Despite that, bring in new people and raise the average. Befriend recruiting. Execute interviews and sell calls. The best managers I know spend more time with their recruiting team than their ICs - it's often one of their first meetings coming into a company. And if your recruiting team is small or bad: congrats, you're now the recruiting team. Because it's your job to ensure new bar-raising engineers end up on your team one way or another.
Second, raise the people in the room. This is coaching. Tell people how they can improve. Build awareness and give opportunities to do better. Partner and pair folks. The most amazing managers will quickly, charismatically, and directly tell people how they can do better - and are loved for it. Bad managers are slow and afraid to tell others how to improve.
Third, fire people in the bottom 10-20% on the team. This is critical - many managers are afraid to fire. But if you don't, no one will. It's your job. Mathematically, if your team skill resembles a bell curve, then firing the bottom percentile routinely will raise the average. It frees up heads for new hires at average or above. It shows the team that you don't tolerate bottom performance. Identifying exactly how strong each person's performance is can be tricky - but I've found that every manager can stack rank their team if they really have to. Consider the bottom name on that stack rank. Would you prefer a random new hire to that person? Can you trust that bottom person with the next critical project the team takes on? Likely, you need to fire.
I often see reservations around firing due to politics. Someone might be bottom percentile, but net-value-positive on the team. Firing them decreases the team's net output, and the org might not effectively backfill. Firing is only easy when hiring is going well - when hiring has dried up or fallen behind, firing is scary. I empathize. The solution is to ensure that hiring is smooth and effective as soon as possible. Great hiring unblocks firing concerns, and they work hand-in-hand in cultivating a great team. And remember - this is your job.
Be 20% flexible on everything
It's a failure as an amazing manager to be too rigid, and it's also a failure to be too flexible. The ideal balance is around 80% strict and 20% flexible. Should you break a comp band for a new hire? Usually no, but it's a mistake to never. Should you let that person work remote? Usually no, but sometimes. Is it okay to ship late? To cut a corner? 80% of the time, don't - hold strong. But 20% of the time, sure.
Everything has nuance. Leave room to bend the rules, but don't skip rules and don't fall into broken windows. The benefit of a human manager with awareness, feelings, and fuzzy decision-making is that you can tactfully decide when and where to be flexible. A policy and a robot can't.
Cultivate lieutenants
Call them "right hands." "Lieutenants." Whatever you want - every amazing leader has a few. Individuals who are uniquely loyal, high performing, and overcompensated. Find or hire these people, reward them with access, information, and compensation. In return, use them as an extension of yourself. Mindmeld so they can represent your values when you're out of the room.
Source information from them for max context building - especially technical visibility that you're likely missing. An amazing manager can't be everywhere at all times. You have blind spots in meetings, in code, in conversations you're not part of. Lieutenants extend your reach, visibility, and impact.
Lieutenants aren't a formal title and don't show up on org charts. But if correctly established, other aware individuals at the company should be able to point to a manager and call out their one to three lieutenants. It's not purely invisible.
Live in dissonance
Really strong engineers sometimes struggle with dissonance. In science and technical systems like code, dissonance is a sign that something is wrong and will break later. But in management, you need to live in it. Be comfortable with it. Identify it, be aware of it, and then sit in it.
What do I mean? Maybe one engineer tells you they need a pay raise or they'll quit, but you know the company isn't issuing raises this quarter and you're not going to make an exception. Maybe the sales team says quality is uncompromisable, but the product team needs their launch to happen or they'll explode. And you sit in both rooms and nod. You hear the feelings, you empathize, you occasionally connect the differences - but many times you just sit in the dissonance.
A lot of dissonance is incorrect to solve. To solve it requires distraction, hurt feelings, exceptions. Sometimes sitting in the dissonance and letting it pass organically is the most productive thing. Knowing when to intervene and when to just accept that things are broken and suboptimal is the art of a great manager - and more often than not, absorbing the dissonance so others can focus is the best choice.
You're an amazing manager because you can hold so much conflicting information in your head when others would explode. This is also an organic result of cultivating tons of context. If you really understand everything that's happening - all the desires and motivations across the company - you'll be aware of hundreds of misalignments and disconnects. It's not productive to solve them all. The job is to swim through the chaos, gently guide towards the right long-term outcome, and absorb the intermediate state.
Be slow to change
Great managers are busy as hell. They're in 1:1s, writing docs, holding meetings, and working late. Much of this work is absorbing context, hiring, and aligning individuals. But amazing managers, surprisingly, are slow and hesitant to change anything - for good reason.
A great engineer sees a bug and immediately fixes it. A great manager sees an organizational bug and waits. Find the Chesterton fence. Is there a reason something is broken? Is this a one-off or a larger pattern? Does it matter that we fix it now, in a world where 30 things are organizationally broken? Fixing it will distract a ton of people - is now the right time? Will we drift to a future state where this self-resolves anyway?
Many teams could benefit from being reorged. Product priorities constantly shift, meaning that at any moment, team arrangements are slightly suboptimal. But just wait. There's a cost to changing things - it distracts, and often the change has its own inaccuracies. You can live in a suboptimal team state for a long time, and waiting creates new information.
Maybe a bad deployment breaks the site. Should you call a post-mortem? Should you mandate that all downtimes now require post-mortems? Should you set up an on-call rotation? The devil is in the details, but the best managers are slow to act. They wait, watch for a pattern, gather more information. If something is a real fire demanding change, it'll likely still be an urgent problem in a week or a month. If it's just a passing spike, you won't even remember it in a month.
Amazing managers spot issues and then wait to see if they self-resolve or are still a fire later. In a world of twitchy ICs, managers can be incredible ballasts. Solve short-term problems by empathizing, talking, being human, pondering changes but not enacting them quickly. Almost always with management, less is more, and slow changes are good.
This is a living post. More ideas will be added over time.