This message was deleted.

Great question @Edoardo Causarano, looking forward to the replies. I wrote an article on platform teams and incorporating internal user feedback into the platform roadmap a while back, might be a good starting point 👉 https://humanitec.com/blog/internal-platform-teams-what-are-they-and-do-you-need-one

I think there's a tendency to build internal platforms which solve all sorts of non functional requirements at the expense of giving app developers an unfamiliar development experience, and then being seen as a bottleneck, or set of hoops to jump though. This is exacerbated in today's hiring market where people simply don't have time to learn the ins and outs of an in-house system, with an average tenure of 3 years If you don't let dev teams go off-piste, then you become a gatekeeper. Also your new platform doesnt cover existing applications (so every team with an app they are proud of gets branded as " legacy"), it doesn't cover the code from any companies your company has bought, and doesn't cover tactical project solutions built using standard cloud tools. What I've often thought should go hand in hand with a platform, or maybe before it, is a capability to automatically catalogue your project estate, and analyse it for conformance to NFRs, and publish that back to the owners. Only when armed with that information will some teams see the advantages of using the platform over rolling things themselves. Also this system let's you shift-left your ADRs and standards. It reminds me a a bit of red green refactor. Green is building an in house platform, red is building an standards conformance measurement tooling.

This is why I think it’s exceedingly important to build on top of reasonably standardized platforms such as Kubernetes. It allows you to give out full functionality to the devs while still being platform-agnostic (works on self-hosted, aws, gcp, etc) and allows for simplifying things through Operators and templating.