My first year (ish) as an engineering manager
It has now been (officially) over a year since I became an engineering manager. (More like a year and a half if you count my “interim” period). It seems like a good time to reflect.
Why engineering management?
The further I go with engineering management, the more salient this question is — especially given the fact that there are, frankly, so many legit reasons not to.
Over ten years ago, I was a technical strategist / project manager at an agency. I had originally interviewed as a frontend developer (I had been working as a for a national non-profit), but because of my varied skillset outside of web dev, the company suggested this other role. I felt like I really could have enjoyed the role but felt out of my depth technically. Even though I had been building websites for years, I had no professional web development / engineering experience. I felt extremely hamstrung by that limitation — and frankly it bit me several times. That was my motivation to go to a bootcamp and hard pivot into a career as a frontend engineer.
My goal was to develop that technical depth and experience in engineering, and then pivot back — this time with engineering experience under my belt. Originally I wasn’t even aware of engineering management. My plan evolved to achieve a certain level of engineering seniority / experience and then pursue a transition to the parallel track of engineering management. Engineering is only one piece of my skill set. I believed what made me a great tech lead would also make me a great engineering manager. I felt I had more to offer in this capacity, and I wanted to travel that road to find out.
The hard parts
Having limited control
💬 From the outside, management looks like making decisions and calling the shots. From the inside, management looks more like becoming intimately acquainted with your own limitations and motivations and those of others, plus a lot of systems thinking.
I certainly never had the impression that becoming a manager meant being able to control and “fix” everything. I’ve worked in close enough partnership with prior managers to understand that. But there’s certainly an emotional toll that comes along with not being able to control and make everything better while also being professionally responsible for humans.
Since I transitioned into engineering management, I’ve gone through 3 changes in line manager, 2 layoffs, and 2 acquisitions (on the acquiring-company side). I’ve been calling it “speed-running management”. It is a hard, hard lesson that “everyone will probably end up being someone’s worst manager” at some point. (I don’t know who to attribute that to, but I’ve heard this general saying several times). Things have happened outside of my control that I have to represent and work through. It is, no contest, the worst part for me.
I would never have been emotionally prepared for this until this point in my life. I started my life in the non-profit space, which I credit in part with priming me to be very mission-driven, and prone to become deeply personally invested in my work, in the people around me — and in the company I’m at. Of course, those are all good things to a point. I feel I’ve self-corrected to arrive at a place I’m more comfortable with. We all need to make our own calculations about what we’re giving and getting out of the equation — and whether that’s acceptably in balance for us. And the variable you have the most control over is what you give. I’ve gotten better at exercising my control over that variable more consciously and carefully.
Being an introvert
I am unquestionably an introvert. I do think I slightly underestimated the emotional energy toll of engineering management and talking to people all day. I do get emotional hangovers, but I think I’ve vastly improved my resiliency over the last year. My partner is an engineer and an extrovert. After work, he’s ready to chat and hang out. In contrast, after work I need to have some period of time speaking to no one. We have certainly had to consciously find a balance there.
Missing flow state
I do miss the feeling of flow state that comes with writing code, and seek it out in other areas, like personal hobbies.
Saying “no”
As an EM you are responsible for managing inbound requests to preserve the efficacy, efficiency and focus of your team. If you have six sets of stakeholders who each have a p-zero need, who stack ranks the p-zeroes? I used to really struggle with this, but it’s more manageable now. If there isn’t a clear stack ranking, I connect the necessary stakeholders to be party to hashing it out together, rather than positioning myself as the sole gatekeeper.
Sometimes you do need to pivot — “We can do anything, not everything.” But if you want to put something on a full plate, something needs to come off the plate. Either we need to get ruthless about priorities, or we’re in a tough spot with resourcing. And if nothing can come off the plate (which, of course, happens) — something has gone wrong. A team can’t do their best work under that scenario, and my goal in that case is to get through it the best we can, together. It’s ok if this happens sometimes, especially at a startup. But a team cannot healthfully sustain this in perpetuity.
Measuring your performance is harder
Reading about engineering management, you’ll see everywhere things like “your performance is now measured by the output of your team”. But I could be doing a really mediocre job, and my team could be stellar enough to succeed without or even in spite of me. How do I know what I’m doing is effective?
This has continued to be a challenge for me. It’s harder to get specific feedback from your own manager about your performance… as a manager. It used to bother me a lot more, because I felt such a duty to the team — “How can I be sure I’m doing right by them?” While measuring my performance as a manager still feels trickier than as an IC, at this point I feel more comfortable trusting the foundation I’ve laid in my relationships with my team, and that they’ll come to me with feedback if and when needed (and I constantly invite constructive feedback).
When I transitioned into engineering management it was with the team I was then an IC on. One thing I did that I really liked in hindsight was to say straight up, “Look, I’ve never done this before, but I’m going to do my very best. Please feel free to go directly to my manager with feedback about me if you need to, and for whatever reason don’t feel comfortable coming straight to me.” My nightmare was that I could be missing an opportunity or even doing a disservice to my team out of inexperience or ignorance — and without the gift of feedback, I would never know. I wanted them to feel explicitly empowered to go somewhere with it, even if it wasn’t directly to me.
The best parts
Lifting people up
I’m the type of person who loves to celebrate other people’s birthdays, but shies away from doing much of anything for my own. One of the greatest things I get to do as a manager is rave about, celebrate, and highlight the accomplishments of my team. It’s been important to me to create opportunities for this that are both private (a private Slack “wins” channel, kudos in our regular team retros) and public (in all-company channels for kudos and thanks, etc).
I also love being a little connection mechanism for recognition; When I’m having a conversation with someone, and they’re expressing their appreciation for something another team member (whether someone directly on our team or outside of our team) has done, I encourage them to share that directly with the person they’re talking about, or share it with that person’s manager. As a manager, I so value when others drop into my DMs to share these things. It makes my day.
Communication nerdery
I am a communication nerd. I’m obsessed with cross-linking and comprehensiveness. Clean Notion databases and consistent, thorough project documentation and status updates and connecting the dots between people; I find it really fulfilling. In fact, communication ended up being the invisible thread in my university education — Public Communication, Graphic Design and Chinese.
This is probably why it won’t surprise you that some of work that was most satisfying to me as an engineer was refactoring. I love leaving something clean and organized. I was never precious about tech choices, and I’m still not. I prize consistency and order.
Building trust and working relationships
I feel like I really had a head start because I started off by managing the team I was already a part of. I already had established working relationships I’d built with folks — some for years already.
In the past year, some of my favorite things we’ve accomplished have resulted from deeply understanding someone’s skillset, what drives them, what speaks to them in how to help reframe challenging situations, etc.
Being closer to the business
I wasn’t sure which section this should go in, but I put it here. I’ve seen a lot of conversation around the idea that there’s a lot more career flexibility and tolerance for jumping between the individual contributorship and management. This work has given me perspective and proximity to business decisions that I didn’t have before. Sometimes, that’s immensely frustrating. (See “Having limited control” section). But it’s almost always edifying. And if I later oscillate back to IC, I will have learned some valuable lessons that will make be a better IC and partner to my EM.
Serving the people around me
I have almost never written code purely for fun. For me, the satisfaction from writing code comes from building something that is useful and appreciated (hopefully) by others. Stepping into engineering management allows me to serve end users through the people around me by directly serving the people around me. I should note, of course, you don’t need to be a manager to serve the people around you. We should strive to do the same as peers. (Which I try to do now with my EM cohort). But managers are such an important part of our experience at work — for better or for worse — and I find it rewarding to leverage and grow my skills for that.
My most important lessons
Know when to let it be
I’m a certified type-A control freak, and one of the most valuable things I’ve learned is… my limits. I’m working on defining my own measure of success with an element of grace for the things I can’t control. There are always things that haunt you, regardless of whether you could have done anything differently. But now I’m mostly able to avoid endless dwelling and rumination — which used to be emotionally ruinous.
Don’t bullshit people
Nobody wants their manager to bullshit them. One of the times in my career I felt the most defeated was when my frustrations were validated day in and day out, for over a year, and I was strung along about things changing.
Looking back, the things I now take away from that situation are:
- Believe people’s actions. I perhaps should have moved on from that situation long before I ended up doing so.
- As a manager, be as transparent as you can about what you are able to change, or not able to change.
Burnout is a response to repeated attempts to make meaningful change while lacking the agency to do so. See problems > try to fix them > get shot down or ignored.
If this person had just told me, “hey, I get it, but it’s just not a priority and not going to change right now”, I could have made my own choices about whether what I was giving and what I was getting out of that role was in balance and worth it to me, even with the frustrations. The answer may have been yes. Instead I felt strung along and mismanaged. Just tell me how it is and let me make my own decisions. I try to bring that to my management style as much as possible — without being cynical, let’s be realistic and reframe / game plan for the best possible approach and outcome under the circumstances. We’re going to make the best of it, but I’m not going to try to sell you on it always being sunshine and rainbows.
Overall takeaways
Through the years I have less and less tolerance for tech-related things outside of my work bounds. This means that starting a few years ago, even while I was an engineer, I didn’t really do as much “for fun” web dev spelunking or building.
Now that I’m a manager (and not writing code in the course of my work), that means I’m not really writing any code. And I still don’t know how I feel about that. I don’t want those skills to atrophy, but currently I have confidence I could get back into the swing without issue. I do plan to prioritize spending time writing code again this year. I’ve gotten even better at the skill of forming the right questions — when talking through an issue with engineers, I can still think and question like an engineer — and be productive to the problem-solving process of my team.
People have asked, “Are you enjoying engineering management?” to which I say, “Hm.” I wouldn’t say “enjoying” is the right word. It’s been satisfying, infuriating, fulfilling, and challenging. I feel like I’ve grown more in this era of my career, and I definitely have more to learn and give in this role. It’s still the right path for me for now, and careers aren’t etched in stone.