POSTS
Staff Engineer Book and why you should read it
- 3 minutes read - 496 wordsIf you are:
- Looking for a new book to read during the holidays.
- A senior software engineer looking for an opportunity to grow to staff/principal.
- A staff/principal/distinguished software engineer trying to fit yourself into this new career model or be better at it.
I have a great recommendation for you: Staff Engineer: Leadership beyond the management track by Will Larson. You can find it on its website and on Amazon
Packing and enhancing all the articles present on its guide website, this book presents a new way of thinking about technical leadership. It shows that it’s possible to be a technical leader and cause a great impact inside your organization without having to totally change to a manager/managerial position.
Focusing on 1) the archetypes of a staff+ software engineer; 2) what are the their main activities and responsibilities; 3) How to cause impact as an “individual contributor” and 4) how to find space in your organization or find another to be act as real engineer; this book can in a well organized manner answer most of the questions that would erupt when defining or pursuing this career path.
In my opinion, this title is a mandatory reading for any software engineer (put it before Clean Architecture, for sure!). Considering that our technical career has been evolving really fast and a huge amount of tech start-ups are emerging and ditching those old career models [in favor of pure technical people], it’s a must to understand how we can keep growing technically and causing real business development without having to ditch our loved coding time.
It brings pure conceptual topics such as the archetypes of a staff eng (tech lead, solver, right hand and architect) and greatly connects them to real-world scenarios and cases. The author interviewed a diverse group of staff, principal and distinguished engineers working for a variety of companies, e.g., Fastly, DropBox, Squarespace, Slack, and etc to extract their daily activities and responsibilities. Each one of them brought a new perspective and contributed to a consensus about that job/role description. They showed that it’s possible, feasible and valuable to have such profiles (individual contributors) within their companies working side-by-side to managers, directors and executives.
As a software engineer trying to find that golden tech spot, the entire narrative resonates perfectly with me. At the end of the day, we are all trying to evolve, generate impact and growth; it’s not that easy to combine our competence and our personal willingness to do something to what our companies really demands. I know you would like to be coding right now, wouldn’t you? So do I; but should I? Should I be coding instead of mentoring one? Is there still a place for architects detached from the tech team? To which problem or team should we be involved?
These are a couple of answers presented there.
It doesn’t matter if you are a software engineer, a manager or any non-IT professional, you will benefit from the reading.