4 ms·
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?
by 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 agoThey share characteristics (ie the "advanced knowledge" aspect), but differ in how these are applied: they deliver and maintain their own systems.
- saled 3y agoThe 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 agoThe "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 agoEnabling 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 agoYou 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 agoI 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.