September 9, 2020
Far too bloated, but very nice references!
This video here: https://www.youtube.com/watch?v=Tvt0A... has one of the authors explaining what's in this book.
I made 135 highlights on kindle, so there has to be some value in it, but the book could easily have been made 5 times shorter.
Bits of information I remember and found interesting:
* Decisions should be taken by people who have the most information in order to make the decision.
* Reverse Conway maneuver: ensure teams can't communicate well, and the software they produce will have very clear boundaries
* Dunbar's number 7+-2: the optimal number of individuals on a team. Some teams could stretch this number to 15. Here "optimal" refers to social interactions. Above that number, people won't "trust" other people enough to work effectively with them.
* Dan Pink's 3 elements of intrinsic motivation: autonomy, mastery and purpose
* If we have managers deciding which services will be built by which team, we implicitly have managers deciding on the system architecture.
* If you don't want teams to communicate, give them separate tools (slack vs email vs JIRA, trello, hipchat, etc :P)
* 3 types of cognitive load: intrinsic (language syntax), extrinsic (deployment and how systems communicate) and germaine (business knowledge). Need to minimize the intrinsic and extrinsic and maximise the germaine kinds of knowledge, as business knowledge is what actully brings $
* 3 levels of system complexity: simple, complicated and complex. Simple = can fit inside one person's head and leave room; Complicated = can't fit inside one person's head, but they're traceable by a human mind; Complex = has non-intuitive/ non-deterministic behaviours and can't fit inside a single person's mind
* One team can support 2-3 simple domains OR 1 complicated+1 simple one OR 1 complex domain (rules of thumb)
* If a team has a complex domain, and a simple one, they might just end up solving the simpler problems and postponing the harder ones forever
* Team API: have a place that describes what the team does and how to interact with them
* put teams that naturally have a need to communicate, in the same space
* The ration between stream aligned and other types of teams should be between 6:1 and 9:1. Wow, lots of stream teams there!
* Monolith types: joint-at-the-db, monolithic build, monolithic release, monolithic model, monolithic workspace (come on, this one's stretching it!)
* Ways to break up a monolith: by business domain, change cadence, team location, risk profile, performance isolation (services supporting 3RPS on average, constantly vs services who stay down most of the year, but then need to process big data for Christmas), technology, user personas; And the test for the monolith split: does the new team architecture support more independent teams?
* Hand-offs between teams are bad
* Having teams that maintain systems and teams which build new systems seems to be an anti pattern; The team that built a system should operate it
4 Team types:
* Stream-aligned (the authors refuse to call them "feature teams" for some reason). These ship features. They're aligned to make changes where the business most requires them
* Complicated-subsystem teams: teams created from people who are basically all PHDs or work on very specialized things (image processing, NLP, etc). They probably act like platform teams.
* Platform teams: they create services that the stream-aligned teams will use
* Enabling teams: teams experienced professionals, going around and helping other teams in specific areas (for instance, specialized could infrastructure people, going around and helping other teams move to the cloud. Same for setting up CI/CD etc.)
3 Interaction modes:
* Collaboration: in this interaction mode, team boundaries are broken, the teams become one for a period of time. Like this, they can spot problems/innovate faster, but communication overhead is high.
* Facilitation: one team teaches the other some kind of technique, or helps the other team in some way.
* X-as-a-service: The teams are extremely separated, and communicate through clear interfaces (web services for example). This interaction mode optimizes for predictability of delivery, and it's the opposite to "collaboration" (so not optimal for innovation)
... so some interesting insights, probably backed by research done by other authors, reported in other books. This book is a good starting place and conversation-starter about team design. It's however too repetitive, and the case studies must be taken with a grain of salt, because it's kind of hard to support a model with just one anecdote.
The number of references quoted by this book is high, and at least the articles that I read are very qualitative. If you read this book, I think that the references should be mandatory read as well.
In the end though, I got left with the feeling that there's far more about team design out there than this book is addressing. For instance in "Leading the unleadable" a lot of personality quirks of team members get discussed. This book does not consider human beings as individuals. There's no mention even of seniority level in a book about team design, which I find kind of weird. Should we put 5 juniors together and call it a team? How about 5 seniors? The book presents some mental models about teams and how they collaborate, which is good, but a little too simplistic. What happens if you have introverts on the team, do you make them work in an x-as-a-service interaction mode, because they don't know/like to communicate with people? What do you do when you have a bunch of bored seniors, do you put them in enabling teams and let them walk around and be pedantic to other people? :D Does this book cover interactions with the marketing, sales, and account management teams as well? I get it that these topics are very complex, but would have been great if instead of being so repetitive, the authors would have acknowledged these topics, and declared them out of scope. The book explains too much what the book's purpose is, doesn't deliver enough information to reach that purpose, and leaves all other related topics completely out.
This video here: https://www.youtube.com/watch?v=Tvt0A... has one of the authors explaining what's in this book.
I made 135 highlights on kindle, so there has to be some value in it, but the book could easily have been made 5 times shorter.
Bits of information I remember and found interesting:
* Decisions should be taken by people who have the most information in order to make the decision.
* Reverse Conway maneuver: ensure teams can't communicate well, and the software they produce will have very clear boundaries
* Dunbar's number 7+-2: the optimal number of individuals on a team. Some teams could stretch this number to 15. Here "optimal" refers to social interactions. Above that number, people won't "trust" other people enough to work effectively with them.
* Dan Pink's 3 elements of intrinsic motivation: autonomy, mastery and purpose
* If we have managers deciding which services will be built by which team, we implicitly have managers deciding on the system architecture.
* If you don't want teams to communicate, give them separate tools (slack vs email vs JIRA, trello, hipchat, etc :P)
* 3 types of cognitive load: intrinsic (language syntax), extrinsic (deployment and how systems communicate) and germaine (business knowledge). Need to minimize the intrinsic and extrinsic and maximise the germaine kinds of knowledge, as business knowledge is what actully brings $
* 3 levels of system complexity: simple, complicated and complex. Simple = can fit inside one person's head and leave room; Complicated = can't fit inside one person's head, but they're traceable by a human mind; Complex = has non-intuitive/ non-deterministic behaviours and can't fit inside a single person's mind
* One team can support 2-3 simple domains OR 1 complicated+1 simple one OR 1 complex domain (rules of thumb)
* If a team has a complex domain, and a simple one, they might just end up solving the simpler problems and postponing the harder ones forever
* Team API: have a place that describes what the team does and how to interact with them
* put teams that naturally have a need to communicate, in the same space
* The ration between stream aligned and other types of teams should be between 6:1 and 9:1. Wow, lots of stream teams there!
* Monolith types: joint-at-the-db, monolithic build, monolithic release, monolithic model, monolithic workspace (come on, this one's stretching it!)
* Ways to break up a monolith: by business domain, change cadence, team location, risk profile, performance isolation (services supporting 3RPS on average, constantly vs services who stay down most of the year, but then need to process big data for Christmas), technology, user personas; And the test for the monolith split: does the new team architecture support more independent teams?
* Hand-offs between teams are bad
* Having teams that maintain systems and teams which build new systems seems to be an anti pattern; The team that built a system should operate it
4 Team types:
* Stream-aligned (the authors refuse to call them "feature teams" for some reason). These ship features. They're aligned to make changes where the business most requires them
* Complicated-subsystem teams: teams created from people who are basically all PHDs or work on very specialized things (image processing, NLP, etc). They probably act like platform teams.
* Platform teams: they create services that the stream-aligned teams will use
* Enabling teams: teams experienced professionals, going around and helping other teams in specific areas (for instance, specialized could infrastructure people, going around and helping other teams move to the cloud. Same for setting up CI/CD etc.)
3 Interaction modes:
* Collaboration: in this interaction mode, team boundaries are broken, the teams become one for a period of time. Like this, they can spot problems/innovate faster, but communication overhead is high.
* Facilitation: one team teaches the other some kind of technique, or helps the other team in some way.
* X-as-a-service: The teams are extremely separated, and communicate through clear interfaces (web services for example). This interaction mode optimizes for predictability of delivery, and it's the opposite to "collaboration" (so not optimal for innovation)
... so some interesting insights, probably backed by research done by other authors, reported in other books. This book is a good starting place and conversation-starter about team design. It's however too repetitive, and the case studies must be taken with a grain of salt, because it's kind of hard to support a model with just one anecdote.
The number of references quoted by this book is high, and at least the articles that I read are very qualitative. If you read this book, I think that the references should be mandatory read as well.
In the end though, I got left with the feeling that there's far more about team design out there than this book is addressing. For instance in "Leading the unleadable" a lot of personality quirks of team members get discussed. This book does not consider human beings as individuals. There's no mention even of seniority level in a book about team design, which I find kind of weird. Should we put 5 juniors together and call it a team? How about 5 seniors? The book presents some mental models about teams and how they collaborate, which is good, but a little too simplistic. What happens if you have introverts on the team, do you make them work in an x-as-a-service interaction mode, because they don't know/like to communicate with people? What do you do when you have a bunch of bored seniors, do you put them in enabling teams and let them walk around and be pedantic to other people? :D Does this book cover interactions with the marketing, sales, and account management teams as well? I get it that these topics are very complex, but would have been great if instead of being so repetitive, the authors would have acknowledged these topics, and declared them out of scope. The book explains too much what the book's purpose is, doesn't deliver enough information to reach that purpose, and leaves all other related topics completely out.
