To me it seems like the “complicated-subsystem” and the “platform” team types are simply Subtypes of the “enabling” team type. Anyone else see the same thing?
The Enabler team type is outward looking, evaluating and bringing new tech and concepts into the business and training other teams. They will collaborate with other teams often in order to help train and transfer knowledge.
This is different to platform teams which are meant to mostly build internal services which other teams use with self service, meaning they don't directly interact with members of the platform team (allowing both teams to operate independently). That said, platform teams may occasionally collaborate with steam aligned teams when building out new features or to better understand the problems the stream aligned teams are having.
The "complicated-subsystem" is a part of the shipped software, it is there to deliver value to the users of the software.
The "platform" is there to allow teams to ship software. It is there to deliver value to other teams.
I think this second one is what is meant by "enabling" i.e. it's not "delivering value to the users", rather, enabling other teams to do better at that.
from the article: "A platform team enables a stream-aligned team to deliver work"
Enabling teams can go work with other teams to "enable" them to be more effective. Think teams of specialists in skills that more teams need than you have specialists to go around, and who also benefit from the strong community of practice & extending state of the art with other specialists. e.g. Product security engineers. Enabling teams will work with all the other team types.
Complicated subsystem teams mostly work with value stream teams on a subset of a value "stream" that is complicated enough / specialised enough to need its own team of specialists, especially when it can be encapsulated in a library or service. e.g. owning an ML component within some software.
Platform Teams build an internal product and act like a value stream team where other internal teams are customers. Often useful for things that you wish you could buy off the shelf from a cloud vendor but can't. Building services and tooling that make the stream aligned and complicated subsystem teams more effective. Sometimes platform teams may need to act like enabling teams at times / with part of their effort to help other teams adopt their product.
You could also make the argument that both “complicated-subsystem” and "platform" teams, are just another "stream-aligned" team whose primary clients are internal to the company.
Overall this post just seems like a great way to see who can win the "most pedantic" award in a management meeting.
> You could also make the argument that both “complicated-subsystem” and "platform" teams, are just another "stream-aligned" team whose primary clients are internal to the company.
That seems overly generic. There are clear, useful differences between teams that need to hit marketing goals or interview/support customers in production, than teams that run your internal GitLab instance.
I came to a similar conclusion after reading this article. There might or might not be nuances, but going by this post alone, there are so many ways to reshuffle and interpret these types it could just be bullshit.
I have happily lurked here for years, but upon seeing Team Topologies mentioned I felt an overwhelming urge to create an account, if only to give a strong negative review.
I was a part of an organization that implemented this book's recommendations, and it did not go well.
We had high performing teams that worked well together and all shared roughly equal responsibility for tech, features, oncall, and tech debt. The organization wasn't perfect -- we had scaled down the org for covid, only to be surprisingly successful (a great problem to have) which was brutal on us engineers and we incurred a ton of tech debt. And we had the standard issues with some collaboration and some politics.
Then someone was brought in who applied the concepts in this book, and it went very poorly. Suddenly we were shuffled into teams that weren't much larger but had huge areas of responsibility. In addition to the tech debt we already had, the breadth of our responsibility was expanded drastically. For example, instead of having one team responsible for kakfa, now 3 teams all owned slices of it, but in a way that we each had to become experts in order to satisfy our oncall obligations (I'm oversimplifying, but hopefully you get the point). Multiply that by 3-5 serious backend systems for each team, and you can hopefully appreciate the high cognitive load we were under.
To make matters worse, most of the teams doing the heavy lifting were now "product teams" which had UI ("fullstack") people thrown onto them, but those teams now owned 92% distributed backend tech, and 8% user interface. Almost all of the fullstack people had a great attitude about it and learned as fast as they could but it did not go well. I was effectively oncall 24/7 from that point.
Also the oncall burden and areas of responsibility were unbalanced between teams. Two teams bascially ended up with the most fragile, unstable systems with the highest oncall burden while others had almost exclusively brand new things that did not yet have serious flaws.
And then, to twist the knife, while we are drowning in our own tech debt and heterogenous team structure, there began a pattern of reducing our autonomy. Important decisions, or strategies, like how we test our software, or how we deploy, we suddenly being dictated by other teams full of recently hired junior engineers who knew less about these things than the staff engineers did, especially since they lacked the tribal knowledge we had built up (and still had not managed to offload onto our own teams!).
I gave some careful feedback about the most obvious problems to the director who seemed responsible for implementing all this, and she brushed off my concerns. That was weird, but made sense when I later learned she was implementing the concepts in Team Topologies. The teams had ridiculously large areas of responsibility because we were the feature teams ("stream-aligned" in Team Topologies b.s.) and we were supposed to crank out features without talking to other teams. That is also why some teams had practically no on call burden and others' on call rotations were full of sev 1s: when your ownership is based on features, some teams will own the one of the newer features that doesn't have tech debt, race conditions, or scaling issues yet, and other teams will end up with the older features, which we could barely keep online.
And the teams full of idiots bossing us around? Well those were the "enabling teams." This was especially bad on the infrastructure side, because these engineers would only talk about the way a perfect system should work, and refused to acknowledge any reality of the existing system. For example, we had a rather homegrown EC2-based autoscaling infrastructure with what I would call a "bespoke" service discovery implementation. The k8s-enabler assigned to one project insisted that k8s+consul was the answer, and the only answer. When I asked how that would work with the existing system in...
> Another thing they did was disband the regular meetings of all of the senior engineers, and even told us to stop collaborating with each other a few times. I'm not 100% sure I can pin this one on Team Topologies, although it the book does promote the idea of trying to control communication between teams.
Someone at your company got a mandate to change the culture, and with such a mandate power gets shuffled around. The power was taken away from engineering teams that needed it.
I wouldn't say they were doing it wrong, just two things were happening simultaneously and the politics of power weren't paid attention to.
I read team topologies and found it to lack any novel insight but given its popularity I just took it as a presentation of the current jargon. It presents a sort of model for thinking about the organizational structures that you may already see popping up. Depending on your organization, you may end up with a unit of DBAs, the original enabling team. If they are doing their job well then they ignore the teams that have services with ordinary database usage and spend a lot of time helping teams with heavy db reliance optimize their usage. If they are pathological, they claim ownership of the entirety of database usage over an organization and everybody suffers. If a stream aligned team has to ask permission to do anything with a db, with a message broker, with a queue, with firewalls, with deployment, with testing, then congratulations, you built multiple walls of confusion. Enabling doesn't mean dictation. And as pointed out by others here, the lines between the enabling team, the complicated subsystem and the platform teams are not bright, they are blurry lines.
Team topologies are somewhat orthogonal to power topologies. Every organizational structure can be subverted to take power away from those that need it.
My experience of DBA teams (at a bank) was that they were desperately slow at approving anything (and all changes had to be approved by DBAs).
We had a DB query in the software for the Fraud Department that was very slow - it was taking several minutes to run, leading the fraud team to take frequent coffee breaks. I added an index to the schema, which led to a 1000x improvement in performance. It took 4 months for the DBAs to approve putting it into production.
Sure: adding an index could have hit performance in some other system; and the index was on the main Customer table. The change did need wider testing than I could do myself. But 4 months? That's not an "enabling" team, that's an "obstructing" team.
If you take 4 months to approve a change of mine beacuse you need to "test it" you'd better be prepared to explain how any issues that might crop up got past 500+ man hours of testing.
Right, so your experience was that the dba team wasn't an enabling team but instead a complicated subsystem team. I would argue, and you seem to agree, that streams need to own their own database, some dbas don't want that and they get caught up performing all the toil on the databases instead of solving just the interesting problems that require their skillset. Yes, these things happen. You should be calling the dbas in (for example) when you need help configuring autovacuums because you have so much load on the db during ordinary operations that a poorly timed autovacuum can cause massive service disruption. Inevitably, some banks will come to view their accounting database as a complicated subsystem in and of itself possibly to the chagrin of the accounting application engineers.
A DBA performing execution of an index migration is usually not a good use of their expertise.
Yeah. But no vacuums; this was Oracle (I think) 7 or 8. The database I was messing with was THE corporate database; and the table I wanted a new index on was THE Customer table. They had every right, even responsibility, to make sure I hadn't broken some other system.
But they were so SLOOW. My suspicion is that they didn't like it that someone who wasn't in the DBA club had found an improvement to their schema. They definitely had a walled and moated fortress.
Enjoyed your candid perspective. Living through some of what you had written and it is an absolute nightmare. Thank you for sharing this, knowing that we're not alone is giving me some hope.
> And the teams full of idiots bossing us around? Well those were the "enabling teams." This was especially bad on the infrastructure side, because these engineers would only talk about the way a perfect system should work, and refused to acknowledge any reality of the existing system.
Oh boy, this sounds all too familiar. And yet, from the OP:
> Enabling teams must avoid becoming an “ivory tower” of knowledge.
In my experience, these types of teams are sucked in to ivory tower thinking precisely because they are so far removed from the existing system. And yet, the article glances over this problem.
Great perspective, you made me realise that this is the team topology my department implemented.
It does explain why communication between team is non existent.
As an eng manager (and coder / principal, depending on what the need is) this sounds like poor management that hit a catalyst in the form of this applied methodology.
Anyone changing an org / team structure without doing an in-depth study consulting the teams involved is asking for trouble. The aim of the preliminary steps is to find the "no way will that work" opinions and take them seriously.
I am fed up of people getting paid to blindly apply these methodologies with next to no appreciation for the complexity, hidden or visible, that exists in most orgs.
Evolution is better than revolution for 99% of things in my experience. Add lightness is usually the way forward.
SCRUM, Agile (capital A), PRINCE2, TDD, BDD, [list any methodology at any slice of the org] all suffer from misapplication by hacks selling snake oil.
Sadly "it's complicated, there's no one-size fits all, and no easy answers" doesn't seem to sell books or get people hired; even when it is true.
> For example, instead of having one team responsible for kakfa, now 3 teams all owned slices of it, but in a way that we each had to become experts in order to satisfy our oncall obligations (I'm oversimplifying, but hopefully you get the point). Multiply that by 3-5 serious backend systems for each team, and you can hopefully appreciate the high cognitive load we were under.
I don't understand how you'd get this from Team Topologies, though. Not even slightly. I don't think this is an easy misinterpretation; there's literally a team type describing the way you used to do it.
Does sound rightfully terrible. It's exceptionally common cognitive mistake to discover a categorization (of people) and take it as prescriptive rather than descriptive. Especially in corporate business context.
Have not read the book, but the Four Teams list obviously describe real roles. But that doesn't mean organization must or should go out and immeiately partition their teams according this scheme. The value is to recognize that these roles exist and are probably performed somewhere by someone in some way or another in the organization. (But perhaps your org is too small to have much of Platform component, say, so it's just Alice who update CI every N week on as-needed basis.) And to use that knowledge to understand the overall process and where there may be problems or future problems.
> As the organization continues to grow and these team types continue to sprawl, it becomes increasingly hard to visualize the full organizational landscape, and, consequently, to get things done.
The premise is true, but the conclusion is a recipe for disaster.
As organizations grow, they tend to have more managers, teams, departments, and procedures. However, adding more layers to this complexity is not going to solve any issue. In fact, it will only make things mentioned above worse.
A short list of maxims from an organization which depends on high-performance human teams, US Special Operations Forces, https://www.socom.mil/about/sof-truths
Humans are more important than hardware
Quality is better than quantity
Special Operations Forces cannot be mass produced
Competent Special Operations Forces cannot be created after emergencies occur
Most special operations require non-SOF support
A "boot" is US Marine who has recently completed basic training (commonly called "boot camp"). It's a multi-use term and not a simple insult (but it's never a positive statement).
Here’s one point I find helpful (particularly if you’re a director-level thinking of restructuring this way.) If you don’t have the utmost confidence that your entry-level managers can hire/have hired a balance of people to effectively take on the responsibilities of a stream-enabled team, you’re not ready to work this way.
A team of backend specialists will really struggle if they are suddenly given complex frontend work, and vice-versa. Plus, if you typically have teams of -4 engineers, that means that even one person being out can be catastrophic to your team’s balance. Or if you pick up a project that suddenly increases a specialist burden, you have to find the right enablement team or move people around the org. Expect that to happen often (perhaps even quarterly?) depending on your stream and product team.
You can also hire fullstack, but beware that they need to be truly fullstack in a way that is really rare. It will probably require a bigger salary commitment across your teams.
Another risk is that your platform teams need to be super good at identifying each stream team’s roadmap. If the way aren’t and your product team doesn’t naturally identify overlapping features as areas for technical communication, the platform team needs to fill that gap. And you need 1 platform team that will identify each gap, so a platform team that can’t identify when two web apps can share componentry likely implies the need for a platform team who can. There will be a lot on their plates!
37 comments
[ 3.3 ms ] story [ 88.5 ms ] threadThis is different to platform teams which are meant to mostly build internal services which other teams use with self service, meaning they don't directly interact with members of the platform team (allowing both teams to operate independently). That said, platform teams may occasionally collaborate with steam aligned teams when building out new features or to better understand the problems the stream aligned teams are having.
The "platform" is there to allow teams to ship software. It is there to deliver value to other teams.
I think this second one is what is meant by "enabling" i.e. it's not "delivering value to the users", rather, enabling other teams to do better at that.
from the article: "A platform team enables a stream-aligned team to deliver work"
Complicated subsystem teams mostly work with value stream teams on a subset of a value "stream" that is complicated enough / specialised enough to need its own team of specialists, especially when it can be encapsulated in a library or service. e.g. owning an ML component within some software.
Platform Teams build an internal product and act like a value stream team where other internal teams are customers. Often useful for things that you wish you could buy off the shelf from a cloud vendor but can't. Building services and tooling that make the stream aligned and complicated subsystem teams more effective. Sometimes platform teams may need to act like enabling teams at times / with part of their effort to help other teams adopt their product.
Overall this post just seems like a great way to see who can win the "most pedantic" award in a management meeting.
That seems overly generic. There are clear, useful differences between teams that need to hit marketing goals or interview/support customers in production, than teams that run your internal GitLab instance.
Just look at my sibling responses.
I was a part of an organization that implemented this book's recommendations, and it did not go well.
We had high performing teams that worked well together and all shared roughly equal responsibility for tech, features, oncall, and tech debt. The organization wasn't perfect -- we had scaled down the org for covid, only to be surprisingly successful (a great problem to have) which was brutal on us engineers and we incurred a ton of tech debt. And we had the standard issues with some collaboration and some politics.
Then someone was brought in who applied the concepts in this book, and it went very poorly. Suddenly we were shuffled into teams that weren't much larger but had huge areas of responsibility. In addition to the tech debt we already had, the breadth of our responsibility was expanded drastically. For example, instead of having one team responsible for kakfa, now 3 teams all owned slices of it, but in a way that we each had to become experts in order to satisfy our oncall obligations (I'm oversimplifying, but hopefully you get the point). Multiply that by 3-5 serious backend systems for each team, and you can hopefully appreciate the high cognitive load we were under.
To make matters worse, most of the teams doing the heavy lifting were now "product teams" which had UI ("fullstack") people thrown onto them, but those teams now owned 92% distributed backend tech, and 8% user interface. Almost all of the fullstack people had a great attitude about it and learned as fast as they could but it did not go well. I was effectively oncall 24/7 from that point.
Also the oncall burden and areas of responsibility were unbalanced between teams. Two teams bascially ended up with the most fragile, unstable systems with the highest oncall burden while others had almost exclusively brand new things that did not yet have serious flaws.
And then, to twist the knife, while we are drowning in our own tech debt and heterogenous team structure, there began a pattern of reducing our autonomy. Important decisions, or strategies, like how we test our software, or how we deploy, we suddenly being dictated by other teams full of recently hired junior engineers who knew less about these things than the staff engineers did, especially since they lacked the tribal knowledge we had built up (and still had not managed to offload onto our own teams!).
I gave some careful feedback about the most obvious problems to the director who seemed responsible for implementing all this, and she brushed off my concerns. That was weird, but made sense when I later learned she was implementing the concepts in Team Topologies. The teams had ridiculously large areas of responsibility because we were the feature teams ("stream-aligned" in Team Topologies b.s.) and we were supposed to crank out features without talking to other teams. That is also why some teams had practically no on call burden and others' on call rotations were full of sev 1s: when your ownership is based on features, some teams will own the one of the newer features that doesn't have tech debt, race conditions, or scaling issues yet, and other teams will end up with the older features, which we could barely keep online.
And the teams full of idiots bossing us around? Well those were the "enabling teams." This was especially bad on the infrastructure side, because these engineers would only talk about the way a perfect system should work, and refused to acknowledge any reality of the existing system. For example, we had a rather homegrown EC2-based autoscaling infrastructure with what I would call a "bespoke" service discovery implementation. The k8s-enabler assigned to one project insisted that k8s+consul was the answer, and the only answer. When I asked how that would work with the existing system in...
Someone at your company got a mandate to change the culture, and with such a mandate power gets shuffled around. The power was taken away from engineering teams that needed it.
I wouldn't say they were doing it wrong, just two things were happening simultaneously and the politics of power weren't paid attention to.
I read team topologies and found it to lack any novel insight but given its popularity I just took it as a presentation of the current jargon. It presents a sort of model for thinking about the organizational structures that you may already see popping up. Depending on your organization, you may end up with a unit of DBAs, the original enabling team. If they are doing their job well then they ignore the teams that have services with ordinary database usage and spend a lot of time helping teams with heavy db reliance optimize their usage. If they are pathological, they claim ownership of the entirety of database usage over an organization and everybody suffers. If a stream aligned team has to ask permission to do anything with a db, with a message broker, with a queue, with firewalls, with deployment, with testing, then congratulations, you built multiple walls of confusion. Enabling doesn't mean dictation. And as pointed out by others here, the lines between the enabling team, the complicated subsystem and the platform teams are not bright, they are blurry lines.
Team topologies are somewhat orthogonal to power topologies. Every organizational structure can be subverted to take power away from those that need it.
My experience of DBA teams (at a bank) was that they were desperately slow at approving anything (and all changes had to be approved by DBAs).
We had a DB query in the software for the Fraud Department that was very slow - it was taking several minutes to run, leading the fraud team to take frequent coffee breaks. I added an index to the schema, which led to a 1000x improvement in performance. It took 4 months for the DBAs to approve putting it into production.
Sure: adding an index could have hit performance in some other system; and the index was on the main Customer table. The change did need wider testing than I could do myself. But 4 months? That's not an "enabling" team, that's an "obstructing" team.
A DBA performing execution of an index migration is usually not a good use of their expertise.
But they were so SLOOW. My suspicion is that they didn't like it that someone who wasn't in the DBA club had found an improvement to their schema. They definitely had a walled and moated fortress.
This is a great summary.
Oh boy, this sounds all too familiar. And yet, from the OP:
> Enabling teams must avoid becoming an “ivory tower” of knowledge.
In my experience, these types of teams are sucked in to ivory tower thinking precisely because they are so far removed from the existing system. And yet, the article glances over this problem.
I definitely need to read this book
Anyone changing an org / team structure without doing an in-depth study consulting the teams involved is asking for trouble. The aim of the preliminary steps is to find the "no way will that work" opinions and take them seriously.
I am fed up of people getting paid to blindly apply these methodologies with next to no appreciation for the complexity, hidden or visible, that exists in most orgs.
Evolution is better than revolution for 99% of things in my experience. Add lightness is usually the way forward.
SCRUM, Agile (capital A), PRINCE2, TDD, BDD, [list any methodology at any slice of the org] all suffer from misapplication by hacks selling snake oil.
Sadly "it's complicated, there's no one-size fits all, and no easy answers" doesn't seem to sell books or get people hired; even when it is true.
I don't understand how you'd get this from Team Topologies, though. Not even slightly. I don't think this is an easy misinterpretation; there's literally a team type describing the way you used to do it.
Have not read the book, but the Four Teams list obviously describe real roles. But that doesn't mean organization must or should go out and immeiately partition their teams according this scheme. The value is to recognize that these roles exist and are probably performed somewhere by someone in some way or another in the organization. (But perhaps your org is too small to have much of Platform component, say, so it's just Alice who update CI every N week on as-needed basis.) And to use that knowledge to understand the overall process and where there may be problems or future problems.
The premise is true, but the conclusion is a recipe for disaster.
As organizations grow, they tend to have more managers, teams, departments, and procedures. However, adding more layers to this complexity is not going to solve any issue. In fact, it will only make things mentioned above worse.
It's like adding fire to the fire to put it off.
A team of backend specialists will really struggle if they are suddenly given complex frontend work, and vice-versa. Plus, if you typically have teams of -4 engineers, that means that even one person being out can be catastrophic to your team’s balance. Or if you pick up a project that suddenly increases a specialist burden, you have to find the right enablement team or move people around the org. Expect that to happen often (perhaps even quarterly?) depending on your stream and product team.
You can also hire fullstack, but beware that they need to be truly fullstack in a way that is really rare. It will probably require a bigger salary commitment across your teams.
Edit: It's also a misquote from the article, they refer to it as an Enabling Team.
A person being both in a Stream-Aligned Team and an Enabling Team at once would kinda turn the latter into a ”guild” in the Spotify [1] lingo.
[1] https://www.atlassian.com/agile/agile-at-scale/spotify