I’ve always found the job description of a staff engineer to be a particularly compelling one, it requires a lot of technical, product and organisational knowledge, but it also needs a set of hard and soft skills to actually utilise this knowledge, without all of these combined the effect that can be achieved in an organisation is only but a fraction of what is possible. Quite a challenging set of requirements, from my point of view, so I wanted to get started on what that means in reality which brought me to Will Larson’s Staff Engineer.

Main out-takes

The author jumps directly into defining the different types of staff engineers and how they operate, this was a good sign for me as it led me to think Larson knows who the audience of this book are, it’s people who already have experience in the field and are looking for what’s next. First part of the book goes over a specific set of best practices for having the highest amount of meaningful impact within the organisation, from aligning teams, defining problems and ways to get to solutions, how to behave and position yourself within an organisation.

Something that I identify as a big thinking point for Larson was the psychological impact of working with other people, throughout the book there are strategically placed titbits that delve into human psychology and how we cooperate; I find those to be particularly valuable and insightful, after all, software development is there to solve problems for other humans, so understanding both is an advantage.

Another big point I found is adaptability, no single person will always have all the answers nor understand the nuances of the problem, sometimes we won’t agree in what is the best path forward and that’s totally fine. Larson states that leaders are not always at the helm, it is equally important to recognise when sponsoring others is the better choice for the organisation and to do so wholeheartedly. This is true for both your peers of equal or similar seniority, but also for the more junior team members, since these are the people who will one day inherit you, you want to teach them how to make decisions and be independent, if this means sometimes letting them make mistakes, so be it, but you need to give them space to grow, learn and be recognised.

The second part of the book is a collection of interviews with different well established people at staff engineer roles, I didn’t find much to be said about this as these were in large part the inspiration for the knowledge described in the first part, but it is useful and even calming to know that other people had their share of difficulties and it would be more worrying if the path to a staff engineer was smooth rather than intertwined with a fair bit of various hardships.

Final words

To conclude, one of the thoughts that stuck with me is that you should want to alternate between leading and following, for the sake of the organisation, but also for your own mental endurance and learning opportunities, you shouldn’t be the person with all the answers and your role will more often than not be facilitating the discovery of a solution with input from others which gets increasingly more important as you organisation grows. The amount of small bits of wisdom and references to other books and blogs makes this book also an excellent guide to the staff engineer path over a longer period, it is certainly a book I will keep coming back to.