Skip to content

Commit

Permalink
team topologies
Browse files Browse the repository at this point in the history
  • Loading branch information
klausbreyer committed Jun 25, 2024
1 parent ada0e6d commit 369b686
Show file tree
Hide file tree
Showing 2 changed files with 47 additions and 0 deletions.
47 changes: 47 additions & 0 deletions content/posts/2024-bookshelf-team-topologies/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: "Team Topologies, Skelton & Pais, 2019"
categories: ["Bookshelf"]
date: 2024-06-24
social: "https://www.linkedin.com/posts/klaus-breyer_team-topologies-skelton-pais-2019-klaus-activity-7211252754739068928-6P49?"
---

{{< gallery "https://amzn.to/3xtHVEq,title.jpg" >}}

First of all, I very much like Matthew Skelton's and Manuel Pais's framework for designing effective software teams:

### Four Team Types:

1. **Stream-Aligned Teams**: Focus on flow and reducing dependencies.
2. **Complicated Subsystem Teams**: Handle specific complex areas; supported by platform teams.
3. **Platform Teams**: Provide services and tools to other teams.
4. **Enabling Teams**: Act as coaches and investigators for stream-aligned teams.

### Three Interaction Modes:

1. **Collaboration**: Close teamwork.
2. **X-as-a-Service**: Clear, minimal collaboration.
3. **Facilitating**: Helping teams clear obstacles.

Those team types and the interaction modes can express every inter-team interaction. And this alone is incredibly helpful, as is having a vocabulary to describe things. (Like Shape Up also did not re-invent the wheel, but gives simple principles in understandable terms)

However, I don't like that they pitch microservices all the time, making them seem like the only solution to solving scale problems.

### Anyway, here's a summary of my notes:

Organizational charts often fail to capture the dynamic nature of real work environments. Instead of being static, team structures need to be flexible and adaptive.

Teams should be long-lived to maintain stability and effectiveness over time.

A key concept from the book is the Inverse Conway Maneuver: structuring your organization as you want your software architecture to be. This helps align the development process with business goals.

Effective team design relies on the same architectural principles: loose coupling and high cohesion. This means minimizing dependencies and ensuring each team has clear, bounded responsibilities.

It's also crucial to minimize the cognitive load for team members by simplifying and clarifying their roles.

Not all communication is beneficial, so focusing on defined team interfaces and avoiding excessive meetings that can hinder progress is essential.

In managing teams, assigning specific domains to each team and limiting the number of domains to manage complexity effectively is vital. Avoiding anti-patterns like ad hoc team design and frequent team member shuffling is also essential.

Cross-functional teams are recommended for their ability to operate independently and cover multiple functions. When scaling organizations, match team types to organizational and software maturity levels and visualize dependencies to effectively manage knowledge, tasks, and resources.

Continuous improvement is a core theme, with team topologies needing to reflect the current context and always aiming to minimize dependencies. By following these principles, organizations can foster a dynamic and efficient team structure that supports continuous delivery and operational excellence.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 369b686

Please sign in to comment.