Adjusting to Staff! The 5th Archetype: Detective

Last year I found myself in the fortunate position of being offered the position of staff engineer, and not just any staff engineer, but the first mobile native staff engineer in my organization.

I had first joined the company as a first-time senior engineer, so once again I found myself learning the role on my feet. I’d worked with senior engineers before though, observed what they did, had an idea of what they do. I’ve never worked with a staff though…

This presented a problem….. How can I be a staff engineer if I don’t know what one is?!

Becoming a staff engineer: what I expected vs what I found

Interestingly, there isn’t much literature on being a staff engineer, but fortunately what is available is gold. The two books:

The Staff Engineer’s Path by Tanya Reilly and Staff Engineer: Leadership beyond the management track by Will Larson, both go into lots of depth and cover a wide array of topics but for now I want to focus on the types of staff engineer.

Will Lawson, defines a staff engineer as 4 types:

• Tech Lead: Guides a team through technical decisions, ensuring architectural coherence and quality code while mentoring team members.
• Architect: Owns direction, quality and approach within a critical area. They combine deep technical knowledge of the constraints, user needs and leadership.
• Solver: A Solver tackles the most complex technical problems, debugging and optimizing code, and finding innovative solutions to critical issues.
• Right Hand: Extend an executive’s attention, borrowing their scope and authority to manage areas of the organization.

These gave at least a baseline to work towards. My working assumption at the time was that I needed to move from senior to one of these staff archetypes, much like a skill tree from an RPG game. Given the staff role was new, I assumed my company had one of the archetypes in mind in order to fix a specific problem.

Originally, I identified as a combination of the “Solver” and the “Tech Lead” in that there is a heavy focus on “fixing the hard stuff” that nobody else either wants to, or has the background knowledge to resolve. However, I wasn’t entirely sure this was the archetype the company wanted at the time. This left me a bit conflicted, do I commit to the archetype defined by the company or try to push more for one which I already align to.

Luckily, it turned out I did not have to make this decision. By speaking with leadership and the other staff engineers, it became apparent, sticking to one archetype is not pragmatic or useful to anyone right now.

“I found that depending on the requirements the role may change between archetypes based on the business needs. More often than not, it was a combination of the top 3.”

This is in contrast to being a senior. Senior engineers may often find themselves working in feature teams. Working in a feature team, the product team sets the direction for the majority of the work, and engineers make it happen. Often at times (but not always!), scaling or tech debt resolution needs to be squeezed in between roadmap work.

When moving to staff, suddenly the expectation changes, and in a big way!

Your job is no longer to build features and improve the app as an IC. The scope now expands beyond your team to the entire company, within your technology domain.

This may sound like a blank cheque to fix tech debt, but that is not the case. It is important to be mindful, that the role is to not fix the problems you want to solve, or the problems the team has wanted to solve but never had time.

When moving from senior to staff, there is an expectation of knowing what needs to be done in your domain to empower the business to deliver on their requirements for the next months or years ahead.

Using your knowledge and feedback from the teams, the next step is problem identification. The problems you find, should align with the upcoming business goals. If the business wants to optimize payments and you know the product has a lot of technical debt around payments, it’s a good idea to try and focus on scaling and improvements around this area of the code.

However, if it is not clear, maybe you are new to the organization and know the upcoming business goals, but do not know the technical challenges, now is a great time to start deep diving the problems the team is facing.

Diving in: putting your detective skills to use

At this point, the problems should start becoming clearer and which staff archetype is best to address it. E.g.

• Does the team have very complex tech debt to resolve? Possibly the solver would be best,
• Maybe the team is technically strong but struggle to maintain alignment, in which case maybe architect or team lead would be more suitable.

Early on, I would promote for a 5th archetype. The Detective.
Just as high rise building Architects needs to have a clear understanding of the foundations, so do technology focused architects!

As a detective, my first steps were speaking to the eye witnesses (the team) and asking:

• What their problems are
• Which parts of the code have the most technical debt
• Which areas have low unit tests or high failure rates
• Are any areas slow or painful to work with
• Are there any teams you struggle to work with efficiently

Secondly, drawing on my existing knowledge:

• What problems do I know of
• What areas of the code are often problematic
• What slows us down
• What keeps me up at night!

Finally, The business!

• Speak to the business/stakeholders and ask what challenges they are facing.
• What keeps them up at night too!

Already by combining this information along with the upcoming business challenges, you should be able to start making connections on how to optimize your project.

So in a nutshell

Coming in from a senior to a staff role, the first thing to understand, is to align with the people or person who defined the role and understand what they expect from it. If the role is new, what problem was the role created to resolve? Then understand the skills and expectations required in order to resolve those problems.

If everything perfectly aligns with an existing archetype, then you have a good starting point. If the lines are more blurred, you may need to start some detective work. As time goes on and you spend less time worrying about problems facing a specific feature squad and instead all squads or groups, common problems and challenges will surface. When you can align these identified problems with what the business expects from the role, you will have your answer for which archetype you most likely will need to succeed in your first few months as a staff.