Platform Engineering's Identity Crisis: Are We Just DevOps 2.0 or Actually Building Developer Products?

General
1

I’ve been thinking about this a lot lately while working on our design system at Confluence. We call it an “internal product” and treat our developers like customers - roadmap, user research, the whole nine yards. Sound familiar? That’s basically the pitch for platform engineering too.

But here’s my question: Is platform engineering actually something new, or is it just DevOps with better branding? :thinking:

The Rebranding Question

I’ll be honest - when I first heard about platform engineering, my BS detector went off. It felt like when everyone renamed themselves “growth hackers” or “DevOps engineers” to stay relevant. Same people, same work, new LinkedIn title.

But the more I dig in, the more I think something real changed. Not in the technology, but in the mindset.

What Actually Changed?

Here’s what I see as different:

Old DevOps thinking: “We built this CI/CD pipeline. Now everyone has to use it. Training is next Tuesday.”

Platform engineering thinking: “What deployment pain are developers actually feeling? Let’s build something so good they want to use it.”

That shift from mandate to adoption feels huge. It’s the difference between my first design system (which everyone hated and avoided) and my current one (85% voluntary adoption).

The Product Mindset Trap

But here’s the thing - a lot of platform teams say they’re product-focused but still behave like ops teams:

  • No user research with developers
  • No clear adoption metrics vs mandates
  • No roadmap communicated outside the team
  • “We know what’s best for them” attitude

That’s not a product mindset. That’s just nicer-sounding authoritarianism. :grimacing:

My Design System Failure Story

I learned this the hard way. At my startup, I built a design system because I thought it was “best practice.” I made it comprehensive, documented, and technically beautiful.

Developers hated it. Too complex, too opinionated, solved problems they didn’t have.

Now? I start with user research. “What UI pain are you feeling?” “Where do you waste time?” “What would make your life easier?”

Turns out they wanted dead-simple components for 5 common patterns, not a comprehensive system for every edge case. Built that instead. Adoption soared.

Isn’t this the exact conversation platform engineering is having right now?

Questions for This Community

I’m genuinely curious about your experiences:

  1. When did you realize you were building a product, not just infrastructure? What was the moment it clicked?

  2. How do you measure adoption vs mandates? Like, really measure it? Can teams opt out of your platform, or is it required?

  3. What’s the real difference between a Platform Engineer and a Senior DevOps Engineer? Is it the title, the org structure, the mindset, or the actual work?

  4. Are we just rebranding because “DevOps” got watered down? Be honest - how much of this is marketing?

The Identity Crisis Is Real

Maybe the identity crisis itself is the point? Maybe platform engineering is DevOps 2.0 - the evolution that happens when you take the cultural philosophy of DevOps and actually build it into a product discipline?

Or maybe I’m overthinking this and we should just focus on shipping tools that make developers’ lives better, whatever we call it. :woman_shrugging:

What do you think? Let’s figure out what makes platform engineering actually different - or admit it’s just a rebrand and move on.

Posted from Austin while debugging why our component library works in Figma but not in production. Again. :sparkles:

2

This resonates deeply, Maya. I’ve lived through exactly this transition you’re describing - managing teams that literally went from having “DevOps Engineer” titles to “Platform Engineer” titles. And you’re right to question whether the shift is real.

The Organizational Change That Matters

Here’s what I’ve observed: The shift from DevOps to Platform Engineering is real, but it requires organizational change, not just renaming the Slack channel.

When we were “doing DevOps,” my team’s success metrics were:

  • Uptime percentages
  • Deployment automation coverage
  • Number of CI/CD pipelines created

Now as a “Platform Engineering” team, our metrics are:

  • Developer satisfaction scores (we survey quarterly)
  • Time-to-first-deployment for new services
  • Platform adoption rate (voluntary vs mandated)
  • Developer velocity (lead time improvements)

See the difference? We shifted from measuring our output to measuring their outcomes.

The Journey Was Messy

It wasn’t instant. For the first 6 months after we “became” a platform team, we were still operating like an ops team:

  • Built features we thought were important
  • Measured success by technical excellence
  • Got frustrated when developers “didn’t appreciate” our work

The turning point came when our VP of Engineering (shoutout to leaders like Keisha who get this) mandated that we treat our internal platform like a product launch. That meant:

  • User interviews with 15 dev teams about their pain points
  • A public roadmap with quarterly themes
  • Monthly “office hours” for feedback
  • Opt-in adoption for new features (with fallback to old tools)

