However, principal engineer should not be seen as a natural progression to senior engineering levels. This is where titles like ‘principal’ or ‘staff’ engineer become part of the defined career ladder. 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. And these biases are a quick way to lose competent engineers. Implied competencies are easily colored by personal bias, both implicit and explicit. 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. 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. 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. It surprises me that many shops still claim to have a ‘flat org’ or claim that they do not believe in titles. Career ladders and the myth of a flat org 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. 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 am now closer to more technical strategy decisions than I used to be and I decided to read the book again. Now, 2 years later, I have been a principal engineer for a year. 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.
It is not that I disliked managers or that I think it is easy work.
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. At SendGrid, principal engineer and principal engineer 2 are manager and director level roles respectively without having human direct reports. At the time, I was a senior Database Engineer aspiring to become a principal engineer in my organization. I bought and read The Manager’s Path by the awesome Camille Fournier when it first came out.