6 ms·

Four Team Types

73 points by kiyanwang 3y ago

oa335 3y ago
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?
- ElFitz 3y ago
  They share characteristics (ie the "advanced knowledge" aspect), but differ in how these are applied: they deliver and maintain their own systems.
- saled 3y ago
  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.
- SideburnsOfDoom 3y ago
  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"
- benjiweber 3y ago
  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.
- flakes 3y ago
  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.
  - robertlagrant 3y ago
    > 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.
- gherkinnn 3y ago
  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. Just look at my sibling responses.
DarkVanilla 3y ago
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 prod, he explained why k8s is better than EC2 and I'd better get with the program. When I brought up the source code of what we had deployed in prod and pointed at the exact line I expected to fail, he insisted it was working. He lied. We lost three weeks. When I eventually heard about the book and read it, it make me angry to see what people in management (or that style of management) actually thought about us (there's some stuff about using teams as units to make us all fungible cogs but I'll skip that because this comment is already very long). Especially because most of the companies cited in the book were awful, boring places to work at. I sorry I can't remember any examples (other than maybe an online casino); all I remember is the case studies were all done for companies that I would never want to work at, and most of them were outside the tech sector entirely. 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. I watched the org decline for about 1.75 years before I left. That stupid ass book was not the only problem we had, and not even the biggest. But it certainly made things chaotic and unpleasant for a while. I realize that there is an obvious counter point to everything I've written -- maybe my org was just "doing it wrong." Maybe this post will get a bunch of replies saying a long the lines of "well actually, chapter X doesn't say you supposed to do Y". And I would just like to point out that if it is so easy to misinterpret this book, if our Director and VP's best efforts simply fell short of understanding the text, and the claimed success is only possible with your enlightened interpretation, well that's a problem too. If you are a staff engineer, I actually recommend reading it (hopefully in some manner that does not involve a purchase, like borrowing from someone). It can give you a useful perspective and insight into what some managers are thinking. If you are some kind of manager or director or VP, I don't know what to tell you. Managing an org is hard. I certainly don't know how to do it. But if you are learning how to do it from this book, I hope I never have to work for you.
vrnvu 3y ago
> 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. It's like adding fire to the fire to put it off.
transpute 3y ago
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 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 For software development, see HN discussions which reference Mythical Man Month (1975), https://hn.algolia.com/?query=mythical%20man%20month&type=comment&sort=byDate https://hn.algolia.com/?query=mythical%20man%20month&type=co... & the book itself (pdf): https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...
- rokob 3y ago
  SOF usually doesn’t let a boot run a team of operators the way tech companies do though.
  - hbrav 3y ago
    Boot?
    - kognate 3y ago
      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).
      - kalupa 3y ago
        "noob" is a surprisingly good substitute. Is it an insult? depends on context ...
jimberlage 3y ago
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.
- jimberlage 3y ago
  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!
- tines 3y ago
  Did you ever work at IBM by chance? I ask because it's the only place I've ever heard the word "enablement" used.
  - ozr 3y ago
    The term is spreading, unfortunately.
  - jimberlage 3y ago
    Nope! I do think I picked it up from a boss who spent time at IBM, though. Edit: It's also a misquote from the article, they refer to it as an Enabling Team.
sharas- 3y ago
This is a great simplistic scheme to sell to a typical corporate go-getter simplistifier manager. https://bitslap.it/blog/posts/playground-it.html https://bitslap.it/blog/posts/playground-it.html
- timeagain 3y ago
  This post raised my corporate cynicism levels more than any ribbonfarm post has to date.
- gherkinnn 3y ago
  This is so accurate it hurts.
s4i 3y ago
Can one person belong to multiple teams at once though? 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 https://www.atlassian.com/agile/agile-at-scale/spotify
Lucyj001 3y ago
[dead]

73 points by kiyanwang 3y ago

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?

ElFitz 3y ago
They share characteristics (ie the "advanced knowledge" aspect), but differ in how these are applied: they deliver and maintain their own systems.
saled 3y ago
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.
SideburnsOfDoom 3y ago
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"
benjiweber 3y ago
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.
flakes 3y ago
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.
- robertlagrant 3y ago
  > 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.
gherkinnn 3y ago
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. Just look at my sibling responses.

DarkVanilla 3y ago

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 prod, he explained why k8s is better than EC2 and I'd better get with the program. When I brought up the source code of what we had deployed in prod and pointed at the exact line I expected to fail, he insisted it was working. He lied. We lost three weeks. When I eventually heard about the book and read it, it make me angry to see what people in management (or that style of management) actually thought about us (there's some stuff about using teams as units to make us all fungible cogs but I'll skip that because this comment is already very long). Especially because most of the companies cited in the book were awful, boring places to work at. I sorry I can't remember any examples (other than maybe an online casino); all I remember is the case studies were all done for companies that I would never want to work at, and most of them were outside the tech sector entirely. 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. I watched the org decline for about 1.75 years before I left. That stupid ass book was not the only problem we had, and not even the biggest. But it certainly made things chaotic and unpleasant for a while. I realize that there is an obvious counter point to everything I've written -- maybe my org was just "doing it wrong." Maybe this post will get a bunch of replies saying a long the lines of "well actually, chapter X doesn't say you supposed to do Y". And I would just like to point out that if it is so easy to misinterpret this book, if our Director and VP's best efforts simply fell short of understanding the text, and the claimed success is only possible with your enlightened interpretation, well that's a problem too. If you are a staff engineer, I actually recommend reading it (hopefully in some manner that does not involve a purchase, like borrowing from someone). It can give you a useful perspective and insight into what some managers are thinking. If you are some kind of manager or director or VP, I don't know what to tell you. Managing an org is hard. I certainly don't know how to do it. But if you are learning how to do it from this book, I hope I never have to work for you.

vrnvu 3y ago

> 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. It's like adding fire to the fire to put it off.

transpute 3y ago

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 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 For software development, see HN discussions which reference Mythical Man Month (1975), https://hn.algolia.com/?query=mythical%20man%20month&type=comment&sort=byDate https://hn.algolia.com/?query=mythical%20man%20month&type=co... & the book itself (pdf): https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...

rokob 3y ago
SOF usually doesn’t let a boot run a team of operators the way tech companies do though.
- hbrav 3y ago
  Boot?
  - kognate 3y ago
    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).
    - kalupa 3y ago
      "noob" is a surprisingly good substitute. Is it an insult? depends on context ...

jimberlage 3y ago

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.

jimberlage 3y ago
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!
tines 3y ago
Did you ever work at IBM by chance? I ask because it's the only place I've ever heard the word "enablement" used.
- ozr 3y ago
  The term is spreading, unfortunately.
- jimberlage 3y ago
  Nope! I do think I picked it up from a boss who spent time at IBM, though. Edit: It's also a misquote from the article, they refer to it as an Enabling Team.

sharas- 3y ago

This is a great simplistic scheme to sell to a typical corporate go-getter simplistifier manager. https://bitslap.it/blog/posts/playground-it.html https://bitslap.it/blog/posts/playground-it.html

timeagain 3y ago
This post raised my corporate cynicism levels more than any ribbonfarm post has to date.
gherkinnn 3y ago
This is so accurate it hurts.

s4i 3y ago

Can one person belong to multiple teams at once though? 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 https://www.atlassian.com/agile/agile-at-scale/spotify

Lucyj001 3y ago

[dead]