This message was deleted.

The idea behind Platform Engineering is to lift the burden off of the feature teams, so in general this is an anti-pattern. However, not everyone is in the right place to introduce a Platform team and there are cases where allowing feature teams to build their own platform is okay to do. This Platform Engineering adoption flowchart might help decide if it's time for an actual Platform team to take on the creation of an Internal Developer Platform. The Team Topologies book is also a great place to look at how a platform teams works and interacts with stream-aligned teams. https://octopus.com/devops/platform-engineering/when-to-adopt-platform-engineering/

There’s nothing to say you shouldnt have platform engineers in a feature team. There’s too much domagatic language around how to do platforms. Having a platform is an outcome you’re lokoing to achieve. Putting platform engineers in feature teams and having a strong technical direction setter w/ moral authority (say a founder w/ a CTO title) can achieve the outcome as well. Most people organize the way described above bc it requires WAY less leadership abilities from both executives as well as technical leaders

I agree with Andrew. There may be a few danger signs to watch out for if you end up with a single platform engineer on a stream-aligned team (single point of failure, divergent platforms for different teams, knowledge vacuums, overload, etc). If there's a strong community of practice across teams, a lot of problems can be avoided without a formal team structure.

Thanks all for answers 👍🏾

I like the flowchart, but I feel like it might be missing one little step. You often end up with a Platform Engineering Team ahead of a full IDP that starts things a bit more manually, and then as it matures (and the volume of requests gets large) you end up at an IDP

That's a great observation. You can definitely build out an IDP without a dedicated platform team. We used to have cross-team communities of practice for this kind of thing, and they operated more like an open source project than an "internally facing product".