Some Indications You Might be a Principal Software Engineer
Or at least, ready to think about that promotion path...
I want to share some recent thoughts on when a Senior Software Engineer is ready for promotion to the Principal Software Engineer (PE) rank. These are observations I’ve made in past years, in the various organizations I’ve worked.
The PE role isn’t well defined across the industry, with each company having their own definition of when somebody is ready for promotion. In smaller companies, you likely gained the role by being the most productive developer on the team. In larger companies (such as the FAANG companies) there are strict guidelines on promotion readiness, including leadership qualities, coding skill, breadth and depth of experience, scope of your impact, and the ability to think strategically.
I doubt my observations will appear on a formal job description, but they are early signs of readiness for the role. Specifically:
Does the engineer say “we” to mean their team, or the whole organization?
Does the engineer raise problems, or do they solve problems?
Let’s see some examples of each…
1. Saying “we” to mean the team, or the organization
As a Principal Engineer, you don’t belong to a single team (of 6-8 developers), but will instead oversee many teams - perhaps an entire organization (100+ people) with multiple managers, directors, and a VP. You must always think about the organization as a whole, without excluding any of the teams, and without “taking sides”.
Therefore… when I hear a Senior Engineer say the following things, I know they’re not ready for the PE role.
We (on my team) have adopted this approach. You (on your team) might want to try it.
We made a code change on the backend side, and you’ll need to make a similar change on the frontend.
We did the work on the JavaScript side, but your team can port it to Kotlin if they want to.
These innocent statements tell me the engineer thinks in terms of we and you, rather than thinking on behalf of the organization as a whole. There’s nothing wrong with team pride, and ownership over what the team builds, but it’s not a good approach for the Principal Engineer to only think from one perspective.
Instead, they should redefine “we” to be the organization as a whole, and to think on behalf of all teams, not just one. For example:
The platform team has seen good results with this approach, and we should have other teams use it too.
We made the code change on the backend, and we’ll also need to make a similar change on the frontend.
We did the necessary work in JavaScript, but we could also make use of a Kotlin implementation.
It’s a subtle difference in wording, but is a good indication the engineer is thinking on behalf of the whole organization, not just a single team.
Well… that’s easy to say, and I’ve encountered problems with achieving this goal. For example, if you’re a newly-minted PE who was once a member of a single team (you were promoted into the role), you’ll likely struggle with perceptions.
Other engineers who knew you before your promotion will likely play the “we” and “you” game, and they’ll pigeon-hole you into your previous role. This is not intentional, but they were so comfortable with you in your previous role, it’s hard to adjust. Try working with different teams on different projects to break that perception.
If you’re an expert in a specific programming language, and you continue to work in that area, you’ll be closely associated with the teams using that language. Try working in different programming languages to break the perception. Be very public about the code you’re writing so people can see your range of skills.
Be careful where you sit in the office - if you sit too close to a single team, others think you’re part of that team. Move around from time to time, or sit near to the senior management who are seen as team-agnostic.
Be sure to work on projects that are cross-team, and spend equal amounts of time with each team. Bond with the team members to be accepted as an honorary member, rather than as a outsider.
Give presentations to the whole organization on a range of different topics, breaking the perception you’re associated with a single team, or one technology.
But most importantly, when you say “we”, you should be talking about the whole organization, not just a single team.
2. Raising problems versus solving problems
A typical indication an engineer has reached Senior Software Engineer status is they feel comfortable complaining about things. They know the software well enough to understand the weaknesses, and have been a team member long enough to know the organizational problems. They’ve seen the same issues occurring over and over again, and feel confident in voicing their concerns. They’re also able to anticipate problems before they actually occur. A great skill to have!
For example, I’ve heard these complaints many times, including from my own mouth:
We never spend enough time refactoring our code to remove technical debt.
Management doesn’t give us enough time to test our code properly.
Why don’t these new engineers know what they’re doing?!?
Unfortunately, complaints of this nature occur when the engineer starts to be Senior, not when they start to be Principal. Identifying problems is a great skill, but to become a Principal-level thinker, it’s vital to understand the root cause of the issue and to phrase the complaints as solutions:
Let’s rephrase:
We need to collect metrics to show our feature delivery velocity is slowing down due to poorly-written code. By identifying key areas of code rot, then spending 15% of our time refactoring those areas, we expect to see great than 15% in increased feature development velocity.
Based on the customer feedback we’ve collected, we have evidence that spending more time writing automated tests before releasing the software will noticeably increase customer satisfaction. We suggest delaying software releases by 2-3 weeks to write more tests, without being tempted to squeeze in new features.
Our new engineers are encountering friction in their work because they don’t yet have the necessary domain knowledge. I’ll set up some Lunch and Learn sessions to ensure they receive the training they need. I feel that 2-3 of our best engineers can share the training effort, with each delivering two L&L sessions.
Now, those statements are what you expect to hear from a Principal Engineer! Not complaining, but identifying solutions and putting those solutions into action. Even using fancy words (that sound “progressive”) enable your colleagues to trust your opinion more, and be more willing to buy-in to your ideas.
Conclusion
Hopefully these two ideas have been thought-provoking. They’re certainly not the only things indicating you’re ready to be a Principal Engineer, but if you don’t exhibit these qualities, I encourage you to think twice about asking for that promotion. Managers - you should insist on seeing these qualities on a regular basis before allowing a promotion - if you don’t see these skills, then promoting the engineer “because they’re the best we have” or “because they’ll quit if I don’t” is just misleading and not at all helpful for your organization.