Introduction
Recently, I started reading Team Topologies and quickly noticed that many of the key concepts in the book resonated deeply with my experiences at Dovetail. The most striking realization was the power of teams over individuals. This idea challenged some traditional notions of performance and productivity, highlighting that team structure and dynamics are far more important than individual brilliance. Reflecting on these concepts has helped me better understand some of the organizational issues we’ve encountered and provided a fresh lens for approaching potential solutions. This blog is the first in a series where I’ll explore the key learnings from Team Topologies and share how they relate to my own experiences.
1. Teams, Not Individuals, Drive Success
In the bestselling book Team of Teams, retired US Army General Stanley McChrystal notes that the best-performing teams “accomplish remarkable feats not simply because of the individual qualifications of their members but because those members coalesce into a single organism.” This insight reflects the core principle that teams, not individuals, drive success in modern organizations.
Research from Google reinforces this point, finding that who is on the team matters less than the team’s dynamics. High-performing teams emphasise psychological safety, dependability, structure, clarity, and meaning—factors that are impossible to achieve through individual performance alone.
2. The Impact of Team Size
Team size plays a significant role in maintaining effective team dynamics. Allowing teams to grow beyond the “magic” seven-to-nine size risks trust breakdowns, poor decisions, and reduced accountability. Instead, organizations should prioritise small, stable, and long-lived teams, as Allan Kelly suggests in his book Project Myopia. Stable teams help foster “continuity of care” for software systems, enabling higher quality, cleaner code, and improved system operability.
If we stress the team by giving it responsibility for part of the system that is beyond its cognitive load capacity, it ceases to act like a high-performing unit and starts to behave like a loosely associated group of individuals, each trying to accomplish their individual tasks without the space to consider if those are in the team’s best interest.
3. Team Ownership and Accountability
Team ownership is another critical factor. When multiple teams can modify the same system or subsystem, accountability is blurred, and technical debt accumulates. However, a single team with full ownership of a subsystem can take control of short-term fixes and ensure they are addressed properly in the long term. Ownership enables better decision-making and continuous improvement, giving the team the autonomy to operate more effectively.
At the end of the day, technology teams need to invest in proven team practices like continuous delivery, test-first development, and a focus on software operability and releasability. Without them, all the effort invested in a team-first approach to work and flow will be greatly undermined or at least underachieved.
4. Avoiding Anti-Patterns in Team Design
Poor team design can lead to suboptimal outcomes. The first anti-pattern is ad hoc team design. This includes teams that have grown too large and been broken up as the communication overhead starts taking a toll, teams created to take care of all COTS software or all middleware, or a DBA team created after a software crash in production due to poor database handling. Of course, all of these situations should trigger some action, but without considering the broader context of the interrelationships between teams, what seems like a natural solution might slow down delivery and eat away at the autonomy of teams.
The other common anti-pattern is shuffling team members. This leads to extremely volatile teams assembled on a project basis and disassembled immediately afterward, perhaps leaving one or two engineers behind to handle the “hardening” and maintenance phases of the application(s). Such instability erodes trust, increases onboarding time, and decreases team cohesion.
Key Takeaway: Teams, not individuals, are the foundation of effective software development. Small, long-lived teams with ownership and autonomy produce better outcomes and maintain healthier software systems.
Final Reflections
Team Topologies offers a fresh perspective on team design. By focusing on team-first principles—like smaller, stable teams with clear ownership—companies can achieve faster, more predictable software delivery. The book’s insights into the importance of team structure, accountability, and avoiding anti-patterns provide a practical roadmap for organizations seeking to move from chaotic coordination to fast, intentional flow. By putting these principles into practice, organizations can build better teams—and better software—with fewer roadblocks along the way.