The manager’s path

I bought and read The Manager’s Path by the awesome Camille Fournier when it first came out. At the time, I was a senior Database Engineer aspiring to become a principal engineer in my organization. At SendGrid, principal engineer and principal engineer 2 are manager and director level roles respectively without having human direct reports. We had just overhauled the career ladder to provide a full technical ladder, and I now had the opportunity to grow that did not require going into people management. It is not that I disliked managers or that I think it is easy work. To the contrary, I very much appreciate the complexity of engineering management work but I felt that I wanted to strengthen my technical expertise and solidify my career as an individual contributor before considering going fully into people management.

Now, 2 years later, I have been a principal engineer for a year. I am now closer to more technical strategy decisions than I used to be and I decided to read the book again. The title of the book and its stated goal might be laying out the path in engineering management up to senior leadership, but reading it made it clear to me that the book is also of great value to individual contributors to help explain what all these titles mean, what each layer of management is supposed to focus on, and how engineering concerns converge ultimately with business concerns and crystallize into a strategy for a technical organization. I also realized that while I am still an individual contributor, the principal engineer role carries enough cross-organization work, and enough people skills, that it is much closer to management than it may seem without engineers reporting directly to me.

Career ladders and the myth of a flat org

It surprises me that many shops still claim to have a ‘flat org’ or claim that they do not believe in titles. I have heard it said about data stores that ‘all databases have schemas…even the ones that say they do not’ and I think the same applies to organizations that are larger than a small handful of individuals. They may claim or even believe that they are not encumbered by the politics of titles and organizational hierarchy but that simply means that the power structure is there and implied and not based on clear milestones or competencies either. When companies’ engineering teams grow past a handful, the engineering leadership has to document explicitly what they consider are the competencies of a senior engineer, not leave that up to interpretation. Implied competencies are easily colored by personal bias, both implicit and explicit. And these biases are a quick way to lose competent engineers.

Principal. Not senior senior

One of the most common steps in defining titles when a company is hitting its growth stage is adding ‘Senior’ to the moniker of engineer but soon enough, especially if retention is good and people are staying on board a number of years, companies realize they need more than just a 2 level engineering ladder. This is where titles like ‘principal’ or ‘staff’ engineer become part of the defined career ladder. However, principal engineer should not be seen as a natural progression to senior engineering levels. It is an IC position that is on a different playing field as it involves competencies that no longer apply to only technical prowess. For an engineer to get to the Principal Engineer level, there needs to be cross organizational collaborative signals, there needs to be a clear understanding of architecture and design decisions that go far beyond the immediate technical area of expertise.

A force multiplier

Once I became a principal engineer, it quickly became clear to me that my job involved a lot more than closing tickets and writing code to achieve things. Yes I am still a maker not a manager and I do not have anyone reporting to me but my new position now requires leadership duties that are best not left implicit or not handled with the same outcomes oriented focus as my past coding assignments. One of the most important competencies of a principal engineer is to become a force multiplier. This is a much more mature definition of ‘10x engineer’ than the Silicon Valley cargo cult likes to use. A PE does not produce 10x the features or fix 10x the tech debt tickets. A truly valuable PE makes their whole team better by advocating for best practices, gently reminding people of why the processes we have exist, and helping the less experienced engineers find ways to ‘level up’. A good PE can speak to technical aspects of the product, connect planned work to business strategy and to what makes the company more successful and maybe most importantly, have the interpersonal skills to influence others around them towards these goals.

This is why promoting any engineer to PE without clear skills in more than just ‘the code’ would be a disservice to the team and a bad signal for the rest of the organization as to what things management actually values when it comes to the non manager career track. If you want to watch and see how the ‘brilliant jerk’ anecdote came to be, it is those promotions to senior IC titles based solely on code output and not all the value that inter human skills can bring into getting large numbers of humans rowing in the same direction.

Cheerleader, recruiter

One thing the book especially focuses on explaining is “what does that person do, anyway?”. It lays that out by showing when/at what point a ‘manager’ changes focus from day to day tactical to the long term strategic. And few things are more strategic to a company than its ability to recruit great engineering talent.

Managers carry a responsibility towards recruiting and representing the company well. That’s an obvious fact. As a principal engineer, recruitment is one of your responsibilities.

When working at the senior engineer level, the focus is more on “getting tickets/projects done with little to no direction” and “being proactive in fixing tech debt or helping solve problems/bugs”. But once i became a principal, it became clear that by virtue of being one of a few, i now carried a larger impact on morale, organization culture and even on recruiting and representing my engineering organization outside of the company. Behaviours I display, either at the office or at tech events, are now a display of the behaviours my company rewards. My behavior is a signal to anyone who may consider working in my organization of whether we align in values or not.

Manager?

A few years ago I was where a lot of senior engineers (maybe more the women than the men) tend to be:. at a fork in the road. Do I become a people manager or do I stay in a technical IC role and focus on solving technical problems?

Trick question! Once at a certain level, all problems are solved by people. There is no such thing as ‘purely technical problems’. In fact, this is the level where one wishes more problems were purely code because we can make code do a lot of things. Making people do anything is harder and influencing people to do what we want is harder still. This is what principal engineering is about. The role is far less about solving intricate technology problems (although there is that too) and more about being a good influence, convincing the rest of the technical team why Thing A should be solved with plan Foo and not plan Bar. There is a lot of solving for other people motivations, finding the right message for each audience while still working towards the business goals at the end.

What’s next

The past year and a half working as a principal engineer have been eye opening into all the work that goes into getting a large group of humans all rowing in the same direction for the business to achieve planned goals. It is no small feat that is further complicated with our ever growing, ever complex systems of scale. I do not know whether my experience as a principal engineer will some day translate into becoming an engineering manager someday. Maybe it will. I do know that if I ever made the move to managing people that my time as a principal engineer has taught me plenty that I may have missed out on when focusing only on senior engineer competencies.

Many thanks to Tanya Reilly and Sean Kilgore for both being great examples and for their excellent feedback on this. And to Camille Fournier for writing that book.