Transitioning into the Staff+ Engineer Role - from Player to Coach

In the article, I will describe my views and observations on how staff+ engineers transition to supporters, enablers and force multipliers of others and what technical leadership looks like away from the management track. I will explain the benefits for organisations to have leadership roles that are focussed on technical enablement and support.

Throughout this article “staff+” is referenced - what is meant by this is roles that are beyond the senior engineer role but on the technical track, rather than the management track. This can encompass staff, senior staff, principal and even distinguished or fellow engineers. How many of these levels depends on the size of the organisation. The normal step up from senior engineer is to staff, but smaller organisations may only have principal engineers. This article is centred around the transition into these roles, rather than the specifics of how each level differs.

Staff+ role is such a different role from a senior engineer; it's a transitory role into technical leadership and enablement of others. However, the traits and behaviours to be successful in this role are often not obvious to people, as we brand these roles as “individual contributor” roles. This categorisation leads to some confusion about how these roles differ from a senior engineer. 

What is a Staff+ Engineer Role?

There is no single shape for this role, and it will vary from company to company. Often, companies add this role for career progression and retention of engineers, but without recognizing that in the true sense this should be a role change, not an extension of being a senior engineer.

To help illustrate what I believe the role should look like, it is useful to set the context of why the role might be needed at a company. There has been a move to autonomous teams that have complete end-to-end ownership of a product or value stream. With this, there has been a move away from directional leadership and up-front architectural definition. Teams are now not only accountable for how to build their software, but also how to run and maintain it. Architecture and best practices are now the responsibility of teams. This has led to less coupling, however, they are only one team of many in an organisation that must function together to achieve company goals. Additionally, this comes with an increase in cognitive load as engineers are expected to master more than just the code they write. 

This is where the staff+ role comes into play. They enable the teams to do their job better by having a longer and wider view of the technical landscape that the teams are operating in, which they then feed back to the teams. This might be around rolling out or improving cross-cutting concerns, such as CI/CD or monitoring or business-focused initiatives that touch on many areas of the business. Additionally, staff+ engineers should be expected to nurture and grow the teams from a technical angle. Staff+ engineers are highly experienced engineers that have been exposed to a variety of scenarios which they can use to mentor and grow the engineers. 

Ashley Joost, principal engineer at Skyscanner, once described it to me as “We’re the coaches”. 

Wil Larson wrote about several archetypes of this role in his book: Staff Engineer: Leadership beyond the management track, claiming that there are four archetypes: 

• The Tech Lead guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities.
• The Architect is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organization level leadership.
• The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods. Others bounce from hotspot to hotspot as guided by organizational leadership.
• The Right Hand extends an executive's attention, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large-scale organizations.

These archetypes are not fixed and in fact, I have found myself floating between several of them in a single organisation as per what I was working on.

For example, I was working on the data platform at Skyscanner consolidating the approach for capturing user behavioural data from the website. This was much more the architect's role, but in rolling out that work I also got deeply concerned with data observability and data quality. We were relying more and more on custom data point emissions from unreliable sources such as apps. By talking to end-users and data emitters, I saw a massive gap in our visibility and feedback loop over the quality of the data that we were using to drive business decisions. This is where I found myself moving into more of a solver archetype. Data quality may on the surface sound binary - “it’s good” or “it’s not good” - the more you look at it, the more nuanced it gets as different consumers have different views on quality. I dug deep into the topic, and in collaboration with a product manager we brought a data quality strategy to the table. At this point, my archetype changed once again towards the tech lead as we started to staff the initiative. In this role, I was charged with getting others up to speed in the problem space and providing a guiding hand towards some steps forward in addressing the issues that had surfaced. 

Force Multiplying by Enabling Others

Staff+ engineers enable organisations to scale whilst maintaining and building a culture of quality execution. This is by moving from excelling at engineering ourselves, to also getting others to that level and teaching them to also pay it forward via a culture of enabling and supporting others. The growth of others is the cornerstone of the role and enables a higher degree of autonomy for teams which in turn allows for better product delivery.

Certain behaviours become critical for staff+ engineers to exhibit in order to become enablers. They should be heavily invested in driving constant improvement in quality, quantity and value of engineering output by support rather than direction via:

• Mentoring and coaching at both the individual level and the larger settings, such as squads/guilds/interest groups
• Collaborating with squads and product managers to define vision, strategy and the execution path
• Identifying opportunities for individuals and teams - taking the coach position rather than the star player in interesting work
• Identifying/unblocking & reducing dependencies - providing cross-team communication and high-level thinking
• Identifying possible improvements whether it be technical or process and influence the execution
• Instilling the benefits of self-reflection and constant improvement
• Fostering a safe environment and trusted relationships to encourage innovation
• Encouraging and promoting process change
• Providing the space and opportunity for growth
• Protecting engineers' precious time from distraction or stress
• Being trusted by squads to soundboard ideas, frustrations and worries
• Coaching the squads to understand the value of consistency, observability and quality
• Acting as champions for squads and individuals, especially where their voices may not be heard

Technical Leadership on the IC path

IC or individual contributor path is where the staff+ engineer role tends to reside - senior engineers can choose between the management path and the “IC” path. However, I think this terminology further muddies a more universally accepted definition for the staff+ roles. Actually, this whole path definition adds to the confusion.

The management path is about the people aspect, therefore it could be seen that the “IC” is individually contributing and not about people. However, this is so incredibly damaging for the understanding of these roles - it is ALL about the people. It's all about the people and leadership - how we help grow others through our depth of experience. Staff+ are there to provide leadership and guidance through influence. The influence goes up and down the ladder - influencing less technical yet more senior stakeholders towards the right strategy, but also influencing teams to think about the things that will enable more success for them and their product.

