Recently, I made the decision to step out of my role as an Engineering Manager (EM) and back into the role of being an Individual Contributor (IC). Technically, this is a step backward in the career trajectory. However, it is more common than one might think.
One of the most important factors in my decision was reading about other people who had gone through this transition. There are some great resources, such as the canonical Engineer/Manager Pendulum written by Charity Majors and this article on LeadDev written by Gemma Barlow and several others.
There were not nearly as many of these resources as someone like me needs to confidently support this decision, so I would like to add to the woodpile. That is why I'm writing this. So, sorry for polluting the internet with more content, but if I can strengthen this content space even a little, I think it'll be worth the bytes.
This decision was not made lightly. However, it was made quickly.
It took me a long time to realize how I felt, but once those feelings were in front of me, the need for a change was obvious, and I don't really like sitting on that kind of thing. While it wasn't always great, the experience I gained was truly eye-opening and helped me grow in so many ways.
I didn't spend nearly as much time in the role as I had in the role of IC. It was a short experience — I was in the role officially/unofficially for about one year, while I've been an IC for about 7-8 years. This is for a very simple reason — I do not like being an Engineering Manager, sam, I am. In fact, a lot of the time, I kind of hated it.
Despite the saltiness at times, I found it a positive experience in retrospect, even when it wasn't. I learned so much from the role about:
- how and why decisions get made by engineering leadership
- how to influence people
- how to work with "strong personalities" - a euphemism our industry often uses in place of the much more apt descriptor "assholes"
- what motivates people
- what demotivates people
- how often leadership decides what people want without actually asking them
- how tone-deaf leaders can be, including me
- how thrilling it can be to lead your team to success
- how heartbreaking it can be to lead your team to failure
- how little basis words like "success" and "failure" actually have in reality
- how projects are chosen and assigned
- how requirements are gathered
- how requirements are ignored
- how requirements are forgotten?
- how satisfying it can be to create a positive environment for people to interact in
- how hard it can be to leave what you've built in the hands of someone else, regardless of how capable those hands might be
How did I get into the role?
My larger team had become a revolving door for externally hired engineering leadership, and that door had a shitload of thru-traffic. In the span of one year, we had three engineering directors officially, if I recall, and more than that if you count the interim directors, etc. It was a shit show. Despite this, our team somehow kept growing.
We were getting more engineers and more projects. Things were a mess. We had no standards being utilized, common conventions were being ignored because of clashing egos and lack of visibility, and people felt completely aimless. No one had a pulse on what leadership wanted or even expected of us, and there seemed to be no path forward. We felt aimless.
I was working really close and frequently with one of my best friends, Phil. We worked on a project with almost no guidance for close to a year. I was somewhat of a technical mentor to Phil (those would be his words, not mine), so I spent a good amount of time providing guidance and leadership.
I had the good fortune of sitting right next to my Vice President, Ben, who took notice of this. This would end up being a heavy influence (and a very positive one) on my path at the company.
Eventually, Ben and I developed a good relationship. We weren't besties or anything but had some interesting conversations here and there. He obviously had a lot of wisdom to impart, and I mostly contributed by taking the piss out of him the way I do with anyone else, which I honestly think he appreciated quite a bit. Whether that is truly the case — you'd have to ask him. I won't pretend to know how anyone else truly feels.
Ben became a strong sponsor for me. We met regularly in 1-on-1s and talked about my career path consistently. He challenged me often.
He started bringing me up in the right conversations, pulling me into "the room" when possible, and keeping me in mind for valuable opportunities. One of those opportunities would officially start the road to me becoming an engineering manager.
One day, after work, a few of us were out celebrating the end of a project. We had just arrived, and people were still getting seated when Ben approached me where I sat — standing, of course, towering really — and said, "Tim, you're getting an intern. Her name is 'Diane,' and she starts in May."
Well, for the record, her name was not Diane, and she did not, in fact, start in May, but hey — Ben and I didn't need details. We had something deeper than that — we sat next to each other, for god's sake.
I was thrilled but hesitant. Hopefully, in good company, it is actually very common for capable people to be reluctant to enter leadership roles. While I had some reservations, when the time came I had a great experience with that intern. Her name was Diana, and she worked very closely with Phil and I — an experience that benefited all of us, particularly because I was able to provide the guidance and leadership to them that I wanted for myself.
As a more experienced engineer than Phil and Diana, I needed direction from our director, but I wasn't getting that. I quickly discovered that I could prevent that aimlessness that I was experiencing in this position. I could create a more positive working environment for these few people and help them be happier, more productive, etc. That in itself was, quite honestly, intoxicating.
After this, I knew that I wanted to pursue the logical next step in this career path, or at the very least chase down more of these dopamine hits. So I asked for direct reports, and Ben helped deliver. Our larger team was split into 3 sub-teams or "pods" with me leading one. I had two direct reports, Phil and a returning engineer to our company, Kat. I wasn't an EM by title yet though. That didn't come until a little later when we got a new director. All the pods/sub-teams were eventually given an EM, so it eventually became myself and two others, both of which had much more leadership experience than myself.
My time in the role
I don't want to spend a lot of time here, but I want to highlight some key aspects of my time in the management role to make it clear that I was committed to learning new skills and doing the job to the best of my ability. I wasn't just filling a seat or killing time. Some things to keep in mind:
-
The most people I ever managed at once were 6 people. However one of those people did have an intern at one point, but I really had nothing to do with that relationship. I started out managing 2 and kept getting people. Luckily I had almost no attrition.
-
I completed our management leadership training, which was actually extremely helpful and I'm not sure why we don't just let whomever enroll in it.
-
I read several books on engineering leadership, including:
-
And, like, a billion blog posts and articles, plus some other books I can't even remember now.
-
I participated in a Slack channel that matched everyone with a new EM every two weeks to chat with and share ideas, which was hit or miss, but when it worked I found it extremely beneficial. I even had a few follow-up meetings with some people because the conversation was just that good.
-
I administered quarterly anonymous surveys to my team and made changes based on their feedback. Some of these changes were hard for me and required me to drop the ego, but they were better for us all.
-
I did my weekly 1-on-1s with everyone and participated in so much leadership development that it was basically my full-time job just trying to get through all the L&D
-
I received very positive reviews and feedback during my time in the role from leadership and from my team.
-
My team increased the number of vacations people were taking significantly, with no decrease in output. In fact our output increased quite a bit as the team matured and as we gained new engineers and established team-wide conventions and best practices.
-
I continued a good amount of technical work and user support while in the role — some would argue that invalidates my experience a bit, but it was necessary under the circumstances, and I slowly moved further and further away from the technical work.
-
I took a lot of advice from other leaders, particularly the other EMs, over the pods/sub-teams
Obviously, this isn't meant to be a true list of the work I did or the results I achieved, just a small look into how much I put into it.
Signs it wasn't for me
Honestly, the signs that this wasn't the role for me were there all along, however, they became more and more apparent with time, to the point that I could no longer ignore them or explain them away. The signs were:
- I was completely unenergized by my work. Even the wins weren't doing a lot for me. I just felt burnout nearly all the time, yet I was definitely taking a good amount of time off to recharge.
- I was so uninterested in my work that I was becoming very forgetful.
- The only parts of my work that were interesting were technical things. Occasionally I would help debug something or do some "engineering," and that would recharge me just enough to think that it was the other work I was enjoying.
- I could not see myself progressing along the people management track/path. Jobs like director, vice president, executive vice president, CTO, etc., just didn't even kind of seem like something I wanted to do. My manager, who is amazing, was always trying to help me do my best in the role and be best prepared for changes in expectations for the role, so we started talking about me being over multiple teams instead of one, and that sounded like hell to me. I felt like I was at the end of the road in terms of how far I wanted to go, but when I would imagine myself in the more advanced technical roles, I could actually see it. I was interested in what it takes to become Staff or Principal. The thought of that energized me.
The final sign
Eventually, we saw a lot of positive changes. We finally hired a director (an internal hire) who was, and is still, an amazing fit. He is a great technical AND people leader and is passionate about his role and helping to develop others. We moved some great EMs into the other pods/sub-teams and saw a few re-orgs, until we ended up in a configuration that made some objective sense. We had a particularly good project manager and a product manager. The teams were all growing and maturing, and finally, it hit me — I was no longer needed.
Remember, the primary thing that brought me happiness early in the role and before the role was essentially providing missing guidance and leadership to the people I cared about, however now I realized that was the standard, not the exception. The other EMs are great — definitely better than me. Our leadership was strong. Even our new Vice President was a great fit for us, and everything was working so much more smoothly for my people and me that I no longer needed to protect them from, well, anything. Maybe I never really did. I mean, we're not out here fighting dragons (usually).
Not only that, but I realized I'd never truly experienced being a senior-level IC. When I was in that role, I was just a senior engineer by title. I always had direct reports and never got to experience being on a team that had things together or strong leadership and guidance.
At this point, I read some articles, talked to some people close to me, and came to the conclusion that it was time for me to step back into the role that honestly was new for me, considering I'd never truly been able to perform that role as written. It was time for me to go back to being an IC.
The transition
I was very lucky to have such an understanding manager and skip-level manager. They both completely understood my situation and were appreciative of the time I'd spent in the position. They moved me back into the role very quickly with a lot of say from me on where I ended up and what my exact role would be.
Luckily my pay wasn't impacted. However, I was in a different pay band now, so I was much closer to the maximum in the senior engineer range than I was in the EM range. I am at a large company, so there was a lot more room for flexibility on these things, so I can't say it would've been the same at, say, a startup.
The biggest thing was trying to find the right person to take over my team. I'd worked really hard to create a particular team culture that really focused on the satisfaction of the individual and that wasn't something that my manager or I were looking to place in the hands of just anyone. Luckily, the person we found to take the reins was amazing and seemed like the perfect fit, and it didn't take us long to find him on a nearby team in the org. My manager already had a strong relationship with him, and he had worked with several key people across our teams, so it was a "stars aligned" situation.
Key Takeaways
Of course, what would this article be without a set of clearly listed learnings or takeaways to share. "Well written and to the point." - you might say. Well, regardless. Here are some things that might be beneficial to state explicitly, even if you've heard some of them elsewhere:
While cliché, I must explicitly state that engineering management is an entirely different role from engineering. You'll need a whole different skill set, and you are essentially starting from square one. To highlight the difference using basically any other profession, managing doctors is entirely different from being a doctor — I guess, IDK. I'm not a doctor. Who the hell manages a doctor, anyway? Are there Doctor Managers? Doctor II? Doctor Supervisors? Boss Doctors? Please comment and help me out here.
You will learn so much more about how your organization runs—pay and promotion structures, internal conflict resolution, project planning, etc. Honestly, you'll likely see a lot of warts that weren't visible before and gain more insight than you really ever wanted. This may make you want to run, but just remember, other companies likely have their own warts. You just may not see them unless in a similar role to where you are now.
Ask your team what they're thinking and listen. Never assume you can speak for them unless you've spoken to them. So many leaders start off sentences with "my team thinks X" or "my team prefers Y" and when I ask how they know, it is almost always some anecdotal "I know my team" defensive nonsense. Show me the data, or see ya latah. Right? Right? Whatever. Whether it be anonymous surveys or whatever, get real data on how your team feels about things. But don't just do an open-ended "tell me your thoughts".
Make sure to include some quantifiable questions as well so that you can chart something to prove how sentiment changes on a particular topic over time. If you're ever sitting in a room with other leadership talking about how people feel without data, stop the meeting and go get that data. No need for guesses.
If you're having issues with someone or you have feedback, document the hell out of it. Emails, notes, pictures of the Slack messages, whatever you have to do. Just record whatever you need to prove any complaint you'd ever have against someone and keep it somewhere safe. Chances are you'll need it, or someone else will. And when I say issues, I don't mean something like they punch you in the face or tell you to go to hell in a team meeting.
I mean even small things that have an impact, like consistently not listening when you talk or saying they'll do something, then doing something else. You may not always need these things for some big conversation with HR. It is your job to provide quality feedback for growth, and it can be hard to provide unless you have practical, specific examples to illustrate your point. If things do go south and the conversation turns towards a PIP or possible termination, then this documentation will be even more valuable.
Lean on your leadership peers. The other people in your position are an insanely vital resource. These people have been where you are, or are there now, and have more insight into what you're trying to do than anyone else. Take their advice, copy their tactics, and yield credit like crazy where possible. This aligns closely with the concept of having a "first team mindset". Your leadership peers are your team, even if you don't always think of them that way. Use them where possible.
Lean on your leadership, uh, leaders. Your manager is more of a peer to you than you are to your direct reports. They are there to help you succeed for your team, and often that means you need them to handle certain things for you or help you succeed by performing certain tasks. "Managing up" is the apt name for this and is crucial to you succeeding as an EM or anything else when it comes to technical leadership.
This was one of my biggest failures as a leader. My manager would constantly ask "what do you need from me," and I would always say "nothing", even during times that I felt like I was drowning. Don't be like me — take the help. Manage your manager, especially if they're, like, asking to be managed.
Being a good manager doesn't mean your people should never have a bad day — it means building a framework that makes bad days much less likely to occur. Find the pain points for people. This is where that listening comes in. Add practices and processes where necessary to reduce actual friction that people are experiencing and document the hell out of these processes so that nothing becomes a "this is just how we've always done it" type of thing.
The amount of time it takes to "manage" each additional person grew linearly until I hit four reports, at which point it grew exponentially. When I had less than four reports, the amount of time I spent managing each person followed a basic formula that I could actually track and plan around. It basically included the obvious steps of 1-on-1, providing direct mentorship, writing reviews, and some padding for whatever else. At this point, this was making up about 50%-60% of my time, with the other 40%-50% being spent on engineering.
I was more like a senior engineer with direct reports in terms of how much time I could spend on technical work. Then at four direct reports, this changed. You end up spending much more time on certain things because of the number of people you're coordinating. For example, coordinating four people to work on a single project means coordinating four tasks that can be worked on independently without constant conflicts and interference, which is often hard to do unless projects are larger in scale or complexity, and my team was building less complex internal tools at the time.
That means losing people or finding more projects to take on at once, which means more time spent as an EM finding work for the pipeline and coordinating across multiple projects. It also becomes more difficult for people to effectively communicate at four people on a team (five including the EM) so now you have to spend time figuring out the best ways for people to effectively share information without spending all their time together.
Also, more projects sometimes mean more stakeholders, which are relationships you have to manage somewhat as well on top of everything else you're doing. At this point, the argument could be made that I should've taken on fewer engineers, which would free up some time, reduce the number of necessary projects in flight, etc. but to be honest it just — in my experience, and that of many people I know in this role — doesn't usually work that way.
This is often the growth path presented; taking on more engineers is the way forward for most people, so this is something a lot of people in this position will run into.
While it is nice to have a generic framework for growth and development, at the end of the day, each person's individual growth really is about them and their personality. It is unique to them.
Without going down a rabbit hole, if you have an engineer that is otherwise talented, but absolutely doesn't like doing presentations, then okay. They're grown. They like what they like, and don't what they don't. Not saying that it can't change, but you trying to change it has no real value. Giving them opportunities to push themselves is great, but don't let it be the hill you die on.
Your job is to help them be successful. Period. If that means exploring other ways of achieving the same outcome as a presentation (i.e., sharing information and ideas with a group), then explore away. Figure out how they can be successful despite the fact that they're just never going to go out of their way to do a presentation or {insert any other example here}.
Featured Image Photo by 愚木混株 cdd20 on Unsplash