This message was deleted.

IMO platform teams should look to reduce the cognitive load of teams and treat the platform as a product that is evolving over time. I'd lean towards the second option and provide teams with the tools to do their jobs. As an example we run kubernetes for teams but they are responsible for building their container, helm charts, etc. We have provided a standard pipeline to build and deploy with hooks for teams to customize the pipeline for their needs. The pipeline has various feedback mechanisms to help fail a build or warn engineers if they are about to do something that might not meet our policies such as running a container as root or without resources defined

I’m with Matt on this. Of course the context is always different and theres no silver bullet here, but generally I try to avoid the antipattern where the ops/platform team becomes a bottleneck. I’m all in for removing silos and providing autonomy to the teams themselves, instead of having a single team responsible for everything you described in option 1. For example im working on a project in a platform team where we supply the k8s, cicd, gitops and similar tools as internal products. We provide devs with samples, boilerplates and documentation on how to build the helm charts, pipelines and releases. Developers know that they can ask us and we are happy to help them, but we wont be doing their work for them 😄

both cases you mention provide k8s clusters already in place, right? So you provide monitoring and scalability out of the box for developers (right?) Seems a much mature setup than ours. We currently have around 20 dev teams across 4 countries and the platform team has only 4 members and is less than a year old. I think we simply need to avoid "being a bottleneck" and develop internal tools whenever possible. We started by standarizing the platform from outside: domains, MTLS, apigateways, ... We are starting to provide templates to facilitate the work of devs but we are not building THE platform. That seems to require much more maturity. We'll see ...

Remember a platform can be as simple as a document that says use technology X, Y, and Z in this way (taken from Team Topologies). This is a great 2h training about building platform as a product: https://academy.teamtopologies.com/courses/platform-as-a-product

Ill check it out!