The importance of being an Exemplary Practitioner
Falling in love with coding again
Many years ago, at an Amazon offsite, we came up with tenets to articulate and perpetuate the guiding values and expectations of Principal Engineers (“PEs”) at Amazon. This is not to be confused with the more well-known Amazon Leadership Principles, which apply to all amazonians. The Amazon Principal Engineering tenets apply to PEs and build on top of the standard leadership principles. One of them is Exemplary Practitioner.
Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implementations. Only by being close to the details can we earn the respect needed to be effective technical leaders.
This is one of the hardest tenets to stick to as a PE, simply because you get pulled into so many different directions. You are a part of your Director’s Staff, and in some cases your VP’s Staff, with the abundance of meetings that come with that territory. PEs are essential in the performance review and promotion process of an organization, because as individual contributors they bring different data points from the ones that managers bring. Likewise they are critical partners to managers in creating yearly roadmaps (at Amazon, “OP1”, at Google, “OKRs”). But PEs are also tasked with thinking even more broadly and strategically about what the world will look like years from now, and shape it, often via whitepapers and never-ending socialization of the ideas with influential leaders. Among all things PEs do, coding often takes a backseat.
I’ve come to realize that I had slowly and gradually strayed from that tenet of Exemplary Practitioner, and I recently have made deliberate strides to honor it again. This is the story of how I drifted, and how I came back.
A long time ago in a galaxy far, far away, I wrote code
Writing code is an integral part of who I am. I started coding when I was 8 years old. When I was 15, I immigrated to the United States because the US was the epicenter of the computer revolution. I continued coding almost every night throughout high school just for fun. In college, I knew I wanted a degree in Computer Science, so I continued coding. By the time I graduated in 1997, I got a job at Microsoft, so I continued coding. I joined Amazon in 2009 and continued coding. There, among other things, I created the load and performance testing platform that Amazon uses to ensure thousands of its services were ready to handle peak traffic (“TPSGenerator”), about 100,000 lines of Java. In 2014, I was promoted to Principal Engineer (in part because of all that code I wrote!).
But one of the things I realized as I progressed to Senior Engineer, and then to Principal Engineer, is that the roles tended to have less and less coding. Being promoted from Engineer I to Engineer II is about doing what you were doing before, but faster, better, more independently. This is the level at which you generally code the most. Being promoted from Engineer II to Senior Engineer requires you to be a team leader and to leverage your work beyond yourself. Being promoted from Senior Engineer to PE is all about scope, influence and impact to an entire organization, so it requires yet again a mind shift.
A thought framework on Leverage
Shortly after I became a Principal, my mentor sat down with me for an hour and patiently explained leverage. He spelled out that in my new life as a PE, I was going to have to make constant hard choices about whether to work on X or Y or Z, and I needed to be deliberate about it.
To explain leverage, he used the pulley analogy. Pulleys reduce the force necessary to lift a weight. In the picture below, the pulley on the left requires a force of 100N, but the second pulley only requires a force of 50N to lift the exact same way. This pulley is more leveraged, because it gives you more output for your effort. The pulley on the right is even better because it only needs a force of 25N to lift the same weight!
I think of different types of work in my day-to-day life as being like different pulleys — some have 2x ROI, some 4x ROI, of others.
Let’s say you’re working 40 hours per week and you want to increase your output. If what you’re doing is not leveraged, you will need to increase the number of hours you work, because your output scales linearly in relation to your hours of effort. That’s the pulley on the left. But the number of hours you spend at work is finite and you’ll eventually run out of output you can generate. On the other hand if you are influencing others and getting work done through others, those are higher-leveraged activities (the pulleys on the right). With the same time investment you can achieve significantly higher output.
So here is where I (unknowingly and gradually) started straying from being an Exemplary Practitioner.
You see, when measuring leverage, coding does not score particularly high. It is very much an individual activity. I’m not saying the code you write can’t be hugely impactful… it can: I know of an engineer who saved Amazon a million dollars with a 2-line code change (in an extremely high-throughput service, instead of instantiating an expensive new object in a tight loop that was called thousands of times per second, he created a single, thread-safe, static instance of the object). Yes, code can be impactful, but No, it is not highly leveraged.
To contrast, code reviews are more leveraged than coding. Why? I could spend 10 hours writing my own piece of code, or I could spend those 10 hours providing feedback on 10 code reviews to more junior engineers. If I provide feedback on 10 code reviews, I can influence 10 people. I can instill best practices on an entire team, which I wouldn’t be able to do if I was just spending my time writing code.
Designing is an even more leveraged activity. I could spend those 10 hours writing a design doc or a product vision doc that then guides an entire team of engineers for years as they implement it.
But participating in design reviews (providing feedback on other people’s designs) is even more leveraged, because in 10 hours you can participate and influence 10 design reviews, each one of which may guide entire teams of engineers for years. At Amazon, Principal Engineers were expected to be active participants in design reviews company-wide.
There was another dimension in which I was looking at my work that further contributed to me straying from being an Exemplary Practitioner.
I started thinking: what were the things I could bring to the table that made me uniquely valuable? Was coding it? No, not really. Everybody in a software company codes. I was not special. That’s not a place where I added unique value. I’ve never really bought into the myth of the genius programmer that single-handedly and in a vacuum writes code that is so amazing nobody else could have written it, that Hollywood romanticizes in every movie made about the founder of a software company. Plenty of engineers can write code for significantly less money. But leadership, reducing ambiguity in a complex space, driving consensus and aligning technical direction across many teams, cementing product vision, navigating both business and technical needs, leveraging my years of experience to ensure we’re working on the right thing, coaching, mentoring, growing others, these were things that not every engineer in the industry can do, and those are areas where I provide unique value to my employer. I know they sound a bit like platitudes but they really are the core responsibilities of Staff and Principal Engineers.
As I reflected upon this, it was clear that as much as I loved coding, I needed to shift my focus onto other areas where I was more leveraged, and more valuable. And so my IDE started accumulating dust. I was still active in code reviews and design reviews, as more leveraged activities where I could continue being technical. I did occasionally dust off my IDE and wrote a product feature here and there.
At the end of the day, I was effective and impactful. I got good performance reviews as a Principal, and started inching closer and closer to Senior Principal. But as I did that, I wrote less and less actual code. And I wasn’t alone. If you look at the data from any large software company, you’ll see engineers code less and less as they grow in the ladder.
Moving to Google…
In 2020, just as the world was beginning to shut down because of covid-19, I decided to join Google, after 11 years at Amazon.
Overnight, a few things changed.
I was now a Senior Staff Engineer with zero technical artifacts to my name. That was extremely disorienting. At Amazon, even when I wasn’t actively coding, people knew I had architected, and written a good chunk of TPSGenerator and a bunch of other products. Tens of thousands of lines of Java had my fingerprints everywhere in their git history. I was a prolific speaker at internal conferences. I wrote whitepapers left and right. There was a huge paper trail attesting to the fact that I had tech chops, that lent credibility to my presence. I had built that credibility over a decade of creating technical artifacts, and I lost it the minute I handed in my resignation at Amazon. When you join a new company as a Staff, Senior Staff or Principal Engineer, it takes years to rebuild technical artifacts and landings to give you that level of credibility. And you need credibility to lead without authority.
Secondly, I was now a Senior Staff Engineer with zero knowledge about the internals of how tech worked in my new company. Large software companies (I’ve worked at Microsoft, Amazon and Google) have massive ecosystems of proprietary, internal developer productivity tools, organically built over decades. I had accumulated a wealth of knowledge on the amazon toolchain in my 11 years there (even significantly shaped said toolchain since I worked on engineering productivity). So even when I wasn’t actively writing code, I knew every tool’s idiosyncrasies inside out from years of using them. I knew obscure facts about why certain features existed or didn’t exist, why tool X was a better choice for a particular task than tool Y, or why a particular technical approach was not going to work, so I could confidently guide technical decisions around me. Again: I lost all of this the minute I handed in my resignation at Amazon. I had to rebuild that knowledge from scratch, and during a pandemic when we were all working from home and I didn’t have the benefit of just turning to the person sitting to my left or right at the office and asking “How does this work?” or “Can I buy you coffee and you explain why X works this way?” The solitude that came with covid-19 work-from-home exacerbated everything.
I had an immediate choice to make: fix my weaknesses (close technical gaps) or double-down on my strengths (leadership and broad vision). I chose the latter, because it was a way to get impact quickly and establish myself in a new environment. In retrospect, I was too focused on the short term. I had a wonderful manager that gave me the freedom to pursue what I thought was right, but my stubborn Amazon reptilian brain was overly focused on proving myself as soon as possible. You always have to walk a fine balance between learning and delivering.
I eventually decided to pivot. General knowledge of computer science fundamentals, general knowledge of distributed systems, was only going to get me so far: I needed to understand How Google Works Inside. The only way to do that was that I needed to go back to basics. Roll up my sleeves and “get my hands dirty.” The only way for me to be a solid technical leader was to walk in the shoes of the engineers I was to lead. No amount of reading about the things was going to suffice, I needed to actually do the things. I faced a huge amount of atrophy: I tend to be a broad thinker, more comfortable oscillating in a large organization of many teams and thinking about where it needs to be in 2 years, but for my own growth I needed to do the exact opposite. I needed to be an engineer in a single team, grab a regular chunk of work, work on it today not tomorrow, and get those code reviews going asap. I was lucky to have a peer that patiently pair-programmed with me for a while, so I could soak up knowledge from him. I had to become comfortable asking stupidly embarrassing questions with no shame.
And, I fell in love with coding, all over again.
Where I stand today
You’re going to write less and less code as you grow in your career. There’s many ways to remain technical. Participate in design reviews, relentlessly read books and technical blogs, listen to podcasts. I do those things. But coding is the core of being technical and you should never stray too much from that regardless of your level.
This is why I like the way “Exemplary Practitioner” is articulated. I think it’s imperative that Staff and Principal Engineers continue writing some amount of code. It’s not a primary objective, and it’s not a highly leveraged activity. But writing code gives you empathy and a deeper understanding of the actual challenges the engineers that you lead face, and it creates a bond of trust with those engineers. I’m proud to roll up my sleeves. It creates technical artifacts that lend you credibility. And by touching the code in my products, I also develop stronger opinions about how that code should evolve.
I’m thankful to Google for giving me this opportunity to get back to what got me here in the first place. I’m nowhere near being an “Exemplary Practitioner.” I probably will never write as much code as I did when I was a more junior engineer. But Exemplary Practitioner is an aspirational goal and a north star for me with every code review these days.