The Staff Engineer's Path

A Brown Bag session giving an overview of The Staff Engineer's Path, the book by Tanya Reilly.

This is a “Brown Bag” session that I delivered at [Compare the Market] with the intent of promoting an understanding of the role of Staff Engineer within the company, aimed at the broad audience of “anyone in the tech department.”

Abstract

Let’s talk about the book “The Staff Engineer’s Path” and through that, understand more about what the role and responsibilities are of a Staff Engineer.

Slides & Script

First things first.

This is essentially a book review.

Staff Engineer is a relatively new role within CTM. It’s a reflection of the evolution of our Industry, and the fact that we’ve adopted the role and terminology from the industry reflects on how we adapt to the industry.

Everything in the Industry is shaped by the people and organisations that work in it, and as an organisation we can also shape that Industry.

Reading the Books and thoughts that come out of others is a great way to understand what everyone else thinks the role is, and then we can take what we like from that.

The book is written with Staff Engineers in mind, but this presentation is for everyone.

This Presentation covers this book, so that you don’t have to. If it sounds good, I recommend you spend a bit of your tech budget on the book itself.

This is not the only book out there, there’s at least two others – but this is my fave so far.

With the help of Midjourney illustrations, I’m going to give an overview of the content within the book, and hopefully not subject you to death by powerpoint.

This book is aimed at Staff Engineers and above. The name kinda makes this obvious, but it’s the whole concept of being a Senior Individual Contributor – someone who isn’t a manager, but is a technical leader.

If you’re not a Staff Engineer or above, it’s still relevant and beneficial to read this kind of stuff to understand other roles you might interact with or want to progress towards.

Into the book content then.

It’s a book of three parts. Loosely, understanding your role, mental models to help with that, managing yourself and influencing others, problem solving at the level expected of a Senior IC, and how to behave.

To avoid any overhead, this is roughly the structure I’m going to use for this presentation. I’m going to dive into each chapter and extract some useful content from each, and then we’ll wrap things up.

Everyone has opinions on what it means to be a Staff Engineer, even within CTM and especially in the wider industry.

The great hook with this book is that the first chapter covered practically all the best bits of advice I’ve gotten in 1-2-1s over the last few years.

This is stuff like acting in different roles as the needs of a project dictate. Establishing Visions and seeing them through to completion, managing time and prioritising effectively, and callouts to side tracks and alternative roles which aren’t quite SE roles, like SRE roles, and how you may want to dip into them instead.

It also calls out the importance of trust, reliability, good communication, and being a role model for others – hammering home the importance of being a senior IC and technical leader, and building the social capital you need with others in your organisation to Lead without Managing others.

One of the standout items is the idea of Personas.

This actually calls out also to another book, the StaffEng book, which describes four key personas for a Staff Engineer:

• Tech lead
• Architect
• Solver
• Right Hand

There’s not universal agreement on the fact that these are real things, or whether they’re Staff or Principle or something else, and everyone and everywhere is a little different, but these are some of the roles.

And we adopt these roles and guises as the projects dictate, whether that’s indicative of the maturity of a project, the type of project, or organisation or whatever.

Each is distinct, has different requirements on your energy levels, tech skills planning skills or people and org management skills.

The really interesting thing for me is how these archtypes map from our old org structure to our new one.

Tech Lead is something we used to have that became the Engineering Manager role.

Architect is something we used to have that became the Staff Engineer role.

SE and senior IC roles in general involve self-direction and prioritisation and discovery, and the fluidity of the SE role and what it can mean and how it appears is a challenge we’re still grappling with, for figuring out what skills you need to work on and what skills we want, and who is doing well at the job and who is not.

If that sounds daunting… buckle up, that’s what it’s all about.

Putting pep talks to one side, and moving onto the next chapter.

This one leans into mental maps you can apply to your thinking to understand how your organsiation works.
Because it’s not about the tech, but about navigating growth and change. And navigating requires Maps.
Maps are your fallbacks, your defaults to work out where you are, and where you’re going.

The big three are

Location, Topography, and Treasure Maps.

Each has a different spin, but they all talk about recognising, understanding and planning routes through politics, power structures and structural challenges. There’s a few aspects to this – its your own mental mapping, how you present and communicate to others, the pitfalls of simplifying things into maps.

I’m not going to dive into the details and attempt to replicate the content here, but a key thing is that maps are different depending on what they’re trying to represent.

Location maps show you where things are, Topography overlays the organistional blockers, and treasure maps are routes and clues and destinations.

For a treasure map, you don’t always know where you’re going, but you know the waypoints along the way, and you know what you’re looking for.

For topography maps, they’re about mapping out the hillls and mountains and chasms and fortresses that exist. Two teams in different departments that don’t talk , they have a chasm between them. A team with high standards might live in a fortress. A fortress might be an extension of a fiefdom, might have vassal states.

It’s a bit of fun, but the exercise helps step past the immediate “argh” of figuring out organsiations and gives you some structures to tap into and use to understand how to perform as an IC.

Onto the final chapter of the first section, Creating the Big Picture.

Technical Vision, Technical Strategy. You’ll need both of these at different times, one is where you’re going and the other is how you get there.

It contains lots of advice on how to identify what’s needed, prove that it’s needed, and identify if it’s something that you actually want/need/should take on.

Some of these are a documentation effort, a group effort, and needs sponsorship, and all of those things require their own unique skillsets. This covers the lifecycle of both of these efforts, how to not fail at them, and keep them successful.

Without wanting to fall into a pattern of creating one slide per chapter, there were a few things that stood out to me here.

Having a Technical Vision sets the direction for your teams. Without a direction, everyone pulls in different directions, and with alignment, you all travel in similar directions. There’s a few tricks and standard patterns you can use to help with this, and links to those I’ll include at the end of this presentation.

A particular gem for me is that Good Strategy is boring, or obvious, once you’ve said it. Strategy is heard as “Innovation” and “Interesting” things, but interesting strategy is probably wrong.

To support this, there’s some ideas like the Overton Window and Nemawashi, which are ways of laying the groundwork and changing hearts and minds to make the change you want to make seem more palettable.

The Overton Window is normally a more political term, talking about changing public opinion, making it lean more towards the direction you want in small, incremental steps.

And “Nemawashi” or ”laying the groundwork”. Which is about gathering support and feedback from people affected before announcing it, avoiding conflict.

…

There’s a lot more to the chapter of course, and lots of other lessons you can take away… but I’m going to move on.

The first three chapters were all about setting the Big Picture, the next three are about Execution.

This is a handbook for Staff Engineers, so now we go to practical stuff.

There’s a whole bunch of strategies you can use to help manage your time. Some techniques are blocking out time in your diary, ensuring you have time for deep work solving problems instead of shallow work flitting between meetings and doing the easy, non taxing stuff.

But its more than just ensuring you manage time to meet deadlines, or turn up on time, it’s also about ensuring that the work you pick up is worth your time and effort, personally and professionally.

What really stood out for me was the way is laid out aspects of work such as Energy, Credibility, Quality of Life, Skills and Social Capital. And it presents these as ways of evaluating and judging the value of work you can do.

Without energy everything is harder, takes longer.
Without credibility you can’t influence the people you need, or when you do it costs you more effort.
Without quality of life, things suck and you burn out.
Without skills, you can’t be effective or talk with knowledge and experience. Without social capital, you have little trust or influence, and things cost more.

That’s simplified and muddy and there’s lots of overlap, but it’s all about framing the way you think.

Social capital in particular is a thing that you build, bank and spend to get things done.

But you can’t just work on the stuff that makes you feel good and builds your energy, and you can’t just hone your skills all the time, and you can’t build kudos with people all the time, you have to balance and be clever with things.

Your time and your focus is Finite, and the work is infinite.

I said I’d not do a slide per chapter and I kinda meant it.

Staff Engineers can take on seemingly intractable problems and make them tractable.

That is to say, Staff engineers are here to move things along. Projects you get involved with could have a huge variety of reasons why they are not working well. It’s our job to identify what a project needs most and figure out what needs to be put in place to get it moving.

You could say it’s breaking things down into manageable chunks, or drawing an outline for a project.

The book itself rapidly covers a broad range of these and starts to present almost cheatsheets for working through these issues. Some of this is the importance of Documentation and RFCs and tapping into processes. Personally, there’s probably a whole load of links and materials that we as CTM should just lift and integrate into our own suite of templates to see if we can solve some of our issues with paint-by- numbers solutions.

Standout items for me are its commentary on motivation and aspirations, and how big projects require structures and checkpoints and diligence rather than heroism and figuring things out as you go.

