Platform Engineering Adoption Jumped From 45% to 80% in Four Years—But Seven Distinct Roles Emerged. Which One Are You Hiring First?

General
1

Platform engineering adoption jumped from 45% to 80% in four years, and the results are staggering. Organizations with strong platform engineering leadership are seeing:

  • 70% reduction in time-to-market
  • 40% improvement in developer productivity
  • 40-50% reduction in cognitive load for developers

But here’s what nobody tells you: “platform engineer” is now as vague as “software engineer.”

Seven Distinct Roles Have Emerged

When Gartner forecasts that 80% of large organizations will have platform teams by 2026, they’re not talking about one role. The field has splintered into at least seven specializations:

  1. Head of Platform Engineering (HOPE) - Strategic leadership
  2. Platform Product Manager (PPM) - Product thinking for internal platforms
  3. Infrastructure Platform Engineer (IPE) - Cloud, IaC, orchestration
  4. DevEx Platform Engineer (DPE) - Developer experience, tooling, self-service
  5. Security Platform Engineer (SPE) - Security guardrails, compliance
  6. Observability Platform Engineer (OPE) - Monitoring, alerting, SRE practices
  7. AI-focused Platform Engineer - LLM infra, model deployment, AI governance

Each has different skill requirements, different success metrics, different team structures.

The Hiring Problem

If you’re scaling your engineering org and decide “we need platform engineering,” which role do you hire first?

The DevEx-first approach: Start with a DevEx Platform Engineer to build self-service infrastructure. Get developers out of ticket queues and into autonomous workflows. Platform teams report reducing deployment time from 2-3 weeks to less than one day through self-service provisioning.

The infrastructure-first approach: Hire Infrastructure Platform Engineers to stabilize your cloud architecture before you build developer experience layers on top. If your Kubernetes setup is a mess, fancy portals won’t help.

The product-first approach: Bring in a Platform Product Manager to treat your IDP like a product with users (developers), adoption metrics, and roadmap prioritization. Successful platform teams measure ROI in business terms—revenue enabled, costs avoided, profit contribution.

The AI-native approach: With 94% viewing AI as critical to platforms’ future, some teams are hiring AI-focused platform engineers first to build the infrastructure for LLM deployment, vector databases, and AI governance from day one.

What We’re Doing (and Why)

We’re going DevEx-first. Our biggest bottleneck isn’t infrastructure stability—it’s developers waiting on ops tickets for basic stuff like database provisioning, environment setup, and CI/CD pipeline changes.

Hiring an Infrastructure Platform Engineer would optimize things that already work. Hiring a DevEx Platform Engineer should unlock the autonomy that makes the 40% productivity gains real.

But I’m second-guessing this. Maybe we’re skipping the foundation and jumping straight to the fancy UI?

Questions for the Community

  1. If you could only hire ONE platform role in the next 6 months, which would it be and why?
  2. What’s the biggest mistake teams make when building platform teams? (Hiring the wrong role first? Skipping product management? Not measuring ROI?)
  3. Does the seven-role split feel real to you, or is this consultant over-categorization?

Sources:

2

This resonates deeply. We went through this exact decision at my Fortune 500 fintech 18 months ago, and I’ll share what worked (and what almost derailed us).

We Hired the “Wrong” Role First (But It Was Right for Us)

Everyone said hire DevEx first. All the conference talks, all the blog posts. But we started with an Infrastructure Platform Engineer and it saved us.

Why? Our cloud spend was out of control ($2.3M/year), our Kubernetes clusters were a mess of overlapping responsibilities, and we had THREE different IaC patterns across teams. Developers couldn’t move fast because the foundation was unstable.

Hiring a DevEx engineer to build self-service on top of that chaos would have been like putting a nice UI on a dumpster fire. :fire:

The Sequence That Worked

Months 1-4: Infrastructure Platform Engineer stabilized our cloud architecture, consolidated IaC patterns, got our K8s clusters under control. Cloud spend dropped 31% in 4 months.

Months 5-8: Hired Platform Product Manager to interview developers about pain points. This was the game-changer. She ran 47 interviews in 6 weeks and discovered our assumptions were totally wrong.

Months 9-12: Hired DevEx Platform Engineer to build self-service tooling based on ACTUAL developer needs (not what we thought they needed).

Month 13: First real adoption. Deployment time went from 18 days average to 3 days for teams using the platform.

Month 18 (now): 67% voluntary adoption rate. Teams use it because it’s faster, not because we mandated it.

The Biggest Mistake Teams Make

Not hiring the Platform Product Manager early enough.

Platform engineers (infrastructure or DevEx) think like operators: uptime, reliability, efficiency. They don’t naturally think like product managers: user research, adoption metrics, roadmap prioritization.

We almost made this mistake. Our first platform engineer built what HE thought was needed. Smart guy, great technical judgment, but he interviewed zero developers before shipping.

The Platform PM changed everything. She treats developers like customers. She measures DORA metrics AND satisfaction scores. She runs quarterly “platform retrospectives” where developers tell us what’s working and what’s not.

Your DevEx-First Bet

You asked if going DevEx-first means “skipping the foundation and jumping to the fancy UI.”

It depends on your foundation. Questions to ask:

  1. Is your infrastructure stable enough? If developers complain about outages, inconsistent environments, or “works on my machine” problems, fix infrastructure first.

  2. Is your cloud spend under control? If not, you need infrastructure optimization before you scale self-service access.

  3. Do you KNOW what developers actually need? If you haven’t interviewed at least 20 developers across different teams, you’re guessing.

If your infrastructure is stable and you’ve done real user research, DevEx-first can work. But if you’re assuming you know what they need without asking, you’ll build the wrong thing fast.

The Seven-Role Split Is Real (Eventually)

At our scale (40+ engineers in platform org supporting 300+ product engineers), we have:

  • 2 Platform Product Managers
  • 8 Infrastructure Platform Engineers
  • 5 DevEx Platform Engineers
  • 3 Security Platform Engineers
  • 2 Observability Platform Engineers
  • 1 AI Platform Engineer (just hired)
  • 1 Head of Platform Engineering (me)

But we didn’t start there. We started with 1 person and grew based on bottlenecks.

For your first hire? Platform Product Manager or Infrastructure Platform Engineer. The PM if your foundation is stable. Infrastructure if it’s not.

Then hire based on what your USERS (developers) tell you they need, not what the conference circuit says you should build. :bullseye:

3

The seven-role split isn’t consultant over-categorization—it’s organizational maturity showing up in job descriptions.

I’ve been CTO through three different platform engineering buildouts (Microsoft, two startups, current company). The role specialization is real, but it’s a maturity curve, not a Day 1 org chart.

The Maturity Curve I’ve Seen

Stage 1 (0-50 engineers): One “full-stack platform engineer” who does everything. Infrastructure, tooling, developer support, security. It’s unsustainable but it works temporarily.

Stage 2 (50-150 engineers): Split into Infrastructure and DevEx. Infrastructure team keeps the lights on, DevEx team builds the self-service layer. This is where most companies are in 2026.

Stage 3 (150-500 engineers): Platform Product Management emerges as a distinct function. Security and Observability split off into their own specializations. You’re running a mini product organization inside engineering.

Stage 4 (500+ engineers): Full role specialization. Platform PM owns roadmap and prioritization. Infrastructure, DevEx, Security, Observability, and AI teams operate as distinct units with clear interfaces.

We’re at Stage 3 right now (240 engineers). Two years ago we were Stage 1.

Why the Split Happens

Each specialization emerges when you hit a scaling bottleneck:

Infrastructure Platform Engineers emerge when your cloud architecture can’t scale and your AWS bill is growing faster than revenue.

DevEx Platform Engineers emerge when developer productivity tanks because everyone’s waiting on ops tickets.

Security Platform Engineers emerge when you get your first SOC 2 audit or when a compliance requirement blocks a major customer deal.

Observability Platform Engineers emerge when debugging across microservices becomes impossible and your MTTR starts measuring in days instead of hours.

Platform Product Managers emerge when adoption is <30% despite building “everything developers asked for” and you realize you’re solving the wrong problems.

AI Platform Engineers emerge when your ML teams are manually provisioning GPU instances and your LLM experiments take 3 weeks to move from notebook to production.

The Hiring Trap Everyone Falls Into

You’re asking “which role first?” but that’s the wrong question.

The right question: What’s the most expensive problem you’re NOT solving right now?

If it’s cloud costs spiraling, hire Infrastructure.

If it’s developers blocked on ops tickets, hire DevEx.

If it’s <30% adoption of existing platform tooling, hire Platform PM.

If it’s security blocking every release, hire Security Platform.

If it’s inability to debug production issues, hire Observability.

If it’s AI/ML teams reinventing infrastructure for every model, hire AI Platform.

Don’t hire based on what the industry says. Hire based on what’s actively costing you money, time, or deals.

Your DevEx-First Decision

You said: “Our biggest bottleneck isn’t infrastructure stability—it’s developers waiting on ops tickets.”

If that’s true, DevEx-first is correct. But validate it.

Questions to ask before hiring:

  1. How many hours per week are developers waiting on ops tickets? If it’s <5 hours/week average, that’s not your bottleneck.

  2. What happens when you remove the ops ticketing system for one team and let them self-serve? Do they succeed or do they break prod?

  3. Are your infrastructure patterns documented and repeatable enough that self-service won’t create chaos?

If your answers are “20+ hours/week,” “they succeed,” and “yes,” then DevEx-first is right.

If your answers are “not sure,” “they break prod,” and “no,” then you need Infrastructure first to create the stability layer that makes self-service possible.

The One Thing I’d Do Differently

If I could restart our platform engineering journey, I’d hire the Platform PM first, not last.

That person interviews developers, identifies the real bottlenecks, and builds the business case for which specialization to hire next. They prevent you from building the wrong thing, which is way more expensive than hiring slowly.

We wasted 8 months building a service catalog nobody used because we didn’t have someone treating developers as customers. That’s a $600K mistake (2 engineers × 8 months × $150K fully loaded cost).

A $180K Platform PM would have saved us that.

4

Coming at this from the product side, not the engineering side, but I’ve watched our platform team go through this exact crisis and it’s fascinating how similar the failure modes are to product-market fit searches.

Platform Engineering Has a PMF Problem

You’re asking “which role to hire first?” but the real question is: Do you have product-market fit for your internal platform?

Most platform teams skip the customer development phase entirely. They build what they think developers need (based on their own ops experience) rather than what developers actually need (based on interviews and observation).

At my last company, our platform team built:

  • Service catalog (3 months)
  • CI/CD templates (2 months)
  • Deployment automation (4 months)
  • Observability dashboards (2 months)

Total: 11 months of work, $800K in engineering cost.

Adoption: 14% after 6 months in production.

Why? They never validated the problems they were solving were actually the top pain points.

What We Did Differently This Time

When we spun up our platform team at current company (Series B fintech), I convinced leadership to treat it like a product launch:

Month 0: Hired a Platform Product Manager (yes, this was the FIRST hire)

Month 1-2: Platform PM ran customer discovery

  • 52 developer interviews across 8 teams
  • Shadow sessions watching developers deploy, debug, provision infrastructure
  • Journey mapping for common workflows

Month 3: Prioritized problems by frequency × impact

  • #1 problem: Environment setup takes 2-3 days for new engineers
  • #2 problem: Debugging staging issues requires tribal knowledge
  • #3 problem: Database provisioning takes 1-2 weeks through IT tickets

Month 4-6: Hired 2 DevEx Platform Engineers to build MVPs for top 3 problems

Month 7: Launched with 3 features, heavy onboarding, weekly feedback sessions

Month 12: 73% adoption rate (measured by “% of teams using at least one platform feature weekly”)

The Product Thinking Difference

Traditional platform teams measure:

  • Uptime
  • Latency
  • Resource utilization
  • Number of services deployed

Product-thinking platform teams measure:

  • Adoption rate (% of teams actively using the platform)
  • Time-to-value (how long until a new user gets value)
  • NPS or satisfaction score (would you recommend this to other developers?)
  • Usage depth (how many features does each team use?)
  • Retention (do teams keep using it or churn back to manual processes?)

We run quarterly developer surveys. We do monthly “platform retrospectives” where developers tell us what’s broken. We have a public roadmap and developers can upvote features.

It’s product management 101, but most platform teams don’t do it.

Your DevEx-First Bet: Product Lens

You’re second-guessing DevEx-first. Here’s how I’d validate it:

Customer discovery questions:

  1. What’s the most frustrating part of your job right now? (Open-ended, no leading)
  2. How much time do you spend waiting on infrastructure/ops/platform requests per week?
  3. If you could automate ONE thing about your workflow, what would it be?
  4. What almost made you quit in the last 6 months? (Surprisingly revealing)

If the answers are consistently “waiting on ops tickets” and “can’t self-serve basic infrastructure,” then DevEx-first is right.

If the answers are “prod is always breaking” or “I can’t trust the infrastructure,” then you need Infrastructure first.

If the answers are all over the map with no pattern, then you don’t understand the problem well enough to hire anyone yet. Hire a Platform PM to do the discovery.

The Seven-Role Question

The seven-role split feels like the evolution from “software engineer” to specialized roles (frontend, backend, ML, data, infra, security, etc.).

It’s not over-categorization—it’s specialization following scale.

But just like you don’t hire a “Director of Frontend Engineering” when you have 5 engineers total, you don’t hire 7 distinct platform roles when you’re starting out.

You hire based on the problem. You specialize as you scale.

For a Series B company, my instinct is:

  1. Platform PM (if you don’t have one) to validate the problems
  2. DevEx or Infrastructure engineer based on validated problem
  3. Scale from there based on actual bottlenecks

The Uncomfortable Truth

Most platform teams fail not because they hired the wrong role first, but because they never validated that developers wanted what they were building.

It’s the same reason most startups fail: they build something nobody wants.

Treat your platform like a product. Treat developers like customers. Measure adoption like you’d measure MAUs. Run experiments before committing to 6-month builds.

If you do that, the “which role first?” question becomes obvious: whatever role solves the validated problem fastest. :bullseye: