10 ms·

TeamTopologies

178 points by BerislavLopac 3y ago

esafak 3y ago
I recommend this book; it is practical, and sensible. And unlike most business books, it is concise.
hactually 3y ago
You get the feeling ol Martin has been out of the game too long? It feels like he's only catching up with what many have been doing for decades building high performance teams.
- bdg 3y ago
  In the article he identified the authors are moving the platform concept to a "grouping" instead of a team. This is a very recent development that mostly only people who are active in the community know about.
  - dusanh 3y ago
    Isn't that just a team of people now called a different word?
    - bdg 3y ago
      No, it groups together teams. Teams do not group teams.
- xarope 3y ago
  I was about to give some feedback and quote my favourite author Jorge Luis Borges, but then I realised Martin has already done something similar: George Box neatly quipped: "all models are wrong, some are useful". Thus Team Topologies is wrong: complex organizations cannot be simply broken down into just four kinds of teams and three kinds of interactions. But constraints like this are what makes a model useful. Team Topologies is a tool that impels people to evolve their organization into a more effective way of operating, one that allows stream-aligned teams to maximize their flow by lightening their cognitive load. So I am thankful that there are people like Martin Fowler who are willing to write up and remind some of us, who have perhaps forgotten more than others have learnt, that we may continue to avoid the consequences of that aphorism: “Those who cannot remember the past are condemned to repeat it.”
- pvdoom 3y ago
  God I hate the phrase "high performance teams". Its one of those buzzwords, that doesn't have a clear meaning, but most of the time it turns into "people that deliver a lot but also work a lot of overtime at a killer pace". Most organisations don't even have a clear picture of what performance means, so it defaults to deliver more and work more ...
- oaiey 3y ago
  Well when the whole world is reading, you only publish what is really "solid" ... and that means ... not that ground-breaking. So I think you are right, he is catching up. Just I think the motivation is more "do not screw my reputation/company up" instead of the "out of the game too long". On the other side: You can be perfectly right ;)
jauntywundrkind 3y ago
There's a lot that I like about this book. Splitting up the mandate between platform and products teams, and eliminating friction, letting each team be good at their thing is I think an efficiency many companies indeed could benefit from. But I've also seen this book promoted heavily within an org, and the one core strength kept feeling like a core weakness that mades me incredibly sad, about how isolated it made work. It doesn't insist it has to be so, but the org I saw that was so excited for TEam Topologies loved how it continually stressed independence of teams. And as a direct result, I've seen cooperation, coordination, & cross-team planning plummet. In ways that keep having suboptimal plans get put into action with bad outcomes. Stream aligned teams would turn into complicated subsystem teams, after they created something complicated and gnarly while being stream/product aligned, and unchecked. I think the topologies here are quite useful framings, and as Fowler says the idea of trying to reduce cognitive complexity is an interesting one we haven't heard well represented before. And is probably due given how impractical making each team truly full stack devops has become, as the CI/CD/observability stack complexity has expanded. But I caution so much against the messages this book gives management, which is that stream/product aligned teams just need to be racehorses with blinders on & interference is bad. The book glories the stream aligned team, the value creator, and makes everyone else auxiliary, which is sort of true & great. But the book's glorification of execution speed doesn't leave much space for how and where cross-team wisdom happens, what kind of processes you have there. Broader cross-team architecture reviews, brainstorming, systems planning, systems coordination aren't well captured here: most teams need a strong collaboration mode to build good software that fits the architecture well. But the book only really regards a single collaboration need: those of platform teams to get feedback to ease their Developer's Experience. The missing element was ubuntu. If you want to go fast, go alone. If you want to go far, go together. - African Proverb
- esafak 3y ago
  How big was your company? I think beyond a certain size, independence of the team is the prize. You are not alone, for you have your mates. Beyond your team, trying to collaborate is like herding cats. Every team has its own priorities, everything moves more slowly, and the more stakeholders there are, the greater the risk of the project falling through. Bezos' stipulation that teams communicate through interfaces was a stroke of genius. This created a standard which allowed teams to self serve. I agree that teams must collaborate to go farther. One team can only do so much. Management should make sure all the teams stay aligned and hold them all accountable, but the teams themselves should still strive to be independent. It sounds like what your organization needed was a project manager to co-ordinate or a forum for the teams to share information.
