Overview
During the holidays, I delved into a plethora of resources to understand what it means to be a Principal Engineer and what it takes to become one. This summary is a collection of notes that will serve as a reference for myself and others who want to be on this journey.
Note: This is a living document and will be updated as I learn more about the topic. The resources that I have referred to are listed at the end of this post.
Disclaimer: I am beginning my journey as a New Grad Software Engineer this year, aspiring to become a Principal some day. The information below might be conjecture and should be taken with a grain of salt.
Why even bother becoming one?
From what I have gathered so far, the career path to becoming a Principal Engineer is a murky affair. It is influenced by numerous variables, many of which are beyond your control:
Budget Constraints: Your organization may have budget limitations that prevent the creation of a Principal Engineer position. Sometimes, you have to wait for someone to leave, and even then, it’s uncertain.
Uneven Opportunity Distribution: Different companies often value engineering disciplines differently (e.g., infrastructure vs. product engineering).
Team Composition: If your current team is already very senior, it becomes increasingly difficult to demonstrate unique impact.
Managerial Support: Lack of support from your manager or team transitions (e.g., management changes) can reset your progress.
Organizational Culture: Sometimes, organizations value individuals based on their visibility rather than their actual impact, allowing more outspoken individuals to advance more easily.
Considering the aforementioned some of many reasons, one could be forgiven to think that it is worth settling in the clutches of a stable Senior Engineer position without even trying to go higher. It requires a great deal of patience and particular set of skills to get there. But we will explore this journey together.
What does a Principal engineer do?
According to many in the industry, the more senior you become, the more challenging it is to succinctly answer the question, "What do you do in a day?" However, one thing that has become apparent to me is that this role is characterized by a notable shift: influencing decisions more by understanding the organization's needs and less by what you are personally motivated by. The progression to Principal Engineer involves less of solving problems yourself and more of enabling others to solve them and make decisions.
It often involves doing a lot of glue work, tasks that are invisible but essential in facilitating the team's progress. The role requires you to maintain constant credibility while exercising remarkable restraint. For instance, even if you find an intriguing project to work on, you may have to pass it on to another engineer who would benefit more from the experience.
Skills to develop
The text below is a concise rehash of the topics mentioned in the book "Staff Engineer" by Will Larson, Youtube videos by Steve Huynh at "A Life Engineered", and various disparate resources across the internet. This section of the document will be refined frequently to serve as a quick reference guide for myself and others.
Use the links and references to dive deeper into specific topics. Utilize the index on the right to navigate to your section of interest.
What to work on? (And what not to?)
A sad reality of tech career progression is that even as responsibilities outside of work increases and the time available for work shrinks, the expectations around impact keep growing. Depriving yourself from sleep and family time is simply not sustainable. Therefore, we will explore what are some ways that we can create meaningful impact in less time.
In the book Staff Engineer, Will Larson listed the below types of work based on the Effort-Impact matrix:
Avoid: Work in the 3rd Quadrant (Low-impact, Low-effort) keeps busy but accomplishes nothing.
- Termed as Snacking in the book.
- Little to learn from and better left to others who might benefit from.
Avoid: Work that is similar to above but is highly visibile (eg. Creating a flashy metrics dashboard for leadership vs solving core backend issues like scalability and efficiency).
- Termed as preening in the book.
- Often rewarded by companies that conflate impact with visibility.
- If this is your company and you are plan to switch companies in future, optimize your strategy for your current company's promotion criteria by doing such work. Since, your attempts on creating actual impact is going to be neglected anyway.
- If not, then strike a balance between work that matters and work that is visible.
Avoid: Less obviously, it is common for companies to invest resources on low-impact, high-effort projects due to misinformed incentives.
- Be critical in identifying them and eschew if possible.
Work in the 1st Quadrant (High-impact, Low-effort) is challenging to find as they are evident and everyone is looking towards them. Pay attention to areas where not many people are looking at.
- Documentation: Often overlooked but is highly useful for the team. Create documentation for onboarding new engineers, for the architecture, for the design decisions logging, etc. More about documentation below.
- Developer tooling: Setting up CICD pipelines, improving the test coverage, writing scripts to automate repetitive tasks, or writing scripts for setting up development environment for new folks. These facilitate the team to move faster.
- Proof of concepts: Often the organization is hesitant to invest in new technologies or services. You can invest time in them (outside of organizational bandwidth), to demonstrate its value. However, be wary as these types of work are often underappreciated and can even be forgotten as time passes by.
- Anticipating Future Needs: Based on the organization's future priorities (e.g., an upcoming project), you can anticipate needs and work ahead of time to save time.
An often overlooked area is growing people around you. Some of the ways are:
- being proactive on slack to offering help.
- performing good code reviews.
- helping debug issues.
Other ways to be useful are:
- helping a good engineer scope a project into actionable milestones.
- helping them in getting organizational buy-in.
- As you get more senior, you can involve subordinates in decisions, discussions and ultimately sponsor (let them take the lead with your support) to repeat the same success for them, that brought you there.
Communicating your ideas
Writing forces you to think comprehensively about your thoughts and beliefs. Here are some tips to write effective documentation:
While you should always write extensive and detailed documentations, the opening paragraph of any document is by far the single most important thing
The Opening Paragraph: Give the summarizing idea before the individual details. Controlling the sequence in which you present your ideas is equally important.
- The opening paragraph should explicitly capture the issue, how it is affecting the business/team/project and how it can be addressed.
- Suppliment the problem with as much metrics and data (graphs, tables, etc.) as possible to keep it objective.
- Additionally, perform a quick Proof of Concept to validate the idea when appropriate so that your proposal does not come across as watery.
Two good formats for a clear opening paragraph are the SCQA and the Minto Pyramid Principle. These formats can also be used for presentations.
Most of the times, you won't be able to go through the entire document during a review meeting. However, a well defined opening paragraph is enough to spark an important conversation.
- Remember, a good meeting is one where everyone is engaged in a discussion, not where every topic in the agenda is addressed.
Meetings usually start with an agenda. For adhoc meetings, define the purpose and make sure that everyone is on the same page.
Writing long-living documents like architecture docs or technical specification is also a good way to gain internal visibility.
Actively gather feedback from peers on your documents. But write the documents alone. Most people are good critics but not good writers.
- Gathering feedback and actually incorporating then in your document is also a great way to show respect for your coworkers.
Write decision logs for important projects. Write down the process of finding an answer along with the rationale behind them.
- This helps folks to learn from the decisions that we make rather than just being directed by them.
Maintaining credibility
Building credibility is a time consuming process and maintaining it requires being deeply aligned with your direct manager and your sponsor(if any). Remember, you are the one responsible for setting your company, your team and your manager up for success, not the other way round. Below are some ways to get and maintain credibility:
Never surprise your manager; it harms trust. Ensure your manager has complete visibility into your work.
If you are a leader, your success is determined by the alignment of your team with the agreed-upon approach.
Proactively ask for feedbacks from your manager on your work during 1:1s.
- Ask for areas you should be focusing on.
- Make sure that your current priorities align with your manager's.
- If you have issue, don't withhold it. Inform your manager about it.
Bring useful information to your manager.
- This could be about the team, the project, etc (eg. The new code review policy is not scaling well with development pace).
- Do not present problems without a solution.
Alongside having a supportive manager, you absolutely need a supportive sponsor who will be able to vouch for you against organizational friction during important conversations.
- Senior leaders who have seen your presentations, nodded in agreements to your ideas, etc are more likely to be your sponsor.
- Your direct manager and your sponsor must always be informed about your goals. Don't withhold anything.
You need to proactively perform enough actions such that it is easier for your manager (or sponsor) to help you. A good way to do this is asking for feedback on your promotion packet regularly.
Ask specific questions that will eke out useful answers (specific questions are generally easier to answer), rather than vague unhelpful answers.
- eg. "I am wondering how to version our APIs. Should I use path based versioning or HTTP header based versioning?" → A question as specific as this does most of the job for the answerer.
- Refrain from asking vague questions like "What should I do this year to increse my chances for a promotion?". → Most folks stick to giving unhelpful answers like "you should do more impactful projects" rather than just saying "I don't know".
While you don't need to spend much time with your skip-level manager, they absolutely need to be familiar with your work's impact to the extent that they remember them in the next two months. Skip managers can help you find a different team if you ever need to switch.
Influencing decisions without friction.
Career growth is more about being easy to involve and staying in the room than just being technically right while sucking the oxygen out of the room in the process. Below are some ways to influence people to think your way (slowly) without getting kicked out:
It is often possible that your vision does not align with other senior leaders.
- Be cognizant of the distinctions between the different perspectives and find a way to merge them.
- The goal is not to change their mind, but to understand the constraints and figure out ways to adapt your plan according to their priorities.
Effective leaders dont split the world into a leader/follower dichotomy. They move in and out of both roles as needed.
- Do not dilute yourself into everything that comes up.
- If you disagree with something in a minor way, let others take the lead. (eg. "Will the decision matter in six months?" If not, then take the opportunity to follow).
- If someone you trust is leading the project, believe that they will get to a good outcome.
Provide non-blocking feedback to the team. For example,
- classifying code review comments as "optional nit"
- reframing written feedback as a perspective rather than something that requires immediate change.
Meetings and technical discussions do not have to be zero sum games. Each meeting is one round in the broad context of the project.
- Misalignments are often caused because there is some missing context.
- Focus on adding more perspectives and opinions to the Shared pool of meaning, to facilitate better decision making.
- Focus on finding the best outcome for everyone.
- Don't force an agreement on an approach. Identify what needs to happen to get everyone aligned.
Asking good questions is a way to understand different perspectives.
- Good questions are very specific and asked with a desire to learn.
- They free the answerer from the obligation to defend their position.
No matter how senior you are, remain skeptical of yourself.
- Be open to feedback and be willing to change your mind when necessary.
- Even if you get a critical feedback, do not show resistance. Reflect on it, and focus on changing their mind later with more relevant data to support your argument.
When dealing with people who never budge by always trying to be right no matter what (jerks)
- (1) include their direct manager in the meeting (or someone whom they cannot be jerks to). or,
- (2) invest heavily into aligning with them before the meeting so they are less likely to derail the discussion.
Communicating your approach within the limited time, married with a lack of familiarity with the topic from management is challenging. Additionally different people are accustomed to consuming information in different ways.
- Some prefer more data, some lean towards pattern matching each presentation to one of their previous experiences.
- Invest heavily ahead of the discussion.
- If possible, get feedback from an executive attending the meeting.
- Speak clearly and concisely. Contribute more ideas in less time.
Taking the time to organize your thoughts before a meeting, being attentive and engaged throughout and being useful by taking notes can pay heavily.
Networking
This is probably one of the difficult areas for people with a strict technical slant (like me) to improve on. However, it is crucial to build a network of peers having similar interests. Below are some ways to build a network:
It gets lonely the higher you go. It is important to have people around who will challenge you or brainstorm ideas with you, regardless of your ranks.
One way of networking is being easy to find.
- Contribute to discussions, write blogs, speak at conferences, etc.
- Be active in meetings by sharing your opinions. This often helped me spark useful discussions.
Networking is easier in your current company, where it happens almost semi-organically. Long-term, these folks will spread across the industry, bootstrapping your broader network.
Quality matters. Volume doesn't. Build connections with folks you genuinely trust, respect and are inspired by.
The book recommends a good template for approaching people: "Message someone you respoect with a short paragraph with a specific question asking for advice. If they reply, thank them and send another question in 6-12 months. If they subsequently ask something, do what you can to help, else move on."
A final word
It was a toiling yet highly rewarding task to collect these notes from my recent stint of learning on this topic. I hope to add more useful information and refine the existing ones as I learn more. I want to end it for now with this line I am in awe of, from the book "Staff Engineer":
The only way to remain a long-term leader of a genuinely successful company is to continually create the space for others to take recognition, reward and the work that got you to where you are currently sitting.