12 takeaways from my first year as an Engineering Manager

Originally published on my newsletter here.

About a year ago, I became an Engineering Manager at Brex. The transition was fairly straightforward: I was a Staff Engineer who had indicated interest in trying out the managerial path since it seemed like a no-brainer at the time after reading about the Engineer/Manager Pendulum. Most companies are willing to give high-performing senior/staff engineers an opportunity to transition into this role when a need arises. By doing so, they get a manager who deeply understands the technical systems and can empathize with the individuals, and it also opens up opportunities for other senior engineers to fill the senior/staff leadership void that such a transition creates. It's a win-win all around most of the time.

Prior to starting as an engineer at Brex in 2020, I was a founder across two smaller tech startups for 7+ years. That meant not only managing employees (and shareholders), but also being a driver for product/strategic direction, engineering, technical decisions, operational processes, customer support, UX design, and everything else you can think of in between those things. All this to say that becoming an EM was not my very first time in a leadership role. Being an ex-founder made a lot of the job way easier than it normally is for a first-time Engineering Manager. However, this was my first time being in the very specific job of a "frontline Engineering Manager at a tech company" where you are expected to do things like writing formal performance reviews, going through calibrations, putting up people for promotions, aligning your team's strategy with the rest of the company, negotiating your team's quarterly deliverables with leadership, and so on.

As I reflect back on the past year, here are 12 takeaways that have shaped my views on engineering management. Most of the ideas here are not my own, and I've tried to credit as much as I could in footnotes.

1. Start with the customer. If someone is working on something that you can't justify is going to make our customers' lives better, ask open questions to learn more about why they're doing it. More often than you'd guess, people are just trying to do the next thing on a list, and not the next highest ROI thing that the team can be working on. Connect every output of your team back to the customer and how it improved their lives. Because, if it didn't, it probably wasn't worth your team's time.

2. Practice essentialism[1]. Say "no" more than you think you should. Do less, but better. If you think that a request being made of your team is busywork motivated by someone covering their bases, and not something that the company needs to do to serve its customers better, just say no. "No." is a complete sentence, but I encourage you to politely explain why an incoming request is not the highest ROI thing that your team could be working on next (or ever!)

3. Your output is your team's output[2]. Embrace the truth that your output is no longer what you do — it's what your team produces. Say, you have a 6 person team, with 2 out-performers, 3 standard performers, and 1 under-performer, and you want to increase the overall output of your team. Obviously, you can't start coding to move the needle here — at best, you'll be able to add half an engineer's worth of productivity to the team if you work an additional 4 hours on top of your 8 hours of managerial work (and spectacularly burn yourself out in the process). Instead, think about how you can be an enabler or a force multiplier for the team that you already have. What can you do to motivate or train (or, if it comes to it, replace) the under performer on your team. What obstacles can you remove from your team's path to increase their productivity? Your managerial leverage is your team's output divided by your team size. If your team can produce the same results with one less person, you and your team are better for it.

4. Praise publicly[3]. Give kudos. Appreciate people who put in the work. Celebrate promotions. Really, go overboard with this! I have not come across anyone yet who hates being praised for a genuine effort they're making. Cherish anything good that happens on the team, no matter how small. Small gestures of gratitude go a long way, especially when they come from someone the team respects.

