Mar 8, 2022
Peopleware Revisited
Discovering Team Topologies
When Tom Demarco and Tim Lister first published PeopleWare back in 1987, I was convinced that we would eventually have to change the way we ran our projects. There was no way we could ever become effective as project managers if we didn’t start thinking about better ways for people to work together. That was the main argument of Peopleware, and it made sense.
It’s about the Team
Almost 35 years since Peopleware first hit the shelves, we’ve watched project after project fail, and the carnage within the vast and growing category of Information Technology related projects (which was the specific focus of Peopleware) has been particularly depressing.
What have we learned? Well, we’ve seen the concepts of Peopleware validated again and again when it comes to team structure. A compelling example of what we’ve learned, and — more importantly — how we can apply what we’ve learned is brought to life in Team Topologies by Matthew Skelton and Manuel Paris.
Skelton and Paris argue that the way we structure our teams tends to dictate the very architecture of what we deliver. The authors explain this phenomenon in quite a bit of detail, but I find their specific examples of how this plays out in software architecture to be quite illuminating.
In Figure 1, below, Skelton and Paris describe what — for at least a couple of decades — was a fairly conventional set of software system teams, with a “Front-End” developer, a “Back-end developer, and a shared DBA and “Ops” team, who were external to the core development teams. As the authors point out, the communication within these teams is typically as follows: “Front-end devs communicate only with back-end devs, who communicate with a single DBA for the database changes.”
So what is the resulting architecture of the systems produced by these teams? As you can see from Figure 2, below, it follows almost exactly the nature and structure of the teams shown in Figure 1. As Skelton and Paris point out here, the software architecture “…reflects and matches the team….The diagram has simply been rotated ninety degrees.”
An Introduction to Team Topologies
Skelton and Paris have definitely convinced me that there is something valuable in thinking about Team Topologies at least as much as we think about the architecture of the process or system our project is expected to deliver. Especially since the team we deploy will have a profound influence on what we deliver, potentially building in solution limitations that we may not want.
Team Topologies is a rather substantive area of study, so I will not attempt to coverage it in excruciating detail in this post. Still, it is as least worth covering what Skelton and Paris refer to as the “four fundamental team topologies” that can be effectively utilized as a starting point in designing your teams. Below, are the authors descriptions of these topologies:
Stream -Aligned Teams. “A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona. Further, the team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.”
Enabling Teams. “An enabling team is composed of specialists in a given technical (or product) domain….” This team type helps “bridge” capability gaps in “stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks,” etc.
Complicated Subsystem Teams. “A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem. The goal of this team is to reduce the cognitive load of stream-aligned teams working on systems that include or use the complicated subsystem.”
Platform Teams.”The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. The stream-aligned team maintains full ownership of building, running, and fixing their application in production. The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services. This definition of ‘platform’ is aligned with Evan Bottcher’s definition of a digital platform: ‘A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.’”
Keeping the Team Goodness Going
Finally, once you’ve begun to “architect” your teams, while ensuring their structure will provide the solutions you and your stakeholders desire, you can’t stop there with team designs that are built for a point in time. Skelton and Paris remind us that “team structures and communication pathways need to evolve with technological and organizational maturity.” Those periods of “technical and product discovery (that) typically require a highly collaborative environment” require one sort of team structure, as opposed to periods when the key technologies and products are well established, which require the team to evolve to a different sort of structure.
It’s a lot of effort, to be sure, but building and evolving a great team is always worth it.
Get new BlueProject Posts delivered directly to your email box. Sign-up for the BlueNotes Newsletter.
