Where do you all think the boundaries for platform engineering lie? For instance, to what extent do you include considerations for shared functionality/software libraries that are significant to your organization? As I mentioned in my intro, I work with teams that build "Platform Concepts" the provide consistency and solve common problems within our customer-facing application suite. This includes our design system, build and deployment frameworks for our static code and orchestration layer, considerations for authn & authz, and some shared feature work like managing how async messaging (i.e. push notifications, in-app notifications, emails) is provided to users. This sort of work is not traditionally included in the high-level maps/descriptions of "Platform Engineering" - or maybe that's just the contemporary cloud-focused iteration of that.

I commonly see really high-performing organizations that have dedicated developer enablement teams. tell me more about your developer experience team. what's their scope?

We have a collection of teams that I was lumping together for brevity's sake and may not be effectively organized in the contemporary sense. The largest of the groups act as a DevOps org. There are also groups for Cloud Enablement, IaaC considerations for our significant on-prem presence, and our automated testing tool suite.

so it sounds like these groups all define "reusable libraries" / "app frameworks" as out of scope?

Yes, for the most part.

i think it's fairly common for there to be some separation of duties between teams that deliver "platform" (that i run things on) and "platform" (that i build things with). at a large telco i worked with this kind of scope fell into the developer enablement team, that were adjacent to the platform team, and whose primary focus was working with app teams and identifying areas where reuse (code, patterns) and training would help developers in the app teams spend more of their time on the differentiated parts of the app and less of their time on the undifferentiated parts of the app. • encouraging these app teams to use platform capabilities was a key part of their scope • identifying gaps that could be filled by sponsoring new "frameworks" or other reusable components was another part of their scope • finally, education and developer outreach was critical to avoid "build it and they will come" traps

That makes sense. Thanks. To your point in the first paragraph the "platform" vs "platform" differentiation definitely confuses things, though it brought me here so it's not all bad. I think there's still some significant overlap in design sensibility - "platform as a product" is equally applicable to both definitions IMO.

absolutely. a product mindset is fundamental to gaining adoption of the thing you build, and it starts with actually talking to potential users, finding something that is valuable to them, delivering it, and then iterating on the product over time

@Nate Wagar in one of our client engagement we were initially responsible for "Platform Concepts" such as distributing automation as components, deployment patterns and eventually establishing a reference architecture for cloud infra. This eventually transitioned towards fully fledged platform engineering. In result, the platform team was accountable for both initiatives (concepts, dev community and platform). The org layout looked as follows • Cloud enablement function: mostly operating at cloud landing zone and compliance layers • IT managed service team: traditional ops looking after GitHub, Vault, and other managed/self-hosted services • Platform team: doing both team enablement as well as operating the platform • Developer Experience: which emerged afterwards to focus on IDP (portal) and inter-service communication aspects, now focusing more on measuring dev productivity

Unfortunately, I fear the issue is more that teams are playing hot potato, allowing things to fall through the cracks rather than overlap in responsibility. (Though of course defining boundaries will help resolve that either way.)