Team Topologies

Team Topologies: Organizing Business and Technology Teams for Fast Flow by Mathew Skelton and Manuel Pais

Teams as the Means of Delivery

The Problem with Org Charts

Something I have noticed at enterprises I’ve been a part of is the disconnect between the organizational structure articulated by the org chart and how roles and responsbilities are actually divided up. This has been especially pronounced in the small non-profits and swiftly moving early stage startups I’ve been a part of. It’s almost like we have the org chart as a loose score, yet once the team starts storming and norming on its road to performing, all decorum slips away and settle into a culture that is uniquely ours and that leverages the latent talents of those in the room. Niels Pflaeging writes that there are actually three different organization structures in every organization - the formal structure itself (spelled out in that org chart), an informal structure (where we see the “realm of influence” between the individuals), and the value creation structure (how inter-personal reputation is leveraged to actually get the work done). I found keeping these three parallel realities alive in my imagination at once to be particularly compelling when I reflect on how things actually happened on the teams I’ve been on and managed.

The central thesis of this book is that it is possible to hold teams as the foundational organization fundamental that we can design and optimize for in the delivery of software. The book explores four core team types - stream-aligned, platform, enabling, and complicated-subsystem. The authors also outline three team interation modes - collaboration, X-as-a-Service, and faciliting. The book also gives ample examples of how you can approach these concepts at orgs of different sizes and stages of maturity. What I found particularly cogent was the idea that one of the reasons we haven’t seen orgs really fullfill the promise of their adoption of agile software devleopment and lean development cycles is their org designs aren’t set up to propogate those values and practices. Older forms of org design aren’t set up to allow for the rapid reshaping of teams in lean agile development cultures. This book is a good coaching aid for orgs that are witnessing that and looking for some frameworks to navigate the choppy water they’re encountering.

Team-First Thinking

“Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy”, Allan Kelly

This chapter organizes a thesis that I think is at the heart of this book, “when it comes to measuring performance, teams matter more than individuals”. Specifically, we must train ourselves to not think of assigning work to individuals, but to teams. This will necessitate we create high trust environments, and the authors remind us that this is easier to achieve in small teams. But team size and high trust are not the only ingredients, we also need to give the team time to establish itself. We typically talk about teams going through three phases of storming, norming and performing, and each team will pass through those stages at different rates. I find for small teams (less than 12 people) that we go through a version of that process each time a new team member joins. Each new team member brings a world of experience, values, expectations and skills to the team, and it takes time for the collective to integrate these effectively.

The authors state that for teams to work, team members should put the needs of the team above their own. This is not entirely true. It is important for human beings to never lose track of their core needs, even when contributing to the work of a collective. There have been terrible moments in human history when prioritizing the collective over individual need has led to mass enslavement and fascism. I think what the authors are reaching for here is a healthy weight of the global priorities of the team alongside individual needs. In Particle Swarm optimizers this is made explicit by setting a percentage for how much an individual agent will reference their own personal history versus the swarm’s history in select their next position. This is a framework I’d like to see team members leveraging. Are you able to quantify moment to moment how much self interest versus collective is guiding your decision making? Have you agreed as a team what constitutes a shared value of prioritizing team history and horizon? Have you discussed what feedback and punitive response should take place if someone chronically does not serve those values?

In a team-first framework, team responsibilities are matched to the cognitive load the team can handle. “If we stress the team by giving 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”.