Navigating the bumpy road from engineer to engineering manager
A few years ago, I woke up and took a look at my work calendar. Back-to-back meetings from 10am to 5pm. Sigh. I rolled out of bed, checked to make sure neither of my kids were awake yet, and pulled my laptop out. Starting at the file that was open in Sublime, I quickly found a few lines of unused code to delete. Within fifteen minutes, I had opened three pull-requests, each deleting anywhere from 10–50 lines of unused code. Sigh.
When I met with my manager for our weekly 1:1 later that day, I mentioned what I had done. He gave me a look, and said — critically but kindly — “is that really the best use of your time?”
The transition from technical IC, or individual contributor, to engineering manager is rough.
Consider coding: it’s a fairly objective process, or at least it’s treated like one. Many companies track the crude metrics of number of lines of code added or number of commits. The path to seniority is fairly clear in terms of the work — building, debugging, maintaining, and being a core contributor for larger and larger projects. There are some nuances — if you spend time upfront clarifying requirements, you might save yourself 2 weeks building a new endpoint and backfilling data you didn’t actually need. Or a comment you leave in a code review or tech spec could plant a thought that leads to a much better implementation. But generally speaking, at the end of the day, if you’ve had a big chunk of heads-down coding time, and merged a handful of pull requests, it was a good day. Most of the uncertainty around the technical path comes not from the work itself but from titles, compensation, and perceived career progression.
Note: In re-reading this, I am reminded of a time when this technical path was not that clear to me. That may be for another post — how to move from junior to mid-level to senior engineer. I still think it’s more clear than the management route.
Now consider management: Managing people and teams is a much more subjective process, so much so that companies routinely try to have “no managers — a completely flat org!” There are some more tangible things like, did the team deliver what they said they would. But a lot of management is the less visible things — do people feel like they have opportunities to grow at a company, do they feel safe at work, do they feel challenged. The default feedback loop for these are much longer (generally twice a year when company surveys aggregate results per manager). Progression along this path is much more unknown.
When you consider how different the work is, no wonder the transition is so difficult. Most first-time managers don’t get any support — if they’re lucky they may have a peer to lean on, but usually they’re on their own. If you’ve interviewed senior engineers, you’ve probably seen many senior IC candidates who have decided to move back to the hands-on technical work after a few years managing people and teams —you might hear, “never again” or “management wasn’t for me, I just want to code.” A large swath of questions and blog posts around moving to engineering management are more or less variations of:
How do I keep my technical edge?
This question is symptomatic of a more fundamental problem, which is that these first-time engineering managers are not getting guidance in seeing the impact and rewards of moving into a management role. Dealing with the anxiety and sense of being unproductive, of course they grasp at and gravitate to the much more objectively rewarding work of coding.
So, how can we pave the road so it’s not as bumpy? Making that transition smoothly requires a very fundamental mindset shift in how you view your own productivity and self-worth. If you are someone in this transition, here are some ways to make it smoother:
Self: Keep a log
At the end of each day, jot down the most impactful thing you did that day. Let yourself generously speculate about possible downstream effects.
Example: Today I had a meaningful 1:1 with Alice and helped her see how important her work is to the team’s purpose and overall goals. The increased alignment could make her more motivated and productive, which may increase team morale as well.
Example: Bob came to me with an interpersonal issue that he was struggling with. I coached him to give feedback in a kind way. He pinged me on Slack in the afternoon that the conversation had gone really well. Now he has that skill in his toolbelt for future challenging situations. And he has one successful example in which he took initiative to change something that’s not working.
I did this when I was feeling very spread thin as a manager, and again when I was getting started with my coaching business. It can help highlight the potential impact of your actions when things seem very chaotic and uncertain.
Internal: Find peer support
One or a group of trusted peers can act as a sounding board. Being able to post something like, “Hey, I have this situation, and here’s how I’m thinking of approaching it. Am I missing anything?” in a confidential setting is extremely valuable. Senior managers can coach first-time managers, and first-time managers can commiserate together and then help each other through the rough times. Peer support in a company — someone you can reach out to and say “Do you have 10 min? I want to run something by you” — is ideal. At smaller companies, this is often not possible, so having an explicit external peer relationship can also be very useful, especially for sharing best practices and perspectives across companies.
External: Work with a coach
As an engineering leadership coach, I work with several clients who are first-time managers. Sometimes I can sense their uncertainty of whether or not it’s a long-term career path. My job is not to convince them that management is the way to go. Rather, I aspire to shine a light on their strengths, areas for improvement, and the rewards and impact of that path — so that they can make an informed decision. I believe that many potentially great managers go back to primarily IC work because of inadequate support, and they don’t have anyone to bring the management path into focus so it can be seen as clearly as the technical path.
Regarding strengths, a coach can point out what is clear as day to them, but invisible to the coaching client. Impostor syndrome is the phenomenon of high-achieving people who attribute their success to luck or timing, minimizing the effect of their innate abilities. Someone may say, “well of course my team delivers projects on time, and I communicate effectively with the company, anyone can do that,” without realizing how much of a struggle time estimates, communication, and project management can be for many senior engineers. A coach can help you internalize and own your strengths, as well as hone in on areas for improvement.
Other resources
There are also many books and online resources I recommend. These are just a starting point:
The Manager’s Path — a chronological read, going from being managed as an IC all the way through CTO/VPEng-type roles. For early managers, it’s especially great for getting a glimpse at that path and the types of problems along the way.
Eng Manager’s Slack — a well-moderated and sane slack team all around engineering management.
Now, going back to the story I started this post with (but mostly because I love to talk about code deletion). Even when it happened, I knew intellectually that deleting that code wasn’t the best use of my time. But a year or so later, after navigating that rough transition from IC to manager, another insight emerged. In acting as code janitor for the team, I was actually selfishly depriving others of the life-changing magic of code deletion. And I was reinforcing that it was fine to not clean up after themselves, because someone else would do it. Instead, I started LGTMing many code deletion pull requests with 🎊🎊🎊🎊🎊🎊🎊🎊🎊 emojis, and started a #code-deletion slack channel to post deletion PR screenshots. I thought about how my actions impacted and empowered others, rather than what felt good for me in the moment.
Interested in coaching? Email me at jean@jeanhsu.com.
