In many organizations, Principal-related roles are usually reserved for individual contributors who have proven impact over a very large group of people (>= 100 pax). In large organizations (> 500 pax), the company is usually structured into various business units. Principal Software Engineers usually look after architecture of multiple business units (or the whole company) in their portfolio, influencing engineers with strong persuasion and technical ability instead of pure authority. These engineers are usually trusted thought partners of senior leadership like CTOs.
Principal Software Engineers need to have a wide and deep array of skills, including soft skills.
Principal Software Engineers already have proven impact within their organizations or past organizations in designing complex systems. Despite the complexity of many issues, they can be solved by adhering to strong fundamentals.
At the principal level, you will find yourself exposed to various problems. Categorize your problems in buckets of Importance vs Urgency. Most of the time, you will want to work on problems that are very important but not urgent. Usually, these are structural issues that require your attention.
Sometimes, identifying such problems and solving them could take several quarters. When you are new to the job, you may want to find high-leverage but short-term problems which would give you immediate credibility. Some of these opportunities will appear during firefighting and you will be remembered if you could give a quick solution that saves the company a lot of money and time.
Either way, your primary role is to solve problems. The more problems you solve, the more credibility you will gain. Pay attention to these issues along the way:
Hone your skills to listen to others so you do not run into those issues above.
You will need to understand how software development works beyond a single team. Very often, you will find patterns that are applicable across teams / across departments. Learn how different teams solve problems in their own domains, and cross-polinate good solutions between these teams.
Because you are working between teams or even business units, you will need to understand the nuances of each domain. For example, if you oversee flight development and food delivery, you will need to understand the different kinds of problems faced in each domain. The problems faced in each domain will influence the design of the systems. Read this Domain-driven design book for more information.
You will also need to stay current with technologies and trends. This expectation does not mean you must be an expert in every framework, platform, and language but instead to be familiar with their use cases and tradeoffs. This way, you will be able to recommend various solutions together with the pros and cons when an engineer approaches you with a problem.
Spend a good amount of time:
Usually, you will have an army of engineers that are very familiar with the low-level constructs of the systems you are responsible for. However, that does not mean you delegate all decision making to your engineers. You must expect engineers to come to you to ask for guidance, and you must be right most of the time. Be very fast to admit it when you are wrong.
To be right most of the time, you need to continuously update the pool of information in your head. You can do this by:
Be involved in RFCs - Actively comment on your team's implementation, challenge them to think about alternative solutions and ask critical questions like "How can this fail?" If there isn't an RFC process, then Start an RFC process.
Use static analysis tools like Sonarqube to scan for code health.
Use code comprehension tools like CodeCompass.
Review code - Watch out for anti-patterns that engineers are making in their code implementation and suggest remedies inside the code review.
Regular syncs with engineering leads, engineering managers, engineers to sniff out potential problems and solutions.
Build Proof-of-Concepts (POCs) to find problem-solution fit for the problems you identified.
Doing all of the above will give you immense respect from engineers as a trusted authority to go to for technical guidance.
You will be talking to people at least 50% of the time. As you work between teams, you will need to:
A few caveats as you do this:
The first thing you need to do when approaching others is to see the pictures in their heads. Surprisingly few people know how to do this because they are too preoccupied with their own ideas. You can learn how to do this in the book Getting More: How You Can Negotiate to Succeed in Work and Life.
As an architect, almost every decision you make will be challenged. Architectural decisions will be challenged by product owners, project managers, and business stakeholders due to increased costs or increased effort (time) involved. Architectural decisions will also be challenged by developers who feel their approach is better. You will need to learn How to get past No so these decisions could be approved.
As you advance in your role as a senior individual contributor, you will most certainly see a need to mentor others in your company:
It's very important to approach such mentoring relationships with some structure. Without a structure, at best it becomes an 'interesting discussion'. At worst, it becomes an 'aimless chatter'. The Mentoring Manual gives very good guidance on how to create such a structure without restricting your mentee's creativity.
As the Principal Software Engineer of the company, you will be regarded as the person who will be able to see into the future, map current and future business needs to technology and design processes and systems to enable reliability and velocity. Expectations are generally very high at such a role as you are considered part of engineering leadership.
You will have to pay attention to many details in your organization and outside. Hopefully by this point, you would have already built a great Habit of reading to improve your skills.
You will most likely be accompanied by a few other staff+ engineers in your company. Collectively as a group, you need to figure out How to scale architecture as a practice in your company. As one of the primary software architects in their teams, staff+ engineers should aim to equip their teams with the best knowledge and tools to make good decisions. The last thing your company needs is an unplanned system architecture that descends into chaos.
One good way to build your technical strategy is to understand the problems your company is facing. You can learn these by studying design reviews in your company. Read more about this in Guides / Writing engineering strategy