5. Coach privately. Ask open questions to get to the bottom of any low performance. Would the person have been able to do the task if their life depended on it?[4] Yes, then what's demotivating them? (Motivation is the manager's job.) No, then what tools or training are they missing? (Training is also the manager's job.) Ultimately, if someone on your team is lacking in either motivation or training, you owe it to them to make your best effort to provide these to them. Be radically candid[5] in such cases: deeply, truly, care personally about the person and their wellbeing, while challenging them directly on what you're seeing.

6. Be a Servant Leader[6]. As you become an Engineering Manager, you'll realize that your word weighs more, but don't forget that ultimately you are a servant to your team and your company's customers. It’s a noble profession, stay humble. The people on your team are your everything: they need Belonging, Improvement, Choice, Equality, Predictability, and Significance (BICEPS[7]) in their work life. Do everything you can to make these happen for them. Does your team trust that you are fair, and have their best interests at your heart? Does your team believe they have something useful to learn from you or from their peers? Does your team truly feel that you're worth being their manager? If not, work on earning that trust.

7. Be relentlessly resourceful[8]. Lead by example. Be a role model of what "good" looks like. Inspire people by showing, not telling. This one is tricky since you have to make sure you are not getting in your team's way and don't go into a "hero mode" and start taking away leadership opportunities from senior engineers on the team. Finding your balance is critical here, and most Engineering Managers either completely disconnect, or micro-manage and get in their team's way.

8. Stay in touch with reality. Open a Pull Request once in a while to understand the developer experience on your team. Understand how long it takes for a simple 50-line change to get reviewed and merged — is it a pleasant experience, or chock full of a thousand paper cuts[9] along the way. Be on call once a month to understand how noisy your alerts are. Get woken up in the middle of night by a page to remind yourself what it feels like. Help out your team during incidents or through tough patches. Be in the trenches, and feel the pain that your people feel. Because if you don't, it's a recipe to become a disconnected, cold, obscure, heartless manager who "just doesn't get it!". Don't be that person.

9. Build a team where everyone is a leader. Give people more ownership than they think they're capable of. Publicize this ownership across the team and its partners. If you feel an external meeting is no longer the best use of your time, think about who on your team will feel excited about going to it in your place, and will be a growth opportunity for them. If they can manage the relationship 80% as well as you (and they probably can), relinquish your seat on the table and give it to them. Remember that your "burden" could be someone else's growth opportunity.

10. Don't forget about stocks and flows[10]. Things take time. Andy Grove uses the excellent metaphor of a "Breakfast Factory" in his fabled book. If you expect the bread to take 2 minutes to toast and the eggs 5 mins to boil, and you want both to be done at the same time, then start boiling the eggs 3 minutes before you start toasting the bread. It's as simple as that. If you need 3 fully onboarded engineers in 6 months from now, you should have an approved headcount today, hiring over the next 3 months, and onboarding them the following 3 months. You have to think ahead in quarters and months, not weeks or days. If you want a project delivered in 8 weeks, and coding work will take 6 weeks once designs are ready, then make sure that designs are locked down 2 weeks from now. Relatedly, when you realize you're being asked to deliver something your team just cannot, either cut scope, push back on the timeline, or add resources (in that order). If a project's already in flight, avoid adding resources to a late project[11]. Communicate up as soon as you know there's a problem, preferably much before it becomes a problem.

11. Test your brakes. The reason F1 cars can go so fast around the circuit is not just because they have powerful engines. It's because the drivers can trust the brakes[12]. Trust your brakes and test them regularly, i.e., take time off to disconnect and recharge. As a first priority, you have to protect the resource that is you and your team. Burnout is real, and you have to take ownership over yourself and your team not getting there. Run anonymous quarterly pulse checks to understand how your team is feeling, and adjust if you see signs of burnout. Make sure people rest at least as hard as they work.

12. We're 1% done. Management is a craft. And like most crafts, there's no end to how deep you can go. I'm just getting started, and there's an incredible amount I have yet to learn. If you've been doing this for a while and feel you know it all, probably it's a sign that you have started getting in your own growth's way — I never want to get there.

There's a lot more to engineering management, and management in general, that the above list can capture. If you're thinking of trying out this path, I would recommend reading some excellent books on the topic before you make the switch. I did, and it set me up well for a pleasant transition into this totally different profession.

Footnotes

1. Credit to Greg McKeown's Essentialism.
2. Credit to Andy Grove's excellent High Output Management.
3. Credit to Dale Carnegie's How to Win Friends & Influence People for "Praise publicly, criticize privately" adage.
4. Again, credit to Andy Grove's excellent High Output Management for this framework.
5. Credit to Kim Scott's Radical Candor.
6. Credit to Robert K. Greenleaf for the "Servant Leadership" phrase. I haven't read his book on the topic, but I'm a big fan of this phrase.
7. Credit to https://www.palomamedina.com/biceps, and Lara Hogan's Resilient Management where I first learned about this.
8. Credit to Paul Graham's http://paulgraham.com/relres.html essay for this excellent phrase. It applies to founders, but also a great way to think about any role.
9. Credit to Stripe's Developer Productivity org for this phrase.
10. Credit to Donella H. Meadows' Thinking in Systems book for introducing me to this wonderful mental model, and thanks to Will Larson for recommending the book in his An Elegant Puzzle book. I also have to credit Andy Grove again for the "Breakfast Factory" metaphor in High Output Management. This is a timeless idea that any leader needs to internalize.
11. Brooke's law: "adding manpower to a late software project makes it later" from The Mythical Month.
12. I can't seem to recall where I heard this phrase (possibly, a tweet?). I find the metaphor very apt, and it has stuck with me.