hanifbbz 3y ago
Good summary of the book.
marsven_422 3y ago
[dead]
nologic01 3y ago
I find all such literature vague and hard to parse. The channels used to convey information are typically verbal descriptions and diagrams. It is never clear what exactly is meant by a topology, whether the description is covering all important aspects and, importantly, how we could recognize and have some assurance about the "optimality" of a pattern and why there isn't a better one just nearby. More formal descriptions are not necessarily the solution. They would need to be both concise and faithful to the system being modelled.
- elliotec 3y ago
  Have you read the book? Topology has a definition. It doesn’t mean anything different in this context. https://en.m.wikipedia.org/wiki/Topology https://en.m.wikipedia.org/wiki/Topology It seems like you’re just not willing to put in the effort of understanding the basics. Which would be fine if you didn’t plan on giving a review of the complexities.
  - nologic01 3y ago
    > Have you read the book? The comment was based on reading the review. I assume the review covers all essential contributions of the book and it is not merely a promotion piece. I would be more inclined to take your "advice" if you had made any effort to address my concerns / observations. I suspect you simply can't. > Topology has a definition. It doesn’t mean anything different in this context. Thanks for the gratuitous and patronizing arrogance. It further reinforces my sense that these pompous sounding vacuities are a marketing tool and have no intrinsic applicability.
  - gilleain 3y ago
    It means properties of teams that are preserved under continuous deformations? Or does it just mean 'some structure over a set'? That could really cover anything ... While it is certainly useful to consider how you structure your teams, using the term 'topology' seems like marketing gloss. Also alliteration, of course.
vasco 3y ago
The book was good and when I read it, it was helpful as it came out just as I was going from manager of a team to having to split that team and take over a few more in a group. Plus Manuel, one of the authors is a really friendly guy that pushed the Lisbon tech meetup scene forward around 10 years ago when nobody was having any regular local meetups and he was traveling between Spain and Portugal on the regular to make them happen (or so I remember). I presented my first proper talk in one of his meetups and I remember that going well and giving me a lot of confidence for other things later on. Definitely read it if you need to think about groups of teams!
pvdoom 3y ago
I love team topologies, it's really good. My one problem with it is that it kind of stops at the level of structuring a team and doesn't do much about the higher level of management of the organisation. Which needs a deep look just as much as how you structure your teams and if you have platform teams and whatnot. Hell, you could argue that the main reason why agile failed, was that it never addressed how to challenge and change upper-ish management. But its understandable, cause that shit is hard, its political, and its difficult with the current feudal entities that companies are
tsimionescu 3y ago
As someone who used to be part of a platform team, and is now actively working in the same organization to fight the creation of any more platform teams, I very much disagree with the article that this is a good working model. What we have found is that platform teams are a huge point of frustration for product teams, since they cause unnecessary and unmanageable coupling between different business divisions, leading to impossible to balance priorities. What we've seen happen over and over is that product A needs Feature A, and product B needs Feature B, and they both need it tomorrow, and the platform team only has resources for one. And since Product A and Product B are in different business divisions, you end up needing to involve a senior VP or even an officer to make a prioritization decision for a simple software feature, and everyone gets frustrated by the process. What we're striving towards instead is an "inner source" model, where a platform is collaboratively developped and maintained by multiple product teams. Each product team is then empowered to build new features as needed into the platform, and others can reuse them. Of course, the platform needs some architects and overall review, and all teams will not equally participate. But the key point is to encourage this collaboration mode, where no one team is a bottleneck for multiple products. The inspiration for this structure is obviously the open-source world, where multiple corporations and foundations collaborate on a single code base without needing to rely on a single platform vendor to provide features for them.
- elliotec 3y ago
  This is good insight and matches with my experience. As a product-focused engineer/manager, it’s too often I’ve found my teams giving up and taking into our own hands what “should be” owned by platform teams, while they work on things nobody seems to see value in.
- CraigJPerry 3y ago
  This sounds like fundamentally a business problem (we have finite resource, is product A or B our priority?) and trying to solve it with choices in the technology division. Well, here be dragons. Based on my experiences, the idea that a genuine bottleneck in tech is being made visible to customer division management and senior management, is generally an authentic way to ensure realism creeps back into the prioritisation and funding processes.
Foobar8568 3y ago
Platform teams mean that you ended up with a bare minimum of 5 different teams, not including deployment and support to transfer a file from a folder to another one in an automatic way. My current pain.
- quickthrower2 3y ago
  But that file is transferred in a SOC2 Type2 compliant way at least :-)
