https://platformengineering.org logo
Join Slack
Powered by
Hi <@U02MTEBU53M> I really loved your talk. Every ...
# platform-blueprints
a
Hi @Manuel Pais (co-author Team Topologies) I really loved your talk. Every time that I'm reading about platform teams we end up with tons of examples more related to SRE and DevOps. But do you think that in larger organizations will be useful having another kind of platform teams that are between SRE and Stream-aligned teams? Nowadays we are facing a lot of complexity and cognitive load related to some part of our business domain. A lot of different stream-aligned teams and their value-streams rely on these business domains. We are thinking of creating platforms teams that are hiding and making it easier to share the knowledge of these business domain complexities through services and APIs for the stream-aligned teams. Do you think is a dangerous strategy or did you already see something similar in other places? We have some concerns in creating bottlenecks on these teams. Thanks!
šŸ‘ 2
m
That's a very important question and first of all it's critical that the org is aware of the potential impact on the flow of stream-aligned teams when we're trying to "help" but we end up (unwantingly) with platforms that are more blockers that helpers.
Of course, we must start by the business related platform being self-service, that's a must.
But even then, a common problem is the boundaries of the platform being too strict and defined upfront. That is a common mistake that leads to painful dependencies down the line. Maybe the abstractions are too high level for some teams, forcing them to use workarounds or frequently wait on platform teams to make changes. Or the abstraction is too low level, causing cognitive load on the stream teams.
In short, it's definitely beneficial to think about possible non-infra/SRE/DevOps platforms. You can find some really interesting examples here: https://bit.ly/3NgtKoW
I love how uSwitch evolved from an initial could infra platform to now having multiple platforms around consumer data and even marketing: https://teamtopologies.com/industry-examples/organizational-evolution-accelerating-delivery-of-comparison-services-uswitch
message has been deleted
Or how NAV, a gov org in Norway, has a design platform and a data platform on top of the Applicaton platform: https://teamtopologies.com/industry-examples/how-the-internal-technology-platform-creates-value-at-nav
message has been deleted
p
How does this related to the (in)famous "Spotify"-model? Like Tribes? Is everything you describe "inside" a tribe?
m
In my opinion, those higher level platforms are where a lot of the platform value shines.
@Paul Puschmann it's unrelated to tribes, we're not based off the Spotify model at all.
You can find the key concepts from the Team Topologies book here: https://teamtopologies.com/key-concepts
a
Thanks a lot for the info!
šŸ‘ 1
p
... šŸ¤” . Thank you, so I should do some serious reading first šŸ˜‚ . I only wondered what you would think of something like "platform" as a separate tribe.
m
Personally, I think tribes are fine if they're aligned to true domains, but dangerous if aligned to disciplines like SRE or DevOps. A tribe typically sets very strong incentives so you end up incentivizing the wrong things from a business perspective possibly.
šŸ‘ 1
A clearly defined platform could be a tribe. But there should be a clear value proposition to this platform which is aligned to the needs of the other teams and the organization's goals.
šŸ‘ 2
p
And I guess you'd recommend to have "the platform" inside of a tribe?
m
There's no silver bullet to recommend. Sometimes it makes sense for large distributed orgs to have multiple platforms that are localized per region, even if they provide similar services, for e.g.
šŸ‘ 1
Other times, it doesn't make sense to do that.
I think a sense of belonging is important, whether that's with tribes or some other construct.
p
Yes, it highly depends. Thank you so far. I'll have to think about this šŸ™‚
m
We talk about trust boundaries in the book, these are important to keep in mind when organizing platform teams as well. Having 300 people in a single "platform" group is going to cause issues of trust.
šŸ‘Œ 1
We go into more details of all this in our Platform as a Product online training: https://bit.ly/3MS88Pt
šŸ‘ 1
āž• 1
(you can use code platformcon-15off for a 15% discount)
But just to go back to @Angel Costelaā€™s initial question, it is key for any platform, but especially for business & data focused platforms to keep the boundaries of what's in and out of the platform quite fluid and evolving over time. We can use things like a team dependencies tracker to help us have leading indicators of potential issues over time: https://github.com/TeamTopologies/Team-Dependencies-Tracking
ā¤ļø 1
25 Views
Open in Slack
PreviousNext
Powered by