What is a Principal Software Engineer?

This article was written by Dave Koo.

Principal Software Engineers are critical to the success of most commercial software projects. They have the skills, experience, mindset and judgement needed to take responsibility for a wide variety of key software engineering activities, from setting technical direction to leading teams to solving or overseeing the most important and complex challenges encountered on software projects.

But it’s not a role that’s discussed as often as other software engineering roles, and the role’s definition tends to change from organization to organization.

Since the main thing we do here at Steel Toad is providing Principal Software Engineers to B2B SaaS companies and projects, we feel it’s important to clearly lay out what this role means to us. So that’s what we’re aiming to accomplish below. This will also be useful to those needing to create a Principal Software Engineer job description for a job posting at their company.

To keep things short and sweet, we’re going to use the acronym PSE from now on to refer to a Principal Software Engineer.

The Software Engineer Career Path

Let’s start by taking a quick look at common roles and career paths in software engineering to see where a PSE fits in.

The first 3 roles are pretty standard: Junior Software Engineer, Software Engineer and Senior Software Engineer. I think most engineers are familiar with these 3.

After that, engineers will typically choose from 4 directions:

1) Keep doing what they’re doing: They might just really like coding and everything their current role has to offer and not feel the need or desire for more responsibility or a higher level position. In this case, they can continue on in their Senior Software Engineer role.

2) Engineering Management: Those who like the idea of leading and managing others often choose this career path, which would usually start at Engineering Manager, then progress to Senior Engineering Manager, Director of Engineering, etc.

3) Product Management: This career path is a great choice for those who want to start shifting direction more into the business side of things. For an engineer, this career path might start out at Technical Product Manager then progress into Product Manager, Senior Product Manager, etc.

4) Staff+ Technical Track: This is ideal for those software engineers who prefer to stay as individual contributors but are interested in a more challenging position with increasing responsibility and a broader scope of impact. At a startup, the Staff+ career progression might only include 1 or 2 roles such as Staff Software Engineer and/or PSE. At a large company, the career progression might look something like this: Staff Software Engineer, Senior Staff Software Engineer, PSE, Senior PSE, and finally Distinguished Software Engineer.

A Note on Staff Software Engineers vs Principal Software Engineers

There is a reasonable amount of overlap between the Staff and Principal levels and the definitions vary from one company to another. Many of the descriptions in the sections below apply to both levels, however some are specific to the Principal level. In general, PSEs have greater breadth and/or depth of experience, greater responsibility and broader impact across the organization.

Work Experience

It’s fairly common for software engineering roles to map roughly to these experience bands (give or take 1 or 2 years at the higher levels):

• Junior Software Engineer – 0 to 2 years
• Software Engineer – 2 to 5 years
• Senior Software Engineer – 5 to 8 years
• Staff Software Engineer – 8 to 10 years
• Principal Software Engineer – 10+ years

Here at Steel Toad, all of our PSEs have 10+ years of hands-on software engineering experience in progressively more senior roles, across a variety of different projects, including 5+ years as a Senior or Staff Software Engineer.

What makes us particularly unique is that we also have 2 additional requirements for our PSEs that you will rarely find anywhere else:

1) They must have held a key engineering role (preferably Staff+) at a successful startup, since that’s who we primarily serve.

2) They must be a current or past startup founder. And not just hacking something out over a long weekend. It should be something that they’ve put quite a bit of time into (ie. at least a few months of part time work) and ideally they’ve launched and gotten it into the hands of users. Having said that, it’s totally fine if it hasn’t gotten traction. You learn a lot of valuable lessons as a founder (even if your startup fails) and these lessons, along with the mindset that is developed through that experience, are super valuable to our startup clients.

Lastly, while certainly not mandatory, we enjoy finding PSEs who have completed a “principal project” as it acts as a nice rite of passage, giving them the individual confidence as well as increased respect from their peers that they belong at that level. A principal project is typically a challenging project that has a major impact on the organization and is therefore highly visible and career-defining within the organization….it often becomes part of the organizational lore; as an extreme example, you could imagine people whispering in the halls of the Googleplex: “See that guy there? That’s Paul Buchheit, the creator of Gmail”.

So What Exactly Do Principal Software Engineers do?

Now it’s time to dive into the type of work that PSEs spend their time on. We won’t cover everything, but I’d say the sections below are the key areas.

We’ll be focussing on duties primarily at the PSE level, but in addition, you can assume that PSEs have the traits and skills you would typically expect from a Senior Software Engineer and above such as solid technical skills, high attention to detail, good time management, capable problem solving, etc.

Responsibility / Scope / Impact

One of the things that differentiates a PSE from other software engineering levels is their scope of responsibility and impact.

Junior to Senior Software Engineers are generally expected to contribute to the success of their team.