- lightbendover 3y ago
  If you only have a few teams in your company/organization, then you are not at a scale that necessitates a platform team and this discussion isn't for you. When dozens of teams need a shared capability (e.g. for ad serving across many verticals at a FAANG), then you absolutely need one or more.
  - rqtwteye 3y ago
    Who actually is at that scale? Not many. For everybody else you create a lot of complexity for no benefit.
    - lightbendover 3y ago
      I'll be the first to agree that most orgs do not need a platform team.
  - Foobar8568 3y ago
    Oh really? One team for managing IAM, one team per S3, one team for file process automation, one team for process management, one team handling the producer process, one team handling the consuming process, same for application on both side, the client who actually need the request +everything else. One team for a shared platform where it makes sense, sure, but everywhere, like it's some factory chain is the biggest waste of productivity.
    - 3y ago
AJRF 3y ago
I've found over the years that Martin Fowler blogs about things the C-Suite is already doing at their companies, and they use this as validation for their choices. This in turn has a virtuous cycle of keeping him popular. Almost everything he hawks causes misery for software developers, like his whole multi-year spin for Microservices, he's turned refactoring into a fetish (honestly there are people at my dayjob who have been "refactoring" the entire 3 years i've been here) and now hes blogged multiple times about platform teams - which - having been on one - don't work. I see him as a very damaging character. Well intentioned, i'm sure, but I don't think he has good ideas.
- disgruntledphd2 3y ago
  > he's turned refactoring into a fetish (honestly there are people at my dayjob who have been "refactoring" the entire 3 years i've been here) That's kinda dumb, but the book is super good, I learned a whole lot from it, and apply the principles basically all the time. He's been banging the drum on testing for longer, and that makes up for a lot of craziness (I'm with you on microservcies, except where you have 1k+ developers where they might make sense).
- Lutger 3y ago
  Working for 3 years and only refactoring, that's a whole new level of comedy. If you blame Fowler for this madness, then I see how you think his work is damaging. But its a bit like a health influencer telling people to stay hydrated and blame him for his fans damaging themselves by trying to drink 10 liters a day.
  - c-hendricks 3y ago
    Funny you should mention health influencers, as they're also prone to blanket suggestions without taking their audiences needs into account.
    - ourmandave 3y ago
      Sometimes they can work, like "stop doing tik-tok challenges."
mattmcknight 3y ago
I read this book last year and saw a few good ideas. However, it seems to largely be describing enterprise software, and not, say, companies developing a SaaS product. These are different enough that the same organizational constructs don't apply to both. The one takeaway that I stick with from the stream-aligned teams is that we need teams that can build a capability from front to back independently. I think the industry has taken a step backward with huge single page web applications that end up with microservice teams building back end services, but then a monolith on the front end that isn't as modular as a web app where you can simply link to another application. I don't know if microfrontends is the right answer, but a collection of mini-monoliths with shared data services seems to work well enough.
bob1029 3y ago
This seems too complicated to me. I've been trying to wrangle not even 20 team members without much success so maybe I am not an expert in these matters. BUT, I would say for certain that whatever Mr. Fowler is proposing here absolutely would crash into the rocks at our org. This is make-work orgchart fantasy IMO. I would also add that his suggestions around micro services did us absolutely no favors.
phamilton 3y ago
This is a solid book, but there's one concept in it that has drastically changed how I lead and collaborate across teams. The book describes 3 types of problems/areas: simple, complicated, and complex. The definitions of simple/complicated/complex has shifted for me a bit since I read it, but this is how I currently describe it: Simple - the solution is clear and is fairly low risk Complicated - the problem is well framed, but the solution isn't clear Complex - the problem itself isn't really clear This 3 tiered framing lends itself to so many useful structures and interactions. Junior/Senior/Staff scope of responsibility fits remarkably well. Sprint planning / Quarterly planning / Executive planning fits. The biggest thing it has helped with is recognizing that a team needs space to explore complex problems. Those teams need to operate very differently from a standard product stream team and recognizing that need is such an important thing.
hliyan 3y ago
My problem with Fowler is his tendency to reduce complex problems into concepts that can be represented in simple, abstract models/diagrams with weak analogies (e.g. the "streams" here, test pyramids, microservices, various bits of Agile), which are enthusiastically consumed by both inexperienced engineers and decision makers in management: a deadly combination. When much of the industry adopts these ideas, and the resulting inefficiencies become the baseline, it is virtually impossible for anyone to effectively detect those inefficiencies. It becomes a "is everyone crazy, or am I crazy?" situation, until some sort of disruption (e.g. widespread project/startup failures) forces the industry to paradigm shift back to sanity.

178 points by BerislavLopac 3y ago

I recommend this book; it is practical, and sensible. And unlike most business books, it is concise.

You get the feeling ol Martin has been out of the game too long? It feels like he's only catching up with what many have been doing for decades building high performance teams.

bdg 3y ago
In the article he identified the authors are moving the platform concept to a "grouping" instead of a team. This is a very recent development that mostly only people who are active in the community know about.
- dusanh 3y ago
  Isn't that just a team of people now called a different word?
  - bdg 3y ago
    No, it groups together teams. Teams do not group teams.
xarope 3y ago
I was about to give some feedback and quote my favourite author Jorge Luis Borges, but then I realised Martin has already done something similar: George Box neatly quipped: "all models are wrong, some are useful". Thus Team Topologies is wrong: complex organizations cannot be simply broken down into just four kinds of teams and three kinds of interactions. But constraints like this are what makes a model useful. Team Topologies is a tool that impels people to evolve their organization into a more effective way of operating, one that allows stream-aligned teams to maximize their flow by lightening their cognitive load. So I am thankful that there are people like Martin Fowler who are willing to write up and remind some of us, who have perhaps forgotten more than others have learnt, that we may continue to avoid the consequences of that aphorism: “Those who cannot remember the past are condemned to repeat it.”
pvdoom 3y ago
God I hate the phrase "high performance teams". Its one of those buzzwords, that doesn't have a clear meaning, but most of the time it turns into "people that deliver a lot but also work a lot of overtime at a killer pace". Most organisations don't even have a clear picture of what performance means, so it defaults to deliver more and work more ...
oaiey 3y ago
Well when the whole world is reading, you only publish what is really "solid" ... and that means ... not that ground-breaking. So I think you are right, he is catching up. Just I think the motivation is more "do not screw my reputation/company up" instead of the "out of the game too long". On the other side: You can be perfectly right ;)

