Delving into the other side of engineering leadership.
I bought and read The Manager’s Path by the awesome Camille Fournier when it first came out, and I was a senior database engineer aspiring to become a principal engineer in my organization. At the time, principal engineer and software architect were manager and director level roles respectively without having direct reports. We had just overhauled the career ladder to provide a full technical ladder, and I now had the opportunity to grow where people management wasn’t a requirement. It is not that I disliked management or that I thought it was easy work; to the contrary I very much appreciated the complexity of people management, but I felt that I wanted to strengthen my technical expertise and solidify my career as an individual contributor before considering that trajectory.
Fast forward a few years, and after experiencing the principal/staff engineer space and the preparation I got from Camille’s book, I have a better understanding of what each of these management titles mean and what differentiates a manager, from a director, from a VP. I also realized that while I am still an individual contributor, the principal+ engineer role carries enough cross-organization work and enough people skills to make it much closer to management than it may seem, just without engineers reporting directly to me.
Career ladders and the myth of a flat org
It surprises me that many organizations claiming to be ‘flat’ say 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 but not based on clear milestones or competencies.
When engineering teams grow past a handful of people, the engineering leadership has to document explicitly what they consider the competencies of a senior engineer to be and 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 more-senior Senior.
One of the most common steps when companies hitting growth stages define their titles is just 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 two-level engineering ladder, and this is how 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 as it is not an extension of a junior IC position, but a role that is on a different playing field requiring competencies that no longer apply to only technical prowess. For an engineer to get to the principal level, there needs to be cross-organizational, collaborative signals, and 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 don’t have anyone reporting to me, but my new role now includes leadership duties. And it would be a mistake to not be explicit about these duties or their importance to business outcomes. One of the most important competencies of a principal engineer is to become a force multiplier. This is a more mature definition of the ‘10x engineer’ than what the Silicon Valley ‘cargo cult’ like to use. A principal engineer does not produce 10x the features or fix 10x the tech debt tickets. A truly valuable principal engineer 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’. They 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 they have the interpersonal skills to influence others around them towards these goals.
This is why promoting any engineer to principal without demonstrative skills in more than just ‘the code’ would be a disservice to the team, and highlight to the rest of the organization as to what management actually values when it comes to the non-managerial career track. If you want to watch and see how the ‘brilliant jerk’ anecdote came to be, it is the promotions to senior IC titles that are based solely on code output, and not on the value that interpersonal skills can bring.
One thing that The Manager’s Path especially focuses on explaining is “what does that person do, anyway?”. It lays that out by showing at what point a ‘manager’ changes focus from the day-to-day tactical work to the long-term strategy. 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, culture, and even on recruiting and representing my engineering organization outside of the company. Behaviors I display, either at the office or at tech events, are representative of the behaviors my company rewards. My behavior is a signal to anyone who may consider working in my organization of whether we align with our 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 you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem. In fact, this is the level where one wishes more problems were code-based because we can make code do a lot of things, but making people do things 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 a given business problem should be solved with one solution versus another. Though there is still a lot of problem-solving in motivating people; we need to find the right message for each audience while still working towards the key business goals.
What’s next?
Working as a principal engineer has opened my eyes to all the work that goes into getting a large group of humans all rowing in the same direction for the business. Now that I have moved further up to become a software architect, my job became “principal engineer but dial it up to 11”. I help teams see a picture bigger than their immediate backlog, help find common pain points across the technical org so I can guide everyone to a more efficient solution, and help entire engineering groups avoid landmines and pitfalls in their planning. There is a whole different post for another time on “what even is a software architect?” but for now I will say that it needs to be the farthest thing from an ivory tower.