Importantly, it calls out that Projects need people acting in certain roles, but that our role is not to do those roles, but to ensure that they’re covered in some way. Delegation for the win.

Onto the Next chapter, building on the previous.

Recognising when a project is stalled, as early as possible and getting it moving again.

There are a lot of really useful examples and guides in here, the solutions presented for this vary depending on what the blocker is and what the project is. Is it a small project, blocked by other teams? Is it blocked by processes or buy-in from others? Or is it something for which we don’t have enough skills? Enough tech?

A lot of the previous chapters have built up to these points. The Mental Maps from the second chapter are useful groundwork to understand better why things stall, they give you a perspective on things. You apply that here when things go wrong to see the pathway to resolution.

You align things with your technical vision and strategy because you have one now (right)

And you document and break it down into small chunks because you have those tractable chunks of work already understoof.

Understand and explain, Make the work easier, Get organisational support, Make alternative plans. This framework for decisions seems like it could be applied to many different situations, is maybe something we should promote more as a mental model for problem solving.

Problems can be team level, decision level, people level or scheduling issues, or plate tectonics and ownership issues.

Into the final three chapters, which are all about Levelling Up.

The first of these is, You’re a Role Model Now (Sorry)

Like it or not, your behaviour defines how others act, and others will look at what you do for an indication of what they need to do in order to get that promotion.

The metric for success is whether other people want to work with you.

Be competant, be self-aware, have high standards, be nice, take ownership, be responsible.

If something needs to be done or said, then do it or say it now, take the lead, take charge, but don’t take over.

Remember there’s a business and a team as well.

Make problems smaller, write things down, be consistent, be trustworthy, plan ahead.

And remember you have finite time.

Simples?!

Up to this point, the book is about you – how you work, how you make yourself effective.

But the secret to being anything like a 10x engineer is uplifting others – what you’d call being a mentor, perhaps.

If you uplift others, they’re more competent. Competent people are easier to work with, produce better software, better business outcomes.

This is full of practical examples, and a cheat sheet about the kind of Influence you can have on Individuals, Groups and as a Catalyst, and whether it’s by offering Advice, directly Teaching, providing Guardrails and Guidelines, or creating opportunities for others.

As with everything, mental models help clarify what you could do, and reduce the amount of thinking you need to do to perform the job. For each of these four bullet points there’s activities that you can do at the individual, group and catalyst level to help your teams.

This kind of stuff is great, because it’s like a paint by numbers aspect again of the support side of the role.

Our official intro description for the Staff Engineer role was all about being Guardians of Quality and Force Multipliers for the org, and what I really focussed in on unconsciously was the Guardrails aspect. But the role, the things you can and should be doing is so much broader than that.

Plan to give away your job

This one is all about your career, and where you go next.

The IC track is presented as linear, but our careers need not be like that. To quote from the book directly:

You are responsible for your career and choices. There are a lot of options about what to optimize for. Know what’s important to you.
Be deliberate.

This whole chapter is pep talky, but the outcome I got from it is to keep an eye on your own career and goals, and it’s perfectly okay to want to switch and go anywhere from here. Down the ladder, up the ladder, into management or leaning more into the different aspects of the role.

Everything is acceptable, and there’s plenty of examples from others in the industry doing the same.

Everything is learnable if it’s worth the time investment.

And to help you evaluate a job, there’s 5 key metrics it suggests keeping an eye on.

You can apply these to anything I guess. We’re probably spoilt in tech by the idea that our jobs (at least until AI takes over) are in demand and you have the mobility, but it easy not to think about moving, so this is about valuing yourself, your goals, your happiness. Watch these metrics and decide if you need to do something about them in your career.

That was a very fast, non stop whistle-stop tour of the book. Obvs reading the words themselves is different, than me telling you, but it’s a taster.

So let’s wrap it up on a single slide, and we can all take a breather, and maybe Q&A?

• Staff Engineers are “Senior Individual Contributor” roles, aka we don’t manage others.
• They should know or set the Vision and Strategy
• You have to identify where and how to be useful
• You have to manage your time effectively and prioritise appropriately
• You need to break down problems and keep things going
• Be a good role model, always.
• Be self-sufficient and lead sustainable teams
• And to do anything you need to build your influence, and spend it wisely.