Career Growth Speed, Deconstructed

At times I grew exponentially, at other times, glacially — Why?

I was recently lurking on linkedin and noticed one of my favorite Senior Principal Engineers at Amazon had gone from Intern to Senior Principal in a decade. That’s an astonishing growth by all accounts (promoted every two years). For the longest time his work profile photo was from the intern days, so I imagine that was very confusing to people who just looked him up.

Some engineers grow glacially slow (or not at all); while others grow through the ranks at neck breaking speed. Usually this is a combination of individual skills, leadership support and situational luck. I wrote about some of this already (The Fallacy of the Self-Made), but this article today is a deeper dive into times in my life where I did one or the other, and why.

The 3 companies where I worked the last 25 years (Microsoft, Amazon, Google) have slightly different names for the levels, slightly different bars, and slightly different distribution, but the high level concept is common across all. There’s an entry-level Engineer (your first few years in the industry), an Engineer-II (the bulk engineering role where you’ll spend most of your time coding), a Senior Engineer (who leads technical decisions in a team), and then the Staff, Principal and Distinguished Engineer levels (which I wrote more about here and here). I am a Senior Staff Engineer at Google.

I started my thought experiment with the high level timeline. This is where I worked.

Next, I took a stab at adding my level progression. I’m using the Google levels here, but since Amazon doesn’t have the notion of Staff and Senior Staff, it’s a bit of an approximation / extrapolation.

My next step was to make it more granular by marking up times where I grew fast and times where I grew slow. I added green triangles pointing up when I grew fast (double green triangles for times where I grew exponentially fast). Likewise, orange triangles pointing down for times where I regressed in my career. And gray squares for times where it was sort of linear growth. For good measure, I added the 2 times where I was pretty darn close to getting fired.

You may have assumed that the path of somebody who got to Senior Staff Engineer, a role held by about ~2% of Googlers, would be nice and tidy. Not me. My career growth was a mess! It doesn’t take a data scientist to identify the two areas of interest. I circled them in red.

How dramatically different I performed in these two periods of my life! Yet I was the same human being — what caused me to behave so differently? I bet some people who knew me during Period A may be surprised about my Period B… and vice versa!

Both periods are about 6 years. Only in Period A, I didn’t have a single promotion, my career was stale, and my compensation really didn’t change. In Period B, I was promoted 3 times, and doubled my compensation. And, much harder promotions. Why were they so dramatically different? Was Microsoft harder than Amazon? No, not at all. In fact Amazon was a much harsher, much more demanding environment. But somehow Amazon supercharged my career in a way Microsoft did not. Why?

My managers mattered

In Period A, I had a long string of awful, awful managers. They were more concerned with growing their own careers and had no genuine interest in guiding me. I can’t remember any of them sitting down with me and candidly telling me: this is where you are, here’s behaviors that you should do less of, here’s behaviors that you should do more of.

In Period B, I had a string of amazing managers that I developed deep, long relationships with. They took a genuine interest in my growth, provided candid feedback on strengths and weaknesses, challenged me, and facilitated a fast track for me when I deserved it. Having a great manager doesn’t mean they always paint a rosy picture: some of my favorite managers were some of my most demanding managers.

But after some thought, I decided that the initial observation that managers determined my career growth is too simplistic, and punts too much responsibility away from me.

During Period A, my wife patiently endured years of me complaining about some of these managers. She is not one to sugar-coat things to me, so one day she had had enough of me whining and said, “hey Carlos this is the third manager you complain about! Maybe it’s not just them, maybe it’s YOU!” That flustered challenge shook me a bit. She was right. Ultimately, I owned my destiny. I didn’t need to stay in unhealthy places. I didn’t need to continue reporting to a crappy manager that didn’t care about me. I learned over time there’s environments where I operate amazingly, and environments where I do not. I stopped blaming my manager and taking the driver seat to push my career forward.

Compensation mattered

Money should not be the only thing that inspires you to do your job, but it does help to see a direct link between how well you take care of the company and how well the company takes care of you.

Period A started after I invented two things that saved Microsoft millions of dollars, and not only did I not get promoted, I got a measly $10k raise/bonus. The stock had been stale for years. Every day I had a harder and harder time seeing positive direct financial benefits to my hard work. I knew I was underpaid at Microsoft, and the chip I was carrying on my shoulder got bigger every day. My attitude got crappier every day — which didn’t help.

Period B on the other hand started off with Amazon doubling my Microsoft compensation. The stock grew by 10x in that period. This all set a positive tone where I saw direct consequences to my hard work, which in turn created a self-feeding loop. Every morning I came to work thinking: “This company is taking really good care of me, what can I do to be worth what they’re paying me?” In fact for a while, due to the stock growth, I felt I was getting paid more than I was worth, which put an odd yet energizing pressure on me to do more for the company.

Long hours* didn’t matter

On average I worked 40 hours per week during Period B as I was getting promotion after promotion. I put this with an* because there were times where I had deadlines that were important for the business and I was willing to push myself and make sacrifices. Yes there were intense weeks when I worked 60 hours or more because it was time-sensitive, but life/work balance has always mattered to me and my managers understood and respected that.

