I've been thinking about the idea of platform team...
# platform-culture
o
I've been thinking about the idea of platform team locality in larger companies. For example at Sam's Club/Walmart, we have teams that build tooling for all technology teams across multiple orgs, CI/CD automation, managed kubernes clusters, databases and messaging queues as services, etc. All at massive scale. We also have teams that own infrastructure specific a business vertical. Like a particularly unique k8s implementation. I have been leading a team that has done platform engineering with 3-5 closely related teams as our customers. These teams have shared tech stacks and often exchange developers and QA. Our team is drawn from those teams and has been doing migrations, performance testing, owning shared components and automation, implementation of platform changes from the global platform teams and coordinating architectural decisions between teams. Stuff that requires close collaboration with app teams and understanding of their specific problems and codebases. I've started to think of these strata as Global, Regional and Local platform engineering. Anyone else see this kind of pattern emerge in their orgs? Is it written about anywhere? Thanks!
h
Not sure if it gets that specific but Adobe,intuit and ING have some videos about their platforms and how some of their teams are organized
j
We are attempting to go in the other direction. To engage with "reference customers" (representative teams from the overall organization) in order to improve the overall product offering (internal developer platform et al), and how to best make use of it. Main reason is that the promise of platform engineering is challenging to achieve without a fair amount of standardization (to reap economics of scale). Also mindful of the 80/20 rule, attempting to channel central efforts towards the 80% as much as possible
The "local platform engineering" reads more like an SRE approach?
o
The primary use case for local platform teams in our org has been migrations. In order to replatform workloads, you really have to have a pretty intimate understanding of the software being migrated, the new platform and the old platform. It's a full-time job, particularly if you're trying to perform the migration in such a way that development can continue on the target software during the migration. A platform team drawn from engineers that have worked on target applications can excel at this.
c
@Oakley Hall check out Adam Schaefer’s talk about “the 3rd economy” (of scope) - it sounds like you’re putting your finger on the need for the “connective tissue”. Specifically Schaefer introduces a really useful concept of “recommoning” https://digital.gov/event/2020/08/04/continuous-devops-dilemma-with-andrew-clay/ ^^ not a fully baked framework you can just plug and chug, but i think his way of framing this problem might resonate with you.
^^ concretely I think this mental model might help clarify and frame where a team fits in the stack, and (consequently) what outcomes that team should be optimizing for. Also wardley mapping would be helpful when it comes time to “land the plane” and decide where one team will end and other teams will begin https://learnwardleymapping.com/ In summary, when I read your above description I think the “global” platform teams should be optimizing for scale and providing whatever interfaces the N “local” platform teams need to maximize the scope of “stream aligned” teams that can leverage those economies of scale.
o
This is great stuff. Thank you @Cruise Hall