Finding the steps on the individual contributor ladder
What does it actually mean to be a ‘principal engineer’? Skyscanner’s Nicky Wrightson draws on her experiences, her missteps, and her research to profile one of the most in-demand roles in the world of individual contributors. Read on to find out if the IC route is for you…
Skyscanner is growing and our Engineers don’t just love working here — they love telling people about it. Over the next few months some of our most passionate engineers will be writing to showcase our London hotbed of software engineering talent, and how we’re impacting millions of travellers, all over the world. Nicky Wrightson has also written a follow-up to this blog on what it’s like to be a principal engineer at Skyscanner, which you can find right here.
Introduction
I rose through the ranks to become principal engineer at the Financial Times. Since leaving there I have had two principal engineer roles, with the second of those taking me to where I am at the moment: Skyscanner. During this journey of promotion and seeking a new role I have had to get what a principal engineer actually is really clear in my mind. I didn’t get it right initially, and found myself in a role at a company that was not yet ready for a principal, so having me was not good for them — or for me. I found a few useful resources which helped me to understand what it means to be a principal engineer, but it’s fair to say that there’s not much information out there. So I thought I would pull together my experiences, learnings and questions and write something to help people decide if the individual contributor (IC) route is for them.
What is an individual contributor?
Historically, as engineers/developers became more senior they hit a decision point — do I become a manager or an architect?
A manager would work with the team guiding project delivery and also provide line management — often to a large group of people.
An architect provided a directive technical role — we were still building in data centres and we needed someone to think of the whole end-to-end solution up-front — so we understood how much rack space to buy, for example. Architects designed solutions up-front and passed those solutions on to teams to implement.
Neither of the roles of manager or architect are hands-on, so for career progression you would have to sacrifice cutting code. Additionally, all those skills you have honed as a senior engineer don’t necessarily map at all to the skills you need in the fundamentally unrelated roles of architect or manager.
Never once has a single line manager ever even broached the idea of me moving from senior developer to architect; in fact, I have only ever met one female architect in my 20-year career. So to progress my career it seemed like my only choice was to ditch tech and head into management. However, I managed to resist being pushed towards the management track; although I enjoy managing people I have always wanted to keep my fingers in the code.
More recently, several new practices have come along which have made new career paths possible — namely agile/lean development and the elastic compute enabled by cloud native development.
Teams are now empowered to architect, build and own the solutions and products that they are building. The architectural responsibilities are being pushed down to the teams themselves, meaning that there is less need for an architect in a directive, over-arching role. Architectural solutions are reduced in scope and broken down into much, much smaller deliverables, which the teams themselves are best placed to solve. I am not saying there isn’t a place for architects but the old style highly directive style of architecture should, I think, no longer exist.
However, once you no longer have that larger and longer view of a system and product and the teams are working in the trenches you do see a gap that the architects once filled. After all, however autonomous a team is there are always integration points, larger company-wide initiatives, the need to take a longer view of technical strategy for a product, and/or awareness of options in the design process.
This gap is where principal engineers fit in. Depending on the scale of your organisation you may have many levels above senior engineer — for example, you may have staff engineers, followed by principal engineers and then engineering fellows.
Individual contributors are members of this slice of the engineering profession. They tend not to have reports. And their existence reflects the fact that there is career progression for engineers that is not management-focussed.
I am a principal so I am going to concentrate on talking about my views and experience of this role versus anything higher up.
What does it specifically mean (to me) to be a principal engineer?
I do not want to generalise about this role so I am going to tell you what being a principal engineer means to me. You can pick and choose any or all aspects that you agree with as I think this is strongly influenced by your own experience.
For me it is a move away from direct delivery and towards becoming an enabler. The word I think best resonates is the word “influence” — you work to influence your teams/squads, the wider programme, your department/tribe, your wider company, and beyond that — the wider tech community. Principal engineers have a significant amount of experience technically, and from a deliverable point of view, which is highly valuable. They also tend to be constantly building on that experience — either through self-motivated learning and experimentation or from working with teams to solve problems.
The manner in which you exert your influence varies in every situation. These are some examples though:
- Influencing teams/squads — when designing a feature a principal might influence the decisions by providing wider company context, ideas from their experience or by coaching the squad by throwing lots of questions at them. I often find myself playing devil’s advocate to encourage squads to think in different dimensions. Our influence at this level shouldn’t be influencing solely for outcomes but also for growth, hence coaching is an important aspect. Sometimes that involves doing the early leg work to understand the technical considerations for initiatives that are coming up so that you can bring that information back to the squad
- Influencing the wider programme/department/tribe — this influence normally comes from a deep level of expertise — whether that depth is technical, people-, process- or domain-related doesn’t matter. You are influencing change for a wider group. This might involve driving forward a more consistent approach across squads or introducing new approaches to the problems tribes are facing
- Influencing the global tech community — there are lots of ways to do this but most of them tend to involve a level of advocacy for your company’s practices. However, in some cases it can involve working with other companies to solve a common issue such as a bug in some open source code. Where our work is particularly impactful I think it is important to share it with the wider community via speaking at conferences. However, if that’s not your bag then there are other ways to contribute back to the community — e.g. taking part in hackathons, making open source contributions, or blogging. I strongly feel that as principals we should be working to improve the technical standards beyond our company walls.
It doesn’t matter whether a principal is operating at the tribe/department level or embedded within a team, I believe there is scope for influencing.
What it is definitely not
“Principal. Not senior senior”
Principal engineers are not just a bit more experienced than senior engineers. It is a fundamentally different role from senior engineer and although the skillsets overlap there are many aspects that differ significantly. It means stepping from a delivery role to more of an enabling role — the goal is still to boost engineering output — but more indirectly, through supportive mechanisms.
Not a ‘10x engineer’
A controversial term (which I do not believe in) - whatever your definition of this term, principals are not it.
We don’t tend to disappear off and return having built silver bullet applications to solve really hard issues. Some principals are highly technical and have a really deep domain knowledge, these principals will often try to prototype approaches to help clear the way for teams. However this shouldn’t be done in an isolated manner otherwise you will find that you are just doing work that you think is useful. Also we drive forward all the best practices that I believe the idea of a “10x developer” contradicts — such as clear maintainable code, appropriate levels of automated testing and more.
A new label for an architect
The most asked question I get on this topic is, ‘what’s the difference between a principal engineer and an architect?’
When we had data centres and rack space, computation resources were expensive and had an obvious physical aspect to them — someone bought capacity, drove to the data centre and installed it. We had people that could design systems up-front and then from that we could estimate throughput and then work out how much we needed to buy. This was the role of the architect. The role of the architect was much more directive in getting teams to implement their vision. As there is a lot of up-front work done by the architects in terms of design and cost estimations it means that those designs become inflexible and hard to change once they land on the team’s roadmap. As architects tend to generally not be hands-on these designs often did not have the operability and maintainability of the systems as first class considerations. Although architects define the implementation, they hand over the ownership and accountability to teams.
Principals provide more of a supportive rather than a directive role. Principals are more concerned with deliverables and system operability. This comes from still being hands-on and jumping on issues together with teams to be able to solve the issues. Often the principal engineers will also be on the on-call rota taking ownership and accountability of the system alongside their squads. This directly changes their focus, as principals prefer pragmatism over perfectionism. They know the pain of supporting systems. The other thing is that we are now operating in the cloud so pivoting is relatively low-cost in comparison to the days of the data centres, meaning that principal engineers tend to look at delivering lean solutions without covering all use cases (to enable failing fast).
A purely technical role
As you mature through your career you will seek increasing challenges but aspects that make these problems harder tend to be people-orientated and not technical. Technical problems are the easy ones to solve. The role of a principal is often to align people to be able to deliver a solution to these technical problems. Andy Walker discusses the human aspect of tech at QCon London: It’s People, Stupid (People Are Stupid?). However, don’t get me wrong: principal engineers will always have a great depth of expertise, sometimes to such an extent that they will be leading their field. That doesn’t mean that the problems they solve are purely technical though.
Finding a job that supports an IC track
I really messed up finding that next principal role after I worked at the Financial Times. The reason is that I expected my understanding of what I did at the FT to be a well understood role that was the same across companies. However this is a relatively new role, especially in the UK, and when I joined a new company I realised too late that our views on the role were completely misaligned. Partly that was because I hadn’t worked out how to articulate what I wanted from a principal engineer role to recruiters.
Companies often sell the fact that they have flat hierarchies, but I think this only tends to be true for small, young startups where everyone is already talking to everyone. I think as companies get larger those hierarchies become more apparent and it is best to formally recognise them rather than leaving them as implicit hierarchies. These implicit hierarchies favour highly confident people that are able to grow themselves and actively seek out new opportunities. Unfortunately this ends up leaving less confident people behind and can make for a less inclusive working environment.
So, pretty much all companies have career hierarchies — implicit or explicit. The implicit kind will stimulate some personality types — however I knew I would benefit from joining a company with more structure, for the following reasons:
- I am a woman — people will assume I am non-technical until I prove them otherwise. Even with the title “Principal Engineer” I often get asked things like, “but can you code?”, “I have a really technical question so I am not sure you can help”, “are you still technical?”. In a company with a supposedly ‘flat hierarchy’, I would have a title like ‘engineer’ which would flatten out my achievements and that would exacerbate this issue — people would be likely to assume I was a mature graduate just starting out
- A company that can give a well thought-out career definition has invested a significant amount of time thinking about how they want to retain and grow their technical talent. This demonstrates the value they place on the quality and well-being of their technical staff.
To find a new role, you normally have to go through a recruiter. This can be painful if the recruiter is playing a numbers game and throwing candidates at companies. If they are doing this they will tell you what you want to hear. Here is a typical conversation with this kind of recruiter:
Me: “The job spec is for a senior engineer, can I see the principal engineer’s job spec?”
Recruiter: “Company x has really grown and they see the need for a principal engineer but they feel that the principal should drive the definition of the role”
Me: “Ok, can I see the career map/matrix/ladder then that they have in place for higher level ICs?”
Recruiter: “They don’t want to share this externally”
With neither a job spec nor a career definition I would be really suspicious — how could they ask someone quite senior to apply for a job that they can’t define? If they are unable to define this role, then how do they know they need this role? Additionally it told me that the recruiter didn’t necessarily understand the role of a principal engineer — I took this as an opportunity to educate: I sent a lot of recruiters the blog post, “On being a principal engineer”. If, having read the post, they confirmed that the role was a fit I would then explore it further.
The other aspect of finding a new role is really understanding what you want and what you are good at. I found this article by Anna Shipman really useful: “Finding the next level tech job”. She was looking for a director role but I think the advice is the same for any step up. I started tailoring my questions towards the aspects I found important. For example I really excel in an autonomous, trusted and fun culture, and so I utilised questions like “tell me something you have seen or heard recently that exemplifies your culture?” You can use the right questions to determine whether the company you’re looking at can provide you with with atmosphere and culture you need to excel.
Challenges at the principal level
As you step up from senior engineer to principal, you become increasingly autonomous. After all, you are excelling in your field. Principal engineers fulfill different functions depending on company but at this level ultimately principals should be defining the shape of their role in order to squeeze the maximum value from their bespoke skillset.
For example I am tribe-wide over several squads. Those squads own their own development decisions and roadmaps. Therefore I am not in everyone’s stand-ups and planning sessions. It’s unreasonable to think of me pulling tickets all the time — I will pull tickets occasionally as long as I don’t end up on the critical path. The demands on my time tend to be spiky and not predictable — for example, my calendar can go manic at any moment with a new initiative or production issue.
My personal challenges are the following:
- Staying technically up-to-date: I have yet to solve this but I try to get my hands dirty regularly by pulling tickets that are not on the critical path or doing small proofs of concept. Also I read — I read A LOT. I have a never-ending reading path that is populated via social media, and by keeping an eye on company-wide engineering channels, and by speaking to friends
- Not inserting yourself in the critical path: to ensure that this doesn’t happen I have to communicate effectively with my teams. However helpful you think you are being when you pull that ticket you can often end up slowing down a squad when impromptu meetings are thrown your way
- Accepting when squads choose a path you don’t agree with: you know that the solution you have is better or that the solution the team has chosen won’t work. However, if you are unable to convince the team then you have to quickly move on and work on how to support the route they have chosen and provide guidance on how to ensure any failure that might happen is short-lived
- Defining the expectations of this role: if you are joining a company with this role really deeply defined for every principal engineer then I don’t believe your company really has a principal level role. This role is difficult to write a detailed definition for and where companies understand this then there is probably less explicit detail and more focus on the expected behaviours. However, being new to a company or new into the role it is daunting to define this yourself. I urge you to find mentors in the roles that are equal or greater to yours so you can test your ideas with them
- Measuring your value: when you have no stand-up, and no weekly sprint goal to achieve, how do you measure your value? I am still working on answering this — I find that committing to doing tasks to other members of your tribe and delivering helps. Taking ownership of the direction of initiatives can also give value as you see squads achieve success.
In conclusion
If you want to head along the IC path make sure you understand what it means to you. If you aren’t able to follow this route at your current company then invest time talking with recruiters. A good recruiter will take the time to understand what you need from this role. Be sure they understand your definition of the role. Keep an eye out for those key signals that a company is investing in their IC path — do they have a job spec? Don’t be in a rush — this is a step up and most companies are not at the point where they are looking for senior ICs — so don’t rush to join the first business that is willing to hand you the title — they may not have the same understanding of the role as you do!
Nicky has now written a follow-up to this blog which you can read right away: it’s called ‘Being a principal engineer at Skyscanner’ and you can get it right here.
Further reading
- Being a principal engineer at Skyscanner by Nicky Wrightson
- On being a principal engineer by Silvia Botros
- Finding the next level tech job by Anna Shipman
- Managers path by Camille Fournier
- It’s People, Stupid (People Are Stupid?) by Andy Walker
Our engineers move people
At Skyscanner our global presence offers scale, while still feeling small enough for everyone to have impact. Impact that ripples out to millions of travellers across the planet each day.
Just as our customers trust our service, so we trust our Engineers. If you build it, you run it. And right now, we’re creating the next generation of apps, products, systems and services that will define the future of travel.
Together and cross-functionally, our Engineering teams strive to deliver an unmatched traveller experience. Want to discover more? Check out our jobs site.
About the author: Nicky Wrightson
Nicky has extensive experience delivering large scale cloud native architectures. She passionately promotes operability as a first class concern in developing these large distributed systems. She currently works on the data platform at Skyscanner, where the huge scale means she has a whole different set of problems to solve while still striving to keep things operable, cost-effective and maintainable.