That last one was scary. What if nobody used our new deployment pipeline? What if they preferred the old bash scripts?

Turns out, fear of rejection makes you build better products. :sweat_smile:

The Skills Gap Is Real

But here’s the uncomfortable truth, Maya: Product mindset requires PM skills that most engineers don’t have and don’t want to learn.

My best platform engineers are:

  • Technically deep enough to build solid infrastructure
  • Customer-empathetic enough to sit through user interviews
  • Humble enough to scrap their elegant solution for a simpler one developers actually want

That combination is rare. I’ve got senior engineers who can architect anything but get defensive when a junior dev says “this is too complicated.” And I’ve got engineers who love user research but struggle with the deep technical work.

The Question I’m Wrestling With

How do we train engineers to think like product managers without hiring actual PMs for every platform team?

We’ve tried:

  • Sending engineers to product management workshops (mixed results)
  • Rotating engineers through customer-facing roles (logistically hard)
  • Pairing platform engineers with product managers on app teams (worked best)

But it’s still a work in progress. The DevOps to Platform Engineering evolution requires skill development, not just mindset shift.

So Is It Just Rebranding?

My take: DevOps without the product discipline was incomplete. Platform Engineering is what happens when you take DevOps philosophy and ask “okay, but how do we make this sustainable at scale with a product approach?”

The companies succeeding aren’t choosing between DevOps and Platform Engineering - they’re using platform engineering to make DevOps principles work beyond 20 engineers.

At 50+ engineers with multiple teams, you can’t rely on culture and communication alone. You need actual product infrastructure.

What about others? How are you training your platform engineers in product thinking? Or are you just hiring PMs and calling it a day?

3

Luis nailed something critical here - this conversation changes dramatically based on scale. Let me add the scaling perspective because I think that’s where the DevOps vs Platform Engineering distinction becomes undeniable.

It’s DevOps at 20 Engineers, Platform Engineering at 200

When I was at Google with thousands of engineers, we didn’t call it “platform engineering” yet, but that’s exactly what we were doing. You simply cannot run DevOps culture alone at that scale.

At my current EdTech startup, I’ve watched this evolution in fast-forward:

At 25 engineers (2 years ago):

  • DevOps was enough
  • Shared Slack channel for deployment questions
  • One senior engineer knew how everything worked
  • Cultural norms and documentation kept everyone aligned

At 80+ engineers (now):

  • DevOps culture alone is chaos
  • New teams don’t absorb tribal knowledge fast enough
  • The “ask in Slack” approach doesn’t scale
  • We need actual product infrastructure with self-service capabilities

The inflection point for us was around 50 engineers. That’s when “just ask Luis” stopped working.

The Data Supports This

Maya asked if this is just rebranding. Here’s what the data shows:

  • Gartner’s 2026 prediction: 80% of engineering orgs will have platform teams
  • DORA’s actual 2026 data: Already 90% have internal platforms

We exceeded the prediction a year early. That’s not rebranding - that’s market validation of a real need.

But here’s what the data doesn’t capture: Most of those “platform teams” are still just renamed infrastructure teams. They’re in the org chart as platform engineering, but they report to infrastructure, not product. They measure uptime, not developer satisfaction.

The Organizational Structure Problem

This is the part that frustrates me most. The philosophy changed, but the org structure hasn’t caught up:

Where Platform Teams Usually Report:

  • Infrastructure or Operations (65% of companies I’ve talked to)
  • Engineering Efficiency (25%)
  • Actually reporting to Product or having PM partnership (10%)

What This Reveals:
If your platform team reports to infrastructure, you’re signaling they’re a cost center providing a utility, not a product team serving customers.

My platform team reports to me (VP Eng) and partners with product leadership. They have:

  • Dedicated budget separate from infrastructure
  • Product managers embedded (more on this in David’s thread, I bet)
  • Developer satisfaction as a key metric
  • Ability to say “no” to feature requests that don’t serve the roadmap

That required executive-level negotiation to set up. Not because anyone disagreed with the philosophy, but because org structure is hard to change.

The Real Question: Product or Utility?