jauntywundrkind 3y ago

There's a lot that I like about this book. Splitting up the mandate between platform and products teams, and eliminating friction, letting each team be good at their thing is I think an efficiency many companies indeed could benefit from. But I've also seen this book promoted heavily within an org, and the one core strength kept feeling like a core weakness that mades me incredibly sad, about how isolated it made work. It doesn't insist it has to be so, but the org I saw that was so excited for TEam Topologies loved how it continually stressed independence of teams. And as a direct result, I've seen cooperation, coordination, & cross-team planning plummet. In ways that keep having suboptimal plans get put into action with bad outcomes. Stream aligned teams would turn into complicated subsystem teams, after they created something complicated and gnarly while being stream/product aligned, and unchecked. I think the topologies here are quite useful framings, and as Fowler says the idea of trying to reduce cognitive complexity is an interesting one we haven't heard well represented before. And is probably due given how impractical making each team truly full stack devops has become, as the CI/CD/observability stack complexity has expanded. But I caution so much against the messages this book gives management, which is that stream/product aligned teams just need to be racehorses with blinders on & interference is bad. The book glories the stream aligned team, the value creator, and makes everyone else auxiliary, which is sort of true & great. But the book's glorification of execution speed doesn't leave much space for how and where cross-team wisdom happens, what kind of processes you have there. Broader cross-team architecture reviews, brainstorming, systems planning, systems coordination aren't well captured here: most teams need a strong collaboration mode to build good software that fits the architecture well. But the book only really regards a single collaboration need: those of platform teams to get feedback to ease their Developer's Experience. The missing element was ubuntu. If you want to go fast, go alone. If you want to go far, go together. - African Proverb

esafak 3y ago
How big was your company? I think beyond a certain size, independence of the team is the prize. You are not alone, for you have your mates. Beyond your team, trying to collaborate is like herding cats. Every team has its own priorities, everything moves more slowly, and the more stakeholders there are, the greater the risk of the project falling through. Bezos' stipulation that teams communicate through interfaces was a stroke of genius. This created a standard which allowed teams to self serve. I agree that teams must collaborate to go farther. One team can only do so much. Management should make sure all the teams stay aligned and hold them all accountable, but the teams themselves should still strive to be independent. It sounds like what your organization needed was a project manager to co-ordinate or a forum for the teams to share information.

hanifbbz 3y ago

Good summary of the book.

marsven_422 3y ago

[dead]

nologic01 3y ago