Pat Kua talks of the trident model of career development as in the three spikes of a trident referencing management, technical leadership and individual contributor rather than the typical two-track representation you commonly see (management and individual contributor). In my experience, this trident model is a much fairer and more accurate evaluation of the most successful staff+ engineers I have come across, with the staff+ engineers slotting into that technical leadership bracket.

Technical leadership is a distinctively different path from the IC path. The IC folk will typically spend 80-90% of their time on delivery - think technical domain experts who are exceedingly deep in a technical problem space. The technical leadership path though is where the staff+ engineers reside. They are looking forward to how to get teams and individuals to own the vision and strategy, coaching them to give them the skills to continuously improve the execution towards those common goals.

Supporting Others

Part of the role of enablement and leadership comes through the support you can provide. Support can come in the form of coaching, knowledge transfer and being the voice for those either not able to be heard or aren’t in the room. Additionally, support comes from proactively identifying areas that could improve the engineers' lives. 

I start by exploring the pain points for teams and individuals to drive the best way in which I can help them. Sometimes there is a technical solution - a very common gripe is something around deployment, for example, speed or automation. These problems are often cross-cutting and it takes a staff engineer to be able to push for these changes to be prioritised. Sometimes the problems are organisational or people-based. For these types of problems, the type of support from a staff+ engineer might be to purely provide a safe space or to use their influence and network to bring these problems out into the open. 

Staff+ engineers are highly experienced engineers - they have seen a lot of problems and have felt the pain of operating and maintaining systems. Where this is useful is to coach teams and individuals with their problems. Often when a problem space is still super murky or complex, staff+ engineers can provide feedback on approaches. The great staff+ engineers do this without directionally exerting their experience, but instead coach others towards a better solution or approach. It can be hard especially if you are unable to steer teams toward your solution. My rule of thumb is that if I can’t influence a team in the direction I think is best, then either my influence needs work or the team knows better than me. The important part is to ensure mitigations are in place, even if teams want to go in a different direction rather than use authority to influence them back to your way of thinking. Staff+ engineers should be using influence over authority.

How to Get That Staff+ Engineer Role 

This is very dependent on organisation but generally, there are two routes into this role: promotion and getting a new role. 

However, prior to going down either of these routes, you need to really question whether you want this role - it is a very different role to the senior engineer role, as I explained earlier. 

Promotion is definitely the easier route for getting a staff engineer role. However, it is still a substantial job change and could be likened to crossing the chasm for tech adoption. Even if your company has a well-defined career framework, normally the description for staff+ is intentionally vague, for example, “You lead or influence a team in a deep problem space or a number of teams across a broader area”. The reason it is vague is to allow for all the different archetypes described earlier to exist, and equally staff engineers should be proactively identifying what they work on. 

To get into this role via moving companies is a much harder proposition as most companies will expect experience in this role prior to giving this role to someone. However, if you are demonstrating the behaviours I listed above as a senior in a large company, that can be ported over to a smaller company as a staff+. Alternatively, going for lead roles in small companies could line you up nicely to get the staff+ when the company scales enough to warrant it. When going for this role at another company, make sure you are aligned with them on what the role involves and what the expectations are. A career framework is really helpful here. Don’t assume that everyone thinks the same as you about this role because there is a significant disparity in thinking about this role. Spend time speaking to the company about what the expectations are for you when you join.

Either getting promoted or getting this role at another company will involve having evidence that you are able to do this role. This invariably means getting evidence of already performing this role. There is a concept called the “staff engineer project,” which is a piece of work that seniors do that provides that needed evidence. Staff+ engineers are expected to work in murky problem areas - areas that are poorly understood, have a high level of complexity, perhaps distributed over a wide set of stakeholders or very early in its definition. Senior engineers have been known to seek out projects or fabricate problems to demonstrate evidence of working at the staff+ level. This might be due to not having access to problem spaces that fulfil the requirements for evidence for a staff+ role through their normal work for one reason or another. These “staff engineer projects” can be very effective in helping a promotion process but equally, they should be employed with caution. I have seen these projects passed on to teams to support after the promotion has to been given out, despite the team never agreeing to the building of this project. 

There are three core aspects that you can centre your evidence around:

1. Company values - how are you demonstrating living the company values?
2. Career framework - what are the company expectations of you in this next role? Strategically plan how to achieve this. If a company doesn’t have a career framework, then how are you able to measure how close you are to being ready for promotion, and equally, how can you measure your effectiveness once in that role?
3. Supporting witnesses - having people who are working in the role already providing evidence of working at a higher level is very powerful. Equally, if you have a sponsor they should be able to help you champion your cause.

Conclusion

The staff+ role is not an extension of being a senior engineer. Before going for the role, be crystal clear about why you want it. The role centres more around people than it does around code. Really question if this role is for you: whether you love being hands-on in a problem space or if you get excited about working with others to help them deliver. 

To be successful in this role, you have to become an enabler by providing technical support, guidance and a safe space for the teams. Additionally, you should be looking for ways in which you can improve the autonomy and focus of your teams by identifying blockers or improvements that can be made. The best way to do this is to identify the pain points your teams are feeling and see how you can prioritise the work to resolve or minimise them. 

As a staff+ engineer, you should be bringing the wider context to the teams to avoid them repeating work that could be done more efficiently as cross-organisation initiatives. This will allow the engineers to focus on delivering business value for their domain. 

At the core of this role is influence. You need to be able to influence engineers without diminishing their autonomy. You also need to influence those above and those who are outside of engineering to get change prioritised. Most importantly, your influence can provide others with opportunities that will help them grow in a safe environment. This makes the role a tough jump up from senior engineer and is a skill that, like coding, takes practice to master.