I Was a Terrible Manager (Not 1, Not 2, but 3 Times)
Don’t get into management for the wrong reasons
I’ve been in the software industry for over 24 years (11 at Microsoft, 11 at Amazon, and 2 at Google). For most of my career, I was an individual contributor (“IC”). These days I’m a Senior Staff Engineer at Google. I’m a “pure” IC, meaning I choose to have zero engineers reporting to me. But three times in my career, I was delusional enough to think I would be a good manager. Eventually, I figured out I was doing it for the wrong reasons, and I was a pretty lousy manager. My high-level takeaways are:
- Being a manager is not a promotion over being an IC. There’s not a significant difference in pay, and both tracks (the management track and the IC track) have parallel growth opportunities, with similar opportunities for influencing.
- Being a manager is an entirely different role that requires a different skill set. Being a good engineer does not mean you’re a good manager and vice versa. Companies that “promote” high-performing engineers into management roles do a disservice to both the individual and the company.
- If you’re passionate about helping others grow, this is something you can do both as a manager but also as a Senior IC and beyond. You don’t *have* to be a manager to do this.
- If you’re passionate about being a leader, this is *also* something you can do both as a manager and as a Senior IC.
I went into management roles initially because it felt like a promotion. I stayed because I (1) enjoyed growing people and (2) enjoyed leading others. But there was a lot about the management track that I was not great at. And eventually, I realized I had the freedom to grow people and be a leader as an IC; I didn’t need to be a manager to do those things.
Unlike me, if you go into management, do it for the right reasons. Having had both terrible and amazing managers in my 24-year career has made me treasure the good ones. Be a Good One.
The first time sort of “just happened”
I started at Microsoft in 1997 as an SDE-I out of college, got promoted to SDE-II 18 months later, and a year later, I was doing well, so my boss asked me one day, “How about I put these 3 guys under you?” I wasn’t pursuing a management role. I had never even thought about it. But I was flattered, and it felt like a promotion because there seemed to be a prestige around “managing people.”
I started leading a little team of 3–5 engineers in 2000. I had no idea how to be a manager, and I didn’t receive any mentoring or training around that. Back then, Microsoft had this bad practice of “rewarding” promising engineers by turning them into managers. So, I improvised a lot. I was also very lucky because the individuals I had were top-notch. I promoted two of them within a year. Managing a small number of self-motivated high-performing engineers was an easy role; I continued to spend 50% of my time coding as an individual contributor and the other 50% on 1:1s, career discussions, promotion docs, etc. Life was good, and I continued happily (and uneventfully) managing them for a couple of years.
The second time I was too afraid to say “no”
In 2003, Kai-Fu Lee took over our group (the Natural Languages Group, NLG) and merged it with Speech Processing and other interface and assistance technologies. Kai-Fu led a distinguished career, from Carnegie Mellon to executive tenures at Apple, SGI, Microsoft and Google. But you won’t find warm fuzzy feelings for Kai-Fu among Microsofties, and particularly among NLGers. He immediately slashed investments in natural language understanding in half, so overnight, 80 of my peers had 3 weeks to find a different job. At the same time, he was brazenly using his Microsoft corporate email account to seek employment from Google. Kai Fi defected to Google to do the same job he was doing at Microsoft, blatantly ignoring his non-compete, and Steve Ballmer, angry as hell, sued Google. My team was in the middle of that drama.
Specifically, what that meant to me is that all the engineers who reported to me were told to find different jobs. I was furious, They were an amazing group of high performers, and we had worked hard to build friendships, trust, and a strong team.
I got to keep my job, but NLG was now a shadow of the former team with the grandiose goal of empowering computers to understand human languages. The morale of the team was down the drain after watching Kai-Fu laying off half our friends. I had a chance to either focus on being a technical IC or keep the manager title by taking a management role in a different part of the org.
I sat on this for a while. The new role was not a good fit for me. My new manager was not a particularly great human being. It was in a space where I had no particular passion. But “going back to an IC” felt like a “demotion” at the time.
I stayed a manager for all the wrong reasons.
My poor choices caught up with me. I struggled with the team, with the space, and with my manager, among other things. It went so poorly for me that I went from a consistent track record of above-average performance reviews to almost being fired at Microsoft.
After that, I went back to being an IC. I was burned out, and I had lost a lot of my self-confidence. Maybe I wasn’t a good leader after all.
Is the third time a charm?
Life did improve. In 2009 I joined Amazon (as an IC). I was energized by the culture and thrived there in ways I hadn’t at Microsoft.
In 2012, my manager, Claire, made me an interesting proposition. She was about to go on six months of maternity leave. Would I like to hold down the fort while she was out?
I had to think about it for a while. I knew that managing people was not my long-term passion. But, on the other hand, I liked that it was a finite, time-bound assignment: it had a start date and an end date. When Claire came back from maternity leave, I could go back to my old job. If I ended up loving management, I could probably stay in the role. It was a low-risk way to check once again if the management route appealed to me.
So my third management adventure started. I managed 20 engineers, and I was both a manager of managers and a front-line manager in two time zones. Being in a horizontal team that created tools for the entire org, I reported directly to VP, which was also interesting exposure, and I got to join his staff meetings.
This time I had to deal with some challenges I hadn’t had before. In my other stints as manager, I had had the pleasure of promoting engineers, but I had never fired an engineer or even dealt with one struggling.
Amazon had performance reviews every six months, with scores in the range { Did Not Meet, Met, Exceeded, Outstanding }. There wasn’t a mandatory bell curve on Did Not Meet (DN), but usually, ~10% of the population scored DN. With 20 engineers in my team, I was statistically likely to have one or two DNs.
What made this particularly challenging was a draconian rule imposed by Brian Valentine, Senior VP of Amazon Retail at the time (and before that, a veteran Microsoft executive that ran the Windows division for 20 years). Brian was tired of low-performers hanging around for multiple cycles, and he decreed that if any engineer got two DNs in a row, that person’s manager had failed to address a performance issue, which brought a mandatory DN for the manager, regardless of anything else that manager had done during the cycle. Because of BrianV’s draconian rule, if an engineer got a DN, they immediately became a liability to their manager, and the clock was ticking: (1) get them to improve, (2) fire them or (3) you’re the one in trouble. Luckily, Brian’s rule did not stick for too long, but it did apply for a few years.
In the last seven cycles, I had had 4 Exceededs and 3 Outstandings. I was expecting Outstanding this review cycle too, which would nicely pave the road for that Principal Engineer promotion I was pursuing. Yet, I faced the real possibility of ending up with a DN if any of my engineers got a second DN in a row. It was mentally and emotionally draining.
I learned one thing about myself during the process. I’m extremely passionate about sponsoring good engineers and coaching them to become great. The “good-to-great” is my groove. Helping struggling engineers requires an entirely different toolset. Great managers have that skill. Unfortunately, I don’t think I do.
I also shifted the way I see the world from thinking-tech to thinking-business. I started flexing that tech-to-business translation muscle with my monthly team report to my VP. Once a month, I asked my 20 engineers to send me their monthly status, and I aggregated their individual reports into a single report for my VP and his Directors. My engineers sent me summaries that were very focused on the low-level tech details of what they had done, “I wrote 2000 test cases”, “I found 17 bugs”, “I had a meeting with Bob”, “I launched this tool.” I knew perfectly well most of that was meaningless to my VP, and I needed to convert that to business metrics and customer impact that my VP could understand and care about.
That turned out to help me immensely in my path to Principal Engineer later on. A well-rounded Principal Engineer can put their tech hat on and speak tech to engineers writing the code, and then they put their business hat on and speak business to their leadership. You’re glue; you’re a translation layer. A lot of what I do as a Principal is look at the same problem from a technology perspective and from a business perspective to provide a more holistic view.
As promised, Claire came back from her maternity leave six months later. And, as promised, I returned the keys to the kingdom to her.
I enjoyed my third manager stint (not enough to stay as manager, but enough not to regret doing it!). And, I learned things that were very valuable to me in my career as a senior technical leader. So it was not a distraction or waste of time at all as I had feared. Being a manager made me a better engineer.
Some epiphanies along the way
There are a few things that I learned in this meandering path.
- Both the management track and the IC track are solid tracks without a ceiling. They are entirely different roles that require different skills. I developed an empathy for managers and an appreciation of great managers for what they do — it’s not easy being a great manager. The growth path as a manager is slightly more clear in terms of optics. You manage N engineers as a front-line manager, you become a manager of managers, then you become a manager of managers of managers, etc. The growth path as an IC is not as clear-cut, particularly getting to Principal and Distinguished Engineer. But it’s extremely rewarding.
- I had a passion for sponsoring good engineers to become great. Being a manager was one way to achieve this, but not the only one. As a Senior and Principal Engineer, I had the freedom (and actually, responsibility) to mentor others around me that met that criteria. Managers were responsible for the entire gamut of performance, but as an IC, I could focus my energy and limited cycles on the good → great people.
- I also learned that I didn’t have to be a manager to influence technical roadmap or be a technical leader. Managers don’t call the shots alone; they depend on partnerships with their senior technical engineers to make important decisions. As a Senior/Principal Engineer, I had the freedom (and actually, responsibility) to set a technical roadmap and be a technical leader.
Being a manager for a while was very useful to me. It made me a better Principal Engineer. My little bit of wisdom to any engineer flirting with becoming a manager is to try it! You will gain valuable skills. But, don’t stay in it for the wrong reasons.