I probably worked much longer hours in Period A, but they simply weren’t as effective as the hours I worked during Period B.

Which takes me to my meta point: it’s not about how many hours you work, it’s about what you do with the hours that you do work. I figured at any given time I was doing some percentage of level-1 work, some percentage of level-appropriate work, and some percentage of level+1 work, but I needed to be deliberate about shifting those percentages over time. And focus on the things that matter and have impact on the business.

Sponsorship and Freedom mattered

I recently faced a dilemma here at Google. We were presenting a thing to a VP, and we wanted his endorsement. This needed to go well, so I was asked to present, because as a Senior Staff Engineer, I am routinely in the room with Directors and VPs so I feel comfortable speaking their language. But there was a more junior engineer that had done most of the actual work, and I felt he should be the one speaking to show it off, precisely because he didn’t have a lot of experience presenting to leadership. It was a risk. But I insisted. That night, I stayed late helping him rehearse the presentation and refine the speaking points and how to answer some tough questions. I was on standby the next morning — if he got in trouble, I was ready to help him out. But I kept my mouth shut and he did a fantastic job.

It would have been easier for me to do the presentation. It also would have been (possibly) lower risk. Probably even better for my own performance review, since I could claim that achievement. But I strongly feel great leaders bring people along with them. This presentation was a growth opportunity, but it had more value as a growth opportunity to the other engineer than it did to me. And I strongly believe that even for my own career, making longer-term investments in growing others around me benefits me more than whatever short-term gains I get by doing the work myself and claiming it in the next perf review.

During Period B, I had a number of people around me that created that exact exposure (sometimes managers, sometimes Principal Engineers that I trusted and respected). They put me (sometimes against my own will, but always with good intentions) in situations where I needed to step up. I’m pretty sure many times this was risky to them, but they took a chance on me, and because I knew they had, I didn’t want to disappoint them, so I worked extra hard to deliver.

I recently found a fantastic talk by Sylvia Ann Hewlett that perfectly and eloquently articulated what this is and why it matters: sponsorship. This is different from mentorship. As a mentor, you can say, “oh well I gave advice and they didn’t follow it” but when you sponsor somebody, your skin is in the game too.

During Period A, there were a number of managers that shielded me from a lot of that. I think at times they simply grabbed the growth opportunities and exposure to senior leaders for themselves, to help their own careers. Back in the nineties, before the Nadella days, Ballmer’s Microsoft was a toxic testosterone-filled workplace with an every-man-for-himself attitude. It was very risk averse. There was an unwritten fear of failure in the culture, so taking a chance on a person where it may or may not work was not common (so glad to see the cultural chances Nadella has accomplished recently!)

Back to Period B: Amazon’s culture of experimentation came with a healthy level of comfort with occasionally failing. I created the load and performance testing platform still used today to ensure thousands of services can handle peak traffic. It wasn’t something that somebody told me to do, it was something that I thought needed to be done, and I just did it. I grew the platform organically, bottom-up. It first was a weekend and nights pet-project. I then wanted to be more serious about it, and I pitched the idea of spending work time to my boss. She peppered me with questions to make sure I knew what I was getting into, and then, somewhat convinced, said, “ok, you have 3 months of freedom to chase this.” Three months later, it had been adopted by enough people that she asked me to make a more refined pitch to VP so that a few people could help me out. He too peppered me with questions, then gave me another six more months and 3 engineers. After that, I did another pitch to my senior leadership and convinced them to fund a real team to grow and permanently support the product company-wide. It became a business-critical piece of infrastructure that has saved the company millions of dollars. It wouldn’t exist today had those individuals not given me their sponsorship.

Role models matter

I didn’t have a lot of strong role models around me in Period A. I think perhaps the every-man-for-himself culture that Ballmer fomented around Microsoft in the 90s incentivized individuals to be visible to leaders above them, where being visible to more than junior engineers below wasn’t particularly rewarded.

In Period B, Amazon had the cult of the Principal Engineer. PEs were not just more visible, they were expected to be clear role models. When I became a Principal Engineer, one of the criteria for the promotion was exactly that. I knew people whose promotion to PE was held back because of behaviors that weren’t indicative of a ‘role model.’

Having role models highly visible was hugely beneficial to me. For the first time, I could see, crystal clear, these are the individuals whose behavior the company rewards and what I should be emulating.

Sometimes, everything just lines up

I am convinced that no matter how hard you work, no matter how smart you work, you also need a stroke of luck to get fast-tracked.

In my case, I created (by serendipity) a technology at the exact same time that Amazon needed it (load and performance testing at Amazon scale). I could very possibly have created it two years too early, and nobody would have cared. Or I could have created it two years too late, and by then somebody else might have beat me. It was at the exact inflection point where Amazon services were surpassing the millions of transactions per second mark, and load testing was transforming from a nice-to-have to a must-have. You could argue that maybe I just happened to have my eyes wide open and had the judgement to proactively identify something that was needed — and the willingness to act on it. I think it was just the universe lining up for me. There were other internal intersecting efforts at the same time that could have won. I both competed and collaborated relentlessly because I genuinely believed my technology was best. But again, some luck there too.