Two platform teams can buy the same product, follow the same docs, and still want completely different things from it. Knowing which kind you are decides whether the platform works for you.
Part 1 of 6 in the Aiden for InfraOps series. Start with the series overview »
The short version
If you've spent any time selling to, buying for, or working on a platform team, you've probably noticed the term hides a lot of variation. "DevOps team" and "platform team" get used as if they describe one job. They don't. We've found it's more useful to think about platform teams as falling into two camps with different goals, different definitions of success, and different ideas about who should touch infrastructure.
We call them the Enabler and the Accelerator. The distinction sounds academic until you watch two teams adopt the same platform and pull it in opposite directions. This post lays out both, where most teams actually sit, and the one design decision that matters regardless of which side you're on.
The split comes down to a single question: do you want developers provisioning their own infrastructure, or do you want to keep that in the platform team's hands and just do it faster?
Enablers want out of the request queue. Accelerators want the queue to move quicker. Both are reasonable answers. They lead to very different products.
Here's the part worth sitting with: a platform built well for one archetype can feel wrong to the other. An Enabler handed a faster ticketing workflow will ask why developers still can't self-serve. An Accelerator handed a self-service catalog will worry about losing control. Before you evaluate any tooling, it's worth knowing which problem you're actually trying to solve.
The Enabler's goal is to make developers self-sufficient without making them dangerous. They want to move from being a blocker to being a provider. The developer is the end user, and success looks like developer velocity plus organization-wide compliance.
The problems an Enabler is fighting are familiar: developers spinning up non-compliant or insecure infrastructure, the same manual setup repeated for every new app, and no real way to enforce best practices once you're past a handful of teams.
An Enabler's workflow is about building the things developers will consume:
The mental model is a producer running an internal platform. They build the guardrails; developers build inside them.
The Accelerator wants none of that. This team is explicitly not interested in handing self-service to developers. Their goal is to speed up their own work and clear requests faster, and for them the DevOps engineer stays the primary user of the platform.
Often these are smaller or more junior teams drowning in repetitive asks. "I need a new database." "Provision a bucket." The grunt work is manual and error-prone, and it eats time that should go to higher-value platform work. They don't want to give up control. They want the tickets to resolve faster.
For this team the value is an automated assist on the work they already do:
A fair caveat: some of this is where the product is heading rather than fully shipped today. If you're an Accelerator evaluating a platform, ask specifically what's live versus roadmap before you bank on a workflow.
Treating these as two tidy boxes is a simplification, and we'd rather say so than pretend otherwise. Plenty of platform teams sit on a continuum between the two. They might self-serve the routine stuff, like a standard web app, while keeping anything that touches networking or data in the ticket queue. The archetypes are a way to reason about intent, not a personality test with two outcomes.
What's useful is asking where your team leans right now, and where you want it to lean in a year. Those are often different answers, and the gap is the actual work.
Here's where the two camps converge. Whether you want full self-service or faster tickets, the change that unlocks the platform is the same one: a clean separation between the people who create infrastructure and the people who consume it.
For the Enabler, that separation is the whole point. Platform engineers produce hardened modules and templates; developers consume them on a canvas without writing arbitrary config. For the Accelerator, the separation is quieter but still there. The AI drafts, the engineer approves. Creator and consumer stay distinct even when both are technically on the platform team.
Most of the confusion we see, and most of the wasted platform investment, traces back to teams that never drew that line. When everyone can edit everything, governance becomes a code review bottleneck and self-service becomes a liability. Drawing the creator-consumer boundary is what makes either archetype's model hold up at scale. (We dig into that split in Modules vs. appStacks: The Producer-Consumer Split.)
If you're choosing or building a platform, start by naming your archetype out loud. An Enabler should weigh how good the self-service consumption experience is: can a developer build something real without a ticket, and are the guardrails strong enough that you'll actually let them? An Accelerator should weigh how much an automated workflow genuinely shortens the path from request to merged PR, and how trustworthy the review step is.
Both should ask the harder question underneath: have we separated who builds infrastructure from who uses it? Get that right and the rest of the platform decisions get easier. Skip it and no amount of tooling will save you from the chaos of unmanaged infrastructure.
At StackGen, we built Aiden for InfraOps for both archetypes deliberately, because most real teams aren't purely one or the other. If you're not sure where you land, that's a good first conversation to have. The companion post The Force Multiplier: How a Two-Person Platform Team Supports 1,000 Developers is a good next read.
Next — Part 2: The Force Multiplier: How Two Engineers Support a Thousand Developers →
See all six parts in the series overview »