Instead of summarising another year, I was always giving preference to building plans for the next one. 2022 was no exception, and I didn’t really post or even think about its results. The beginning of 2023 brought me some fresh ideas as well as lots of new books on my bookshelf. Some of them I’ve known about, and some became a discovery. But they all have things in common – they’re all somehow related to technical leadership, and I do find them useful for growing in this direction.
Today, I will share Part 1 of those books that I have added to my “must-read” list as well as the reasoning for choosing them. If you pursue the same goal of getting stronger as a technical leader, perhaps, you can find some inspiration in my list as well. Feel free to share your comments about the books, if you’ve read any!
This was the very first book that caught my attention last year. Long story short: I was looking for a better understanding of different technical leadership roles (principal, architect) and their responsibilities. Around that time, I also attended an online software architecture conference, and there was a technical leadership track.
One of the attendees shared a link to the Staff Engineer website and left positive feedback about the related book. I started reading articles on the website, got impressed then decided to get a complete book. It’s now on my bookshelf and will be the first one to read in 2023.
I don’t hold a people manager role at the moment, I’m rather interested in technical leadership. Despite that, his book ended up on my “to-read” list with a purpose. One of the areas I’d like to discover is how to build efficient collaboration between a people manager and a technical leader so that their development teams can evolve faster and tackle modern challenges.
“97 Things…” is a bunch of few-pages-articles from experts where they share their discoveries on different aspects of engineering manager life. I do hope that their insights can shed some light on how engineering managers perceive collaboration with the development teams, what they expect and how they try to help their crew solve problems.
Probably, one of the most mentioned books. When I just took on a Test Architect role, I immediately approached my fellow software architects for tips of advice on how they challenge other people’s designs and how to structure my knowledge in that area. After that conversation “A Craftsman’s Guide…” book ended up on my To-Do list, waiting in the wings.
Book readers are divided into two camps, though. Some people really like it and give it 5 stars out of 5. Many other reviewers of the book say that the content could have been shrunk into 30 pages. Which, I personally think, is not the case. Perhaps, it’s a classic situation when more knowledgeable people have high expectations from material for less experienced folks.
I haven’t started reading, therefore, haven’t built any solid opinion yet. Hopefully, in a couple of months from now I might switch from the above-mentioned publications to this one.
Purchasing this book is the merit of another one on this list. Will Larson, the author, published his firstborn “An Elegant Puzzle…” book a couple of years before the “Staff Engineer: Leadership beyond the management track”. As I’ve mentioned, I was really impressed by the blog content which was the basis of the Staff Engineer book. So, I added both books to my shopping cart without hesitation.
What are the expectations? I don’t have any particular gaps to be filled by this book at the moment. I’m rather interested in Will’s experience of handling different routine things such as technical debt. Or influencing engineering culture in a company, for instance.
Speaking of the devil culture… Every people manager around me has been talking about this book for a while now. Apparently, software development teams and companies nowadays are becoming more and more international. The complexity of managing such diverse communities increases accordingly.
While being a bit sceptical by nature, I don’t really have high expectations from this publication. However, people around me keep praising “The Culture Map” as a source of insights that helped them to understand their crew better. In fact, I did notice some improvements in how they started managing their teams after completing the book. Well then, I got the book and hope to grab it after the above-mentioned, and write an extended review at some point.
This folio is not directly related to my current test architect role or even area of expertise. But with no doubt, a product mindset is one of the key ingredients of a self-sustaining quality assurance specialist or even a team member. When reading the excerpts from the book, I got a feeling that it might be a good starting point for product managers or even inspiration for executive-level managers. The authors of the book (Silicon Valley Product Group) state they know how great products are built and can help readers build them too.
My personal expectation from this book is much more humble – I’d like to have a better understanding of how business people and tech geeks can collaborate better. And, indeed, create tech products customers love. As simple as that.
This book’s been on my shelf for a while now. I even started reading it some time ago but then shamefully abandoned it because it had no practical value for me. At that time. Since then lots of things have changed: my role has changed, we all got to know the lockdown very closely, and the value of remote work was rethought. The value of many things was, actually, rethought…
While being quite remote-friendly, software development still faced the need of rethinking how teams look and interact in order to adapt to the new reality. The “Team Topologies” book seems to have insights into how technical teams can work better as a single unit, all together, and progress faster. One of the reviewers, in fact, mentioned the following: “What everyone actually knows: the way I set up the teams will be reflected in my architecture. And how should teams be set up so that the workflow is best ensured? There are 4 team typologies to choose from. It is important to combine these carefully. A MUST-READ for Scrum Masters, Product Owners, Architects and everyone who influences team design.” Well, I will give it another try then 🙂
That’s it for today, folks! I still have plenty of good tech/process books in the bookcase that I have to review and plan for this year. The second part will be published in the upcoming days. And in the meantime, I hope you had a good year and going to have an even better one ahead. Stay tuned!