Staff Software Engineers can lead, provide technical direction, mentor and solve tough problems at the team level, sometimes contributing to multiple teams at the same time, as well as communicate outside the team.

PSEs are expected to be able to operate at any level within the organization including:

• Leading individual teams
• Having technical responsibility for multiple teams (while working closely with the team leads)
• Having technical responsibility for one or more products
• All the way up to working directly with C-level executives on company-wide initiatives.

So even though a PSE is still an individual contributor, their focus shifts away from their own individual contribution to the wider impact and broader success of:

• Teams
• Products
• Departments
• Organizations

In terms of scope, some PSEs are more breadth-focussed: they leverage their broad experience in helping teams across different areas and phases of projects. Others are more depth-focussed: they are typically experts at specific technologies and tend to spend more time coding and working in their areas of specialty. And then finally there are the T-Shaped PSEs who are a combination of both and might be the most common specimen: they are breath-focussed in general and useful in a wide variety of situations but also specialize in specific technologies.

Now that we’ve covered the big picture of scope and impact, let’s take a look at more specific duties at the PSE level.

Setting Technical Direction

PSEs excel at setting the technical direction on projects. This can take many different shapes and sizes so here are a few examples:

• Creating the high-level product architecture
• Choosing technologies for a tech stack
• Choosing which programming libraries or packages to use
• Identifying and mitigating risks during planning stages
• Technical design of critical / complex things – modules, components, features, APIs, etc
• Working with new technologies – Research, Evaluation, Selection / Recommendation
• Establishing, maintaining and promoting software engineering best practices such as coding guidelines, standards and processes

One particularly hands-on way of setting technical direction is creating sample or reference code. At Steel Toad we call this Reference Feature Implementation. Here’s how it works:

– The PSE implements a representative feature of the app that demonstrates how to integrate the different parts or layers of the tech stack into a working feature.

– The output from this activity should be a slice of production-ready code complete with things like proper directory structure, naming conventions, code style/standards, logging, tests, etc.

– If it’s a back end feature for a web app, it might include everything from sending a request to the API all the way down to updating the database, integrating with 3rd party systems, and sending the response back from the API to the client.

– Similarly, a front end reference feature would include everything from the HTML/CSS code to interacting with the client-side data store to sending requests to the server, processing responses and updating the UI as needed.

– Other developers can then use these reference features as a kind of template and follow the same patterns and guidelines when implementing more features. As a result, this is also a useful form of 1-to-many mentorship.

– Ideally Reference Feature Implementation would be done earlier in the project but it can also be done later on depending on the situation – such as the requirements changing, a new technology being introduced, a previous pattern not applying well to a different part of the app, etc.

Team Lead / Tech Lead

Almost every software engineering team has a team lead (or tech lead). The person taking on that team lead role is often a PSE or a Staff Software Engineer (although they might not have those exact titles). This is especially true when that role involves things like project management related tasks and communicating outside the team (such as with product owners, business stakeholders, other departments, clients, prospects, or executives).

A PSE in a team lead role will typically work with an Engineering Manager and Product Manager / Product Owner to help with ongoing planning, prioritizing, resourcing and scheduling at both a project level and individual sprint level.

In a Scrum setting, the PSE will often play a leadership role in all meetings – backlog refinement, sprint planning, daily standups, sprint reviews/demos and retrospectives.

As a team lead, the PSE is accountable for what software gets delivered at the end of each sprint in terms of team velocity, code quality and all other metrics that are important to the team. The PSE has final responsibility for all technical decisions that were made during the project.

PSEs in a team lead role also have many or all of the duties listed below, but since those duties also apply to PSEs who are not team leads, I’ve broken them out into separate sections.

Mentoring

Helping and guiding other software engineers can be very rewarding for everyone involved – for the mentor, the mentee and the organization.

Answering questions – It can be helpful to have a PSE available that other engineers can talk to if they get stuck and need help or aren’t sure of the best way to proceed in a given situation.

Reviews – These are a wonderful tool that PSEs can leverage to efficiently extend the positive impact they have on an organization.

There are an almost endless array of things that a PSE can review in a software company. From requirements, to product architecture, to pull requests, legacy code, processes, coding standards, and more. Basically, any artifact they didn’t create themselves could be a candidate for review at some point.

Therefore it’s important to have a way of determining what to spend their review cycles on. Generally the more something is high impact, high risk, and difficult to undo or change downstream, then the more valuable it is to the organization for a PSE to review it.

Having a PSE review something of high importance before it’s implemented is often a good use of time to help ensure that it’s following the right path and to prevent more expensive downstream issues. Likewise reviewing code after it’s implemented can ensure that it maintains the expected code quality and minimizes technical debt. Reviewing an organization’s legacy codebases is also an important step in software modernization projects.

Delegating – Rather than tackling everything themselves, PSEs can give other engineers opportunities to learn and grow by looking for ways to delegate and then follow that up with reviews and feedback, where appropriate, to ensure that the work was done to the standards expected by the PSE.

Training – PSEs often give technical training sessions to prepare other engineers for the tasks ahead and to level up their skills and knowledge. These should be recorded and stored in a visible shared location for other engineers to benefit from.

Sponsorship – This usually involves the mentor repeatedly advocating to others on behalf of the mentee. As a PSE, this is a direct and powerful way of using your influence, experience, network and status to make a noticeable improvement on another engineer’s career.

Making Important Decisions

PSEs are counted on to make decisions that could have serious consequences and possibly a company-wide impact, such as introducing a new tech stack, deciding how to extend the life of a legacy system or managing a crisis such as a major system outage.

Therefore they rely on drawing from their considerable experience and using a combination of clear-headed analysis, good judgement and listening to others before making decisions.

They consider benefits and drawbacks, strengths and weaknesses, risks, tradeoffs, opportunities and challenges, taking into account a wide variety of factors related to business, technology and people.

Solving Tough (Mostly Technical) Problems

As a PSE, you’re expected to be an outstanding problem solver and are often a frequent person that people turn to when they’re really stuck on something.

It’s pretty cliche to list “good problem solving skills” in a job description or resume, but PSEs need to operate on a whole other level when it comes to solving tough problems which tend to be some combination of: critical, complex, time-sensitive, sporadic and highly visible.

In addition to having acquired an understanding of the problem space, solving these types of problems requires a few key traits.

First on the list is confidence – knowing that you will figure it out, no matter what the problem is, which comes from having solved a ton of tough problems in the past.

Next is resourcefulness – some call it creativity or thinking outside the box. The ability to come at a problem from all different angles and to consider innovative and unconventional solutions. If there are things you can try in parallel, divide and delegate to speed things up.

And then simply being relentless – Just not being willing to give up until you’ve solved it. Taking a methodical approach, documenting each attempt as you go. Having the patience to keep trying one thing after another…..after another….until you succeed. At lower levels on the engineering ladder, there’s always someone more senior or experienced that you can call on when needed, whereas at the PSE level you’re that person. So it requires a mindset shift.

If one were to list out the biggest technical challenges that a software engineering organization is currently dealing with, a PSE can probably help with most of them. At B2B SaaS companies in particular, these problems might include performance / scaling issues, high availability, multi-tenancy, security, integration with 3rd party systems, customization / personalization, analytics, automated testing, CI/CD and more.

Work Style / Characteristics

PSEs usually enjoy a high degree of flexibility, independence and self-direction in their day-to-day work.

One thing that sets them apart from other engineers is that they tend to be comfortable working off of vague descriptions and requirements, with minimal oversight or direction. I think part of the reason for this is that they often interact directly with business and tech leaders who operate at a higher level of abstraction. Another reason is that they’re often trusted enough to be able to run with things and reach out when they need more clarification or have something to review/discuss.

Some examples of this “minimal direction” work that PSEs are given:

“Customers have been complaining that our app has been getting really slow lately….can you take a look?”

“We just signed a deal to integrate with that 3rd party solution that you and I had the Zoom call with a couple days ago. Can you reach out to them, sort out the details and plan the integration project?”

“I’ve been hearing lately about XYZ technology and wondering if it would be a good fit for us. Can you take a look and give me your recommendations?”

“A Fortune 500 prospect late in the sales cycle is concerned about scalability and just asked us to concretely prove that our platform can handle (some large number of) concurrent users and transactions. I don’t think we’ve done a test that big. Can you circle back with them and do whatever testing we need to address their concerns?”

Cross-Functional Communication and Collaboration

As an engineer progresses up the rungs of the software engineering career ladder, their interpersonal skills become more and more important.

Once they reach the PSE level, they will need to have outstanding communication skills (both written and verbal) to be able to navigate and succeed in their role.

Even though a PSE doesn’t directly manage people, they will still spend a fair amount of time communicating and will need the ability to:

• Clearly articulate their thoughts / ideas / solutions to others (both technical and non-technical audiences)
• Build relationships, gain respect and develop trust
• Negotiate and resolve conflicts
• Influence others
• Sell their ideas and solutions within the organization

PSEs will often find themselves interacting across a wide range of departments including:

• Engineering Teams
• Product Management
• UX
• Sales
• Client Services
• Customer Success / Support
• Leadership team

They are expected to be able to act as an effective bridge between business and technology.

Alright, so hopefully I’ve accomplished my goal of describing in detail what the Principal Software Engineer role looks like here at Steel Toad and what our clients can expect from us when they bring us on board.

The fact that we’re not just PSEs but also have first-hand experience as founders of our own startups makes us a valuable resource for B2B SaaS companies. We feel this is a truly unique combination that you won’t find at any other agency.