I find all such literature vague and hard to parse. The channels used to convey information are typically verbal descriptions and diagrams. It is never clear what exactly is meant by a topology, whether the description is covering all important aspects and, importantly, how we could recognize and have some assurance about the "optimality" of a pattern and why there isn't a better one just nearby. More formal descriptions are not necessarily the solution. They would need to be both concise and faithful to the system being modelled.

elliotec 3y ago
Have you read the book? Topology has a definition. It doesn’t mean anything different in this context. https://en.m.wikipedia.org/wiki/Topology https://en.m.wikipedia.org/wiki/Topology It seems like you’re just not willing to put in the effort of understanding the basics. Which would be fine if you didn’t plan on giving a review of the complexities.
- nologic01 3y ago
  > Have you read the book? The comment was based on reading the review. I assume the review covers all essential contributions of the book and it is not merely a promotion piece. I would be more inclined to take your "advice" if you had made any effort to address my concerns / observations. I suspect you simply can't. > Topology has a definition. It doesn’t mean anything different in this context. Thanks for the gratuitous and patronizing arrogance. It further reinforces my sense that these pompous sounding vacuities are a marketing tool and have no intrinsic applicability.
- gilleain 3y ago
  It means properties of teams that are preserved under continuous deformations? Or does it just mean 'some structure over a set'? That could really cover anything ... While it is certainly useful to consider how you structure your teams, using the term 'topology' seems like marketing gloss. Also alliteration, of course.

vasco 3y ago

The book was good and when I read it, it was helpful as it came out just as I was going from manager of a team to having to split that team and take over a few more in a group. Plus Manuel, one of the authors is a really friendly guy that pushed the Lisbon tech meetup scene forward around 10 years ago when nobody was having any regular local meetups and he was traveling between Spain and Portugal on the regular to make them happen (or so I remember). I presented my first proper talk in one of his meetups and I remember that going well and giving me a lot of confidence for other things later on. Definitely read it if you need to think about groups of teams!

pvdoom 3y ago

I love team topologies, it's really good. My one problem with it is that it kind of stops at the level of structuring a team and doesn't do much about the higher level of management of the organisation. Which needs a deep look just as much as how you structure your teams and if you have platform teams and whatnot. Hell, you could argue that the main reason why agile failed, was that it never addressed how to challenge and change upper-ish management. But its understandable, cause that shit is hard, its political, and its difficult with the current feudal entities that companies are

tsimionescu 3y ago

As someone who used to be part of a platform team, and is now actively working in the same organization to fight the creation of any more platform teams, I very much disagree with the article that this is a good working model. What we have found is that platform teams are a huge point of frustration for product teams, since they cause unnecessary and unmanageable coupling between different business divisions, leading to impossible to balance priorities. What we've seen happen over and over is that product A needs Feature A, and product B needs Feature B, and they both need it tomorrow, and the platform team only has resources for one. And since Product A and Product B are in different business divisions, you end up needing to involve a senior VP or even an officer to make a prioritization decision for a simple software feature, and everyone gets frustrated by the process. What we're striving towards instead is an "inner source" model, where a platform is collaboratively developped and maintained by multiple product teams. Each product team is then empowered to build new features as needed into the platform, and others can reuse them. Of course, the platform needs some architects and overall review, and all teams will not equally participate. But the key point is to encourage this collaboration mode, where no one team is a bottleneck for multiple products. The inspiration for this structure is obviously the open-source world, where multiple corporations and foundations collaborate on a single code base without needing to rely on a single platform vendor to provide features for them.

elliotec 3y ago
This is good insight and matches with my experience. As a product-focused engineer/manager, it’s too often I’ve found my teams giving up and taking into our own hands what “should be” owned by platform teams, while they work on things nobody seems to see value in.
CraigJPerry 3y ago
This sounds like fundamentally a business problem (we have finite resource, is product A or B our priority?) and trying to solve it with choices in the technology division. Well, here be dragons. Based on my experiences, the idea that a genuine bottleneck in tech is being made visible to customer division management and senior management, is generally an authentic way to ensure realism creeps back into the prioritisation and funding processes.

Foobar8568 3y ago

Platform teams mean that you ended up with a bare minimum of 5 different teams, not including deployment and support to transfer a file from a folder to another one in an automatic way. My current pain.

