Introduction

This article is about what is a principal software engineer.

I have worked as a Principal Software Engineer in multiple companies, like AWS and Google.

What is a Principal Software Engineer?

The definition changes between companies. Some call them staff engineers. In some other companies, they are also team leads.

So the definition in the tech industry is very inconsistent.

Let’s define some key concepts that define a Principal Software Engineer, in my opinion:

• They are Individual contributors (IC).
• They know a lot of technologies and can choose the right ones for the right job.
• They push new technologies in the company stack (pre-approved technologies).
• They influence other engineers.
• They teach not only software developers but everyone in the company.
• They do NOT manage people.

They are an Individual Contributor.

A Principal Software Engineer writes code. Not a lot of it, as they attend too many meetings, but they write code, and SQL, do system designs, fix bugs, and go where other people are scared to go.

They do tedious external dependencies version upgrades, keep an eye on test coverage, they address security concerns for external libraries and internal code. They review the code of other developers. They are often the person who annoys everyone, asking for more logs, more metrics, better error handling, and better algorithms in a crucial part of the code. They know when it is time to be less strict.

There are times when you can lower these restrictions, but not all software features have the same importance.

In e-commerce, the features that must always work are: viewing products, adding to the cart, pay the cart. Everything else (suggestions, past orders, preview of shipment fees, marketing emails) is less critical, so it can be messed up (but must, in any case, be fixed as soon as possible)

They know a lot of technologies and can choose the right ones for the right job.

A Principal Software Engineer must be opinionated. They must know the difference between languages, datastore, and other glue technologies.

They must not follow the hype. A Postgresql database is still the best way to solve most problems. Keeping data on S3 and using AWS Athena can solve other issues. Java is suitable for solving problems, Go can solve others, and Rust is fast and nice, but the build time is painful. Can Python be used for request intensive APIs? Yes, if the task is not CPU intensive.

Keep yourself updated if you want to be a principal software engineer, don’t follow the hype, know what you are talking about, and don’t use buzzwords.

Push new technologies in the company stack

The Principal Software Engineer must constantly push the boundaries of the current tech menu used in the company. But push gently. Respect what came before. There are reasons behind the tech choices of a company, but a company must always be open to changes, and a Principal Engineer gets paid to do this.

When pushing new technologies, political capital inside the company is required.

• This political capital is already there for people who came via internal promotion because they spent time in the company creating relations between them and their colleagues.
• For direct hire at this level, You need some time to influence the “status quo”, so a principal engineer also requires good communication skills.

I say “communication skills” and not “soft skills” because I don’t like to use the term “soft skills”. It conveys that these skills are weak, but they are not. It is hard to have good human interactions for a software developer, or at least for me. I chose this job because I like machines, not humans ^_^

The Principal Software Engineer needs to propose new ideas. There will be pushback. It is expected. It is human nature. To be able to push new technologies and show numbers and metrics. If you show that migrating from JAVA to Go makes you spend a tenth of the AWS bill, you will get your beloved Go in the company.

They influence other engineers.

The dividing line between “senior” and “principal” is also the scope of influence.

A Principal Software Engineer must span across multiple teams. They know the business of the company from different points of view. It takes time to get to this level.

A Principal Engineer can be assigned to a team but can also jump between teams, working on different projects every time. Working on various projects is more of a personal/company decision.

In big companies (like Amazon AWS), the influence scope can be of at least 50 other engineers. Smaller companies have different numbers in play.

Can a small company need a Principal Engineer? The CTO and the principal engineer are often the same people for a small company. If the CTO is not skilled enough, a Principal Engineer can be needed. But the scope of problems will be simpler.

They teach not only software developers but also everyone in the company.

Mentoring developers is fun the majority of the time. They want to learn, and the common ground is helping the transmission of information between persons.

But not everybody involved in creating software is a software engineer. Product managers, UX designers, and so on are there too.

A principal engineer must explain, in simpler terms, without going too deep into the technical implementations, the limits of the technologies used by the companies, what can be done to improve and how much a technical decision can cost, in terms of money, to the company. Don’t use Buzzwords or acronyms with them.

A PM can ask for infinite customer data retention for a fast user experience on a website, but all of this has a cost. The Principal Engineer must be able to explain all of this and help the search for trade-offs.

They do NOT manage people.

A Principal Engineer is not a manager. They don’t have reports.

Their job is not to make other people happy; it could be to make other developers productive, not with organisation techniques, but to improve the development experience inside the company.

Are you building a pipeline that is taking three days to run? A Principal Engineer will try to make it run in 30 minutes. This would make everyone happier.

But a Principal Engineer is not dealing with other kinds of problems, the problems that are typically manager problems, like performances, promotions, personal issues,…

Is the Principal Software Engineer Role your next carrier step?

Think carefully about this. A promotion is always good. Everybody likes more money. But you will have more meetings and less time to code, but your code will have more impact.

Getting promoted or hired at this level is different. Going back to the topic of “having influence”, joining a company as a new hire at this level is challenging because the colleagues, managers, and the whole company, will be expecting to see this influence. But as a new hire, you will need to settle into the company standards and technologies.

So you don’t have to accept this role as a new hire? Go for it, even if you came from a senior position. What is called ‘senior’ in your current company can be a ‘principal’ in some other companies. This works also the other way around, so be aware of this.

A salary can be a good indicator of the level of the job. If a company offer you a principal software engineer role at the same base salary as your current senior-level role… probably the company is a small one. Do you have to accept the job only for the role? My answer here is no. I can sound a little bit like a mercenary but move for the money or the type of experience, not for the title. If becoming a Principal software engineer at the same salary in another company can teach you something, go for it. But do not go only for the title alone.

In the end, remember that “with great power comes great responsibility”.

Epilogue

We told you what a Principal Software Engineer is and their responsibilities.

This comes from our 20+ years of experience in the field, working with multiple companies.

How do you become a Principal Software Engineer? Follow us to learn it.