100 Books Like Team Topologies

This book helped me set my initial approach to software development and I still periodically return to it for grounding.

An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.

Microsoft Secrets principles are great theory, but how do they feel in practice? Here is the Microsoft version of Tracy Kidder’s classic Soul of a New Machine.

A team of eager Microsoft engineers and product managers go for it, trying to build a children’s encyclopedia to extend the success of Microsoft’s earlier Encarta product. The genius of overlapping defined roles on a quest for a common goal comes face to face with the confusion, surprises, conflicts, diversions, disappointments, and elations inherent in most large-scale software programs trying to do something new (and aren’t they all?). Theory and intensely human practice come together.

I spent my career leading software engineering at two of America’s top banks. It’s not all innovative work, as you might guess, and here is where Toyota comes in. 

Toyota teaches the difference between routine, standardized work (where we use predictive process control) and creative work (where we use adaptive process control). Balancing this in practice is a key to being a great software engineering leader. For those manufacturing-like processes (incremental feature addition, defect repair) the Toyota manufacturing way became the basis of the Agile movement a decade later: flow, pull, level work, quality the first time, process standardization and continuous improvement, and closeness to customers. Toyota Way provides a deeper understanding than any agile seminar. 

When this book was released, I was immersed in a huge failing project at Wells Fargo, struggling to make sense of it all. This book helped me put the failure in perspective and showed a better way that I embraced for the rest of my career. 

The key insight is that large-scale innovation is not like manufacturing – it is less about planning and control, more about people, rapid learning, and adaptation. Here we learn concepts such as the Chief Engineer, lightweight milestone—and responsibility-based project management, and focusing on engineering skills and vendor partnerships. Shelve the elaborate process frameworks consultants are selling you, focus on the basics Toyota emphasized throughout their glory years. 

My journey in the world of software development has been arduous and challenging.

One of the common struggles we all face is the overwhelming number of solutions available, making it impossible to fully grasp everything at a deep level.

Just when I thought I had mastered an approach and felt competent in it, a new shiny approach would emerge, demanding my immediate attention. It often felt like a never-ending race to keep up with the ever-evolving field.

This constant pursuit of staying relevant as a software engineer can be frustrating, as it feels like we are always lagging behind the rapidly advancing world. I discovered that knowledge of specific technologies, frameworks, or libraries does not easily transfer across different technology stacks. They are too specific and lack universality. It was then that I turned my focus to more general principles of software engineering.

I realized that there are fundamental engineering… show more.

In my quest (you can also call it a professional career), I’m drawn to complexity since we create software for complex problems. There are books on Complexity Science; however, they are very academic. This particular book gives practical advice to cope with complexity. It acknowledges the balance between the emotional and rational sides and why we must bring our full-self to any aspect of our life. The “don’t be emotional, this is work” proves to be a threat to our mental well-being and kills innovation in a company. In the book, the authors explore how to listen to our bodies in the face of complexity in an accessible way.

Accelerate is a book about data. The authors used data collected during their PhD projects in order to prove The DevOps is effective.

They have all sorts of different ways to measure DevOps, it sufficiency, and the fact that way more projects succeed when you do DevOps, rather than waterfall methodology.

The book essentially show can be used as evidence of return on investment when modernizing your IT department. I am a person who loves data, and thus I absolutely love this book. Also, if you listen to the audiobook version, one of the authors reads it to you and her personality really shines through in a fun way.

I really enjoyed listening to Nicole read a book about to me about data!

Technology allowed us to share information instantly; it also enabled the creation of new products. However, there is the reverse of the coin, where technology is used for abuse. Eva's book comes from her experience with survivors of abuse, and she shows how technology can be abused, and what we can use in our design process to create products that take safety into consideration. It is a must-read for anyone involved in the creation of digital products.

A Seat at the Table is a wonderful book about how the role of tech leaders in general and CIO specifically have changed dramatically over the last decades.

From a cost center where spending should be kept to an absolute minimum, with a strong focus on hardware to an enabling role that drives and innovate business. Mark Schwartz guides us through these changes in his normal entertaining way.

I've rarely (never) laughed out loud from a business book but this one did that for me.

It is my belief that half of being an effective software architect is mastering people skills.

However soft they are, these skills are the hardest to master. This book focuses on the communication and soft skills necessary to become an effective architect, and it does it superbly. The author’s elevator metaphor is perfect in that it emphasizes the fact that communication must exist on all levels within the organization, and the skills needed at each level differ.

I personally found this book very useful in honing my communication skills as a software architect.