quickthrower2 3y ago
But that file is transferred in a SOC2 Type2 compliant way at least :-)
lightbendover 3y ago
If you only have a few teams in your company/organization, then you are not at a scale that necessitates a platform team and this discussion isn't for you. When dozens of teams need a shared capability (e.g. for ad serving across many verticals at a FAANG), then you absolutely need one or more.
- rqtwteye 3y ago
  Who actually is at that scale? Not many. For everybody else you create a lot of complexity for no benefit.
  - lightbendover 3y ago
    I'll be the first to agree that most orgs do not need a platform team.
- Foobar8568 3y ago
  Oh really? One team for managing IAM, one team per S3, one team for file process automation, one team for process management, one team handling the producer process, one team handling the consuming process, same for application on both side, the client who actually need the request +everything else. One team for a shared platform where it makes sense, sure, but everywhere, like it's some factory chain is the biggest waste of productivity.
  - 3y ago

AJRF 3y ago

I've found over the years that Martin Fowler blogs about things the C-Suite is already doing at their companies, and they use this as validation for their choices. This in turn has a virtuous cycle of keeping him popular. Almost everything he hawks causes misery for software developers, like his whole multi-year spin for Microservices, he's turned refactoring into a fetish (honestly there are people at my dayjob who have been "refactoring" the entire 3 years i've been here) and now hes blogged multiple times about platform teams - which - having been on one - don't work. I see him as a very damaging character. Well intentioned, i'm sure, but I don't think he has good ideas.

disgruntledphd2 3y ago
> he's turned refactoring into a fetish (honestly there are people at my dayjob who have been "refactoring" the entire 3 years i've been here) That's kinda dumb, but the book is super good, I learned a whole lot from it, and apply the principles basically all the time. He's been banging the drum on testing for longer, and that makes up for a lot of craziness (I'm with you on microservcies, except where you have 1k+ developers where they might make sense).
Lutger 3y ago
Working for 3 years and only refactoring, that's a whole new level of comedy. If you blame Fowler for this madness, then I see how you think his work is damaging. But its a bit like a health influencer telling people to stay hydrated and blame him for his fans damaging themselves by trying to drink 10 liters a day.
- c-hendricks 3y ago
  Funny you should mention health influencers, as they're also prone to blanket suggestions without taking their audiences needs into account.
  - ourmandave 3y ago
    Sometimes they can work, like "stop doing tik-tok challenges."

mattmcknight 3y ago

I read this book last year and saw a few good ideas. However, it seems to largely be describing enterprise software, and not, say, companies developing a SaaS product. These are different enough that the same organizational constructs don't apply to both. The one takeaway that I stick with from the stream-aligned teams is that we need teams that can build a capability from front to back independently. I think the industry has taken a step backward with huge single page web applications that end up with microservice teams building back end services, but then a monolith on the front end that isn't as modular as a web app where you can simply link to another application. I don't know if microfrontends is the right answer, but a collection of mini-monoliths with shared data services seems to work well enough.

bob1029 3y ago

This seems too complicated to me. I've been trying to wrangle not even 20 team members without much success so maybe I am not an expert in these matters. BUT, I would say for certain that whatever Mr. Fowler is proposing here absolutely would crash into the rocks at our org. This is make-work orgchart fantasy IMO. I would also add that his suggestions around micro services did us absolutely no favors.

phamilton 3y ago

This is a solid book, but there's one concept in it that has drastically changed how I lead and collaborate across teams. The book describes 3 types of problems/areas: simple, complicated, and complex. The definitions of simple/complicated/complex has shifted for me a bit since I read it, but this is how I currently describe it: Simple - the solution is clear and is fairly low risk Complicated - the problem is well framed, but the solution isn't clear Complex - the problem itself isn't really clear This 3 tiered framing lends itself to so many useful structures and interactions. Junior/Senior/Staff scope of responsibility fits remarkably well. Sprint planning / Quarterly planning / Executive planning fits. The biggest thing it has helped with is recognizing that a team needs space to explore complex problems. Those teams need to operate very differently from a standard product stream team and recognizing that need is such an important thing.

hliyan 3y ago

My problem with Fowler is his tendency to reduce complex problems into concepts that can be represented in simple, abstract models/diagrams with weak analogies (e.g. the "streams" here, test pyramids, microservices, various bits of Agile), which are enthusiastically consumed by both inexperienced engineers and decision makers in management: a deadly combination. When much of the industry adopts these ideas, and the resulting inefficiencies become the baseline, it is virtually impossible for anyone to effectively detect those inefficiencies. It becomes a "is everyone crazy, or am I crazy?" situation, until some sort of disruption (e.g. widespread project/startup failures) forces the industry to paradigm shift back to sanity.