Some Thoughts on the Principal Role

If you’re a senior software engineer or data scientist, you might wonder what the next career step is. Some companies offer an “individual contributor” track, which is called principal, or staff, and that may seem like an attractive alternative to becoming a manager.

I have worked in this role both at Zalando and now GetYourGuide, and I learned a bit from people who previously worked at Amazon. They also have a website on their principal community. So let me try and write down some thoughts on the role.

Different Versions of the Principal Role

So what does this role do? Based on my experience I’d say there is not a single approach to the role. Different companies, or even different organizations within a company can have different expectations of what the role should be.

One version of the role is what I’d call a “super”-senior. They still write mostly code, just for bigger and more complex tasks.

I personally think this approach restricts the amount of impact you have on the overall organization because doing work yourself does not “scale out.” At the end of the day, it is still you writing code.

I see staff or principal level technical roles are a form of leadership. You ultimately have to help people get better at what they do. Instead of working alone, your focus should be on helping teams, for example by joining them on projects, by being involved with architecture or other kinds of design, best practices, testing, or whatever is necessary. The goal in this should be not to fix whatever is missing yourself, but to help people to learn to do it themselves. The whole team will be better even after you are no longer with them, and they will do more work than you could do alone.

Often, teams don’t need help because they lack expertise or experience, but because the problem they are facing may be bigger than the scope they know. For example, when designing a piece of infrastructure that affects many teams, you need to have a good overview of the technical landscape. But teams naturally are most familiar with their team’s scope. A principal can bring this oversight and help the teams to master the challenge.

From what I have heard some big companies go one step further by systematically involving principals in high impact projects to make sure they are fully vetted before going out. Anecdotally, if something goes wrong, the first question is whether a principal had been involved to make sure everything works out. This kind of setup may sound like the principal is policing the teams, but in reality having a principal sign off on your work also gives confidence that it will work as expected.

So there are different ways you can do the job, coding yourself, helping teams out, coaching them, up to formally reviewing the work of the teams. Even in big companies (who I assume have more experience to figure out how to successfully do this role) it also depends on individual interests and backgrounds. Some people go deep into one technology or application area, while others go wide and are familiar with a wide set of systems.

What is Required to Succeed?

To be fully honest I wouldn’t say that I made the role perfectly work in all the different versions I’ve had, but I think I have some insights into challenges involved in making it work.

One challenge is how to influence people. Because you’re nobody’s boss, you cannot just tell people how to do it. (Although I wonder that works well even if you’re the boss.) Instead, they need to trust you, both in terms of technical expertise and that your interest is that the team succeeds. This trust takes time to earn.

Gaining this kind of influence also becomes even more difficult if you are not backed up by leadership. This support can come in many ways. It can be institutionalized as in formal reviews of bigger projects, or it can be that principals are part of leadership to make decisions. Without lack of such support, people might be conflicted about who to listen to. I still think you can earn people’s trust and work that way, but it is way harder.

I think what also doesn’t work particularly well is the idea that a principal will just magically come up with ideas what to do. Like everyone else, principals need goals and clear expectations so that they can look for ways to help achieve those goals. Then, principals can be expected to figure out how to achieve these goals by themselves.

The notion of autonomy can also be misunderstood. It does not mean that you talk to nobody and come up with solutions by yourself and then push those through. Ideally, you will be talking with lots of people and get as much interaction and help to solve problems as possible. There are three main reasons for why you shouldn’t solve problems alone: By involving others you get their perspective and a fuller picture of what you need to consider. You give others the chance to work with you and (hopefully) learn. And finally, involving people in creating a solution goes a long way towards getting their buy-in.

As a last challenge, I personally also don’t think that the idea of a super-senior works well. The work, however brilliant, is still the work of single individual and it does not scale. It also seems odd to work towards knowledge sharing and reducing the bus factor everywhere else in your organization but in the work of a principal.

What It Means For You

First of all, don’t think of the principal role as just the same job with more money and bigger projects/products/tasks. Just like a step into management fundamentally changes your day to day work, moving from senior to principal should also change the way you work.

Principal roles are a form of technical leadership, and this means that your job will be to help people become better. Even if you’re not managing people, your work will be with people to a much higher degree than before. The bias should be less about doing it yourself but how to help people to grow to be able to do it.

If you want to do this role and it is still somewhat new at the company, expect that there may not be enough clarity on what is exactly expected from this role, and that your responsibilities are not clearly defined. In such cases there should at least be some awareness of this and willingness to define it together with you from your manager.

Or Become a Manager?

Another option is of course to become a manager. There are again many different ways how this role is set up, and different management philosophies, but I think the best analogy is that you become a sport coach. You become responsible for the success of the team without being part of the team on the field anymore. You’ll still work on projects and products, but you won’t be doing it yourself anymore.

You’ll also become responsible for people’s career paths, and help them grow. As a principal, you are also helping people to become better, but usually within the context of certain technology or project. To stick with the analogy above, as a principal, you’re more of a speciality coach and helping across several teams to get better at what your area of speciality is, but not to figure out how they can progress in their overall career.

Summary

I think only the biggest companies have already figured out how to do this role best, and even there, expect to see huge differences. But if you are ready to become more than a super-senior and get started on technical leadership, I think this is a very interesting role to grow into. In my case, I’m still figuring it out myself, but when it works, I really like the combination of technical challenge and helping people.

In any case, I hope this was at least not uninteresting, maybe helpful. Let me know what you think!