Maybe the real identity crisis isn’t “DevOps vs Platform Engineering” but “Platform as Product vs Platform as Utility”?

  • Platform as Utility: Mandated, centralized, measured by technical metrics, cost-center thinking
  • Platform as Product: Adopted, customizable, measured by satisfaction metrics, investment thinking

Both can call themselves “platform engineering,” but only one is actually different from traditional DevOps/Infrastructure.

Scale Matters More Than Labels

My controversial take: If you have fewer than 40-50 engineers, don’t bother with platform engineering. Keep doing DevOps. Seriously.

The overhead of product thinking, roadmaps, user research - it’s not worth it until the scale demands it. You’ll spend more time planning your platform than actually building product.

But if you’re past that threshold and still running DevOps-only? You’re about to hit a wall.

Question for the group: At what engineer count did you realize you needed platform engineering? I’m curious if my 50-engineer threshold is universal or specific to our pace of growth.

4

As the product person in this conversation, I’m watching this thread with both fascination and frustration. You’re all circling around the core issue but dancing around what I see as the elephant in the room:

“Platform as Product” without actual product management discipline is just marketing. :bullseye:

Let Me Challenge Everyone Here

Maya, Luis, Keisha - you’re all talking about product thinking, user research, roadmaps, adoption metrics. These are textbook product management practices.

So here’s my question: Where are your Platform Product Managers?

Not “engineers doing product thinking.” Not “distributed product ownership.” Not “we all wear the PM hat.”

I mean actual, dedicated product managers who:

  • Run user research with developers (not just send surveys)
  • Maintain a prioritized roadmap based on data
  • Say “no” to feature requests that don’t fit the strategy
  • Measure adoption, retention, and satisfaction
  • Communicate value to executives for budget conversations

The Uncomfortable Truth From Outside Engineering

I’ve worked with probably a dozen platform teams across Google, Airbnb, and now my current startup. Want to know what I see?

Teams that claim product thinking:

  • “We talk to developers in Slack” (not user research)
  • “We have a backlog” (not a roadmap)
  • “We track usage” (not adoption strategy)
  • “Developers should use this, it’s better” (not customer empathy)

Teams that actually practice product management:

  • Scheduled user interviews with rotating developer teams
  • Public roadmap with themes, not just features
  • Explicit non-goals (what they won’t build)
  • Adoption playbooks for rolling out new capabilities
  • Monthly metrics reviews with stakeholders

The difference is staggering. And you know what the actual product teams have that the product-thinking teams don’t?

A Product Manager.

The Framework Question

Let’s get tactical. If you’re serious about platform-as-product, answer these questions:

  1. Jobs to be Done: What job are developers hiring your platform to do? Can you articulate it in one sentence per major use case?

  2. Customer Discovery: When was your last 1-on-1 interview with a developer? Not a support ticket. Not a Slack thread. A structured interview about their workflow.

  3. Adoption vs Retention: Are teams using your platform because they have to, or because they want to? How do you measure the difference?

  4. Roadmap Communication: Can any developer in your org tell you what’s on your platform roadmap for next quarter? If not, you don’t have a roadmap - you have a backlog.

  5. North Star Metric: What’s the one metric that defines platform success? (And no, “adoption rate” alone isn’t enough - why do you want adoption?)

The Skills Gap Luis Mentioned

Luis, you asked how to train engineers in product thinking. My answer might frustrate you: You don’t.

Product management is a discipline. It takes years to develop. You wouldn’t ask a PM to learn senior-level engineering in 6 months. Why do we think engineers can learn PM skills in a workshop?

The teams I’ve seen succeed did one of three things:

  1. Hired dedicated Platform PMs (rare, expensive, but most effective)
  2. Borrowed PMs from app teams part-time (messy but workable)
  3. Promoted engineers with PM aptitude and gave them actual PM training + mentorship (long-term investment)

“Distributed product thinking” is the fourth option everyone tries. It fails 90% of the time.

Why? Because product management is about making hard tradeoffs. Engineers are trained to solve problems, not to say “we’re not solving that problem.”

My Offer to This Community

I know this sounds harsh. But I genuinely want platform teams to succeed because good internal tools make my product teams more effective.

If anyone here wants to talk through product management practices for platform teams, I’m happy to share frameworks:

  • How to run developer user research
  • Building roadmaps for internal products
  • Measuring platform product-market fit
  • Making the business case for platform investment

But we have to be honest: Calling it a product doesn’t make it a product. Treating it like a product does.

Question back to the group: How many of you have actual dedicated Product Managers for your platform teams? And for those who don’t - have you tried to get headcount approved? What was the blocker?

5

David just dropped truth bombs and I’m here for it. But let me add the strategic layer to this conversation because I think we’re all dancing around what’s actually happening in 2026.

The identity crisis isn’t about labels - it’s about architecture meeting AI at scale.

Why 2026 Is Different

Maya started this asking if platform engineering is just DevOps 2.0. David pointed out we’re missing actual PM discipline. Keisha showed it’s a scale problem.

They’re all right. But here’s what’s forcing the evolution right now:

You literally cannot bolt AI onto DevOps practices. You need platform thinking.

Every CTO I talk to (and I talk to a lot of them) is facing the same challenge:

  • Teams want to ship AI features
  • Legacy DevOps tooling can’t handle ML workflows
  • Data scientists and app developers need different deployment patterns
  • Nobody wants to manage three separate delivery pipelines

This isn’t theoretical. This is happening now.

The Data That Matters

Let’s talk about what actually works:

Companies like Spotify saw 60-90% DevEx gains from platform engineering. Not 5-10%. Not 20%. 60-90%.

That’s not incremental improvement. That’s paradigm shift.

But here’s what the headlines don’t tell you: Those gains came from treating platform as a product with real PM discipline (David’s point), at scale where DevOps culture alone fails (Keisha’s point), with organizational buy-in (Luis’s point).

All three conditions have to be true. Skip any one and you get incremental results, not transformational ones.

The Uncomfortable Reality Check

Most companies claiming platform engineering success are lying. Or at least exaggerating.

I’ve been in rooms where CTOs present their “platform engineering transformation” and it’s literally:

  • Renamed the DevOps team
  • Bought a vendor IDP platform
  • Mandated adoption
  • Measured… nothing new

That’s not platform engineering. That’s theater.

Real platform engineering looks like:

  • Dedicated team with PM partnership (only 21.6% of companies according to recent data)
  • Unified delivery pipeline serving multiple personas (app devs, ML engineers, data scientists)
  • Self-service capabilities with golden paths (documented, supported, actually used)
  • Metrics tied to business outcomes, not just technical ones
  • Organizational structure that signals investment, not cost

The AI Forcing Function

Here’s my controversial take: AI is forcing companies to actually do platform engineering right, because half-measures don’t work for AI workloads.

You can fake platform engineering for traditional apps. You can rename DevOps and nobody notices if services keep deploying.

But AI workloads expose every weakness:

  • Data pipelines that aren’t standardized
  • Deployment processes that assume stateless apps
  • Monitoring that doesn’t handle model drift
  • Security models that don’t account for agentic workflows

Suddenly, “we renamed the Slack channel” doesn’t cut it. You need actual product infrastructure.

So Is It Just Rebranding?

My answer: For 80% of companies right now, yes, it’s just rebranding.

They’re in transition. They’re claiming the label before earning it. That’s fine - you have to start somewhere.

But the 20% who actually transformed? They’re seeing real results. And the gap between the two groups is widening.

What I Tell My Board

When I present our platform engineering strategy to the board, I don’t talk about DevOps vs Platform Engineering. That’s an implementation detail.

I talk about:

  • Developer velocity: Can we ship features faster?
  • Engineering efficiency: What’s our output per engineer?
  • Risk reduction: Fewer outages, faster recovery
  • AI enablement: Can we deploy ML models as easily as services?

Those are business outcomes. That’s what platform engineering actually delivers when done right.

The label doesn’t matter. The outcomes do.

The Challenge to Everyone Here

Stop asking “is platform engineering different from DevOps?”

Start asking: “Are we measuring business outcomes or just following industry trends?”

If you can show:

  • Deployment frequency increased 2-3x
  • Lead time decreased by half
  • Developer satisfaction improved measurably
  • Fewer escalations to platform team (self-service works)
  • New team onboarding cut from weeks to days

Then call it whatever you want. You’re doing it right.

If you’re just measuring “platform adoption percentage” and calling it success? You’re doing theater.

Question for this group: How many of you can tie your platform engineering work to actual business metrics your CFO cares about?

Because that’s the conversation that gets platform teams funded, respected, and actually empowered to build products instead of utilities.