Seven Distinct Platform Engineering Roles Emerging in 2026—From Platform Product Manager to DevEx Platform Engineer. Is Role Specialization Solving Complexity or Creating New Silos?

General
1

Two years ago, our platform team was three people with the simple title “Platform Engineer.” Fast forward to today, and we’re 12 people with seven distinct specialized roles at my Fortune 500 financial services company. While the industry is celebrating this maturation of platform engineering, I’m starting to wonder: Are we solving complexity, or are we creating new silos?

The Seven Emerging Roles

According to recent industry predictions for 2026, platform engineering is accelerating into these specialized roles:

  1. Head of Platform Engineering (HOPE) — Executive-level strategic leadership
  2. Platform Product Manager (PPM) — Treating internal platform as a product
  3. Infrastructure Platform Engineer (IPE) — Core infrastructure and provisioning
  4. DevEx Platform Engineer (DPE) — Developer experience and tooling
  5. Security Platform Engineer (SPE) — Security tooling and compliance
  6. Observability Platform Engineer (OPE) — Monitoring, logging, tracing
  7. AI-Focused Platform Engineer — AI integration and agentic systems

Each role makes sense individually. The problem? We’re starting to see Conway’s Law play out in real-time.

Conway’s Law Strikes Again

For those unfamiliar: Conway’s Law states that “organizations design systems that mirror their communication structures.” When we split our platform team into seven specialized roles, we noticed something troubling:

  • The DevEx team optimized for developer velocity but created security review bottlenecks
  • The Security Platform team built great guardrails but slowed deployment pipelines
  • The Observability team gave us incredible insights but added complexity to every service

Each team was locally optimal but globally suboptimal. We had accidentally created “sovereign states” within our platform org.

The Question I’m Wrestling With

At what scale does role specialization actually make sense?

  • 40 engineers? Probably too early—everyone still needs to be full-stack
  • 80 engineers? Maybe—you’re feeling pain points that specialists could address
  • 150+ engineers? Definitely—but only if you design the org structure intentionally

My current thinking: We over-rotated on specialization. We should have stayed with generalists longer and been more deliberate about when and how to specialize.

What I’m Trying Next

We’re experimenting with a “T-shaped platform engineers” model:

  • Everyone has a specialty (the vertical bar of the T)
  • Everyone participates in cross-cutting concerns (the horizontal bar)
  • We rotate people through different areas every 6 months
  • Ownership is shared, not siloed

Early results are promising, but it requires constant intentionality to prevent drift back into silos.

Questions for the Community

For those of you building platform teams:

  1. How large is your engineering org? At what size did you start specializing platform roles?
  2. Have you seen Conway’s Law create unintended silos? How did you address it?
  3. Do you prefer specialists or generalists? Or some hybrid model?
  4. How do you prevent specialized teams from becoming bottlenecks?

I’d especially love to hear from CTOs and VPs who’ve scaled platform teams beyond 50 engineers. What worked? What would you do differently?

2

This resonates deeply. I saw this exact pattern play out at my previous company, and now I’m being intentional about avoiding it as we scale our EdTech startup’s engineering org.

The DevEx Silo Formation Story

We created a dedicated “Developer Experience” team when we hit about 40 engineers. Within three weeks, I watched it become a silo:

  • Backend engineers would say “that’s a DevEx problem” when CI/CD was slow
  • DevEx team started building features nobody asked for because they weren’t talking to actual developers
  • Deployment pipeline improvements required going through the DevEx team’s queue

The DevEx team wasn’t trying to be gatekeepers—but that’s what they became because we didn’t design for shared ownership.

What I’m Doing Differently Now

For our 80-person engineering org, we’re trying a hybrid model:

Specialization WITH shared ownership:

  • We have people with deep expertise in platform areas (DevEx, infra, security)
  • But they’re embedded in product teams 60% of the time
  • Platform work is a rotating responsibility—everyone spends time on it
  • Major platform decisions require cross-team RFC process

Intentional rituals to prevent silos:

  • Bi-weekly “Platform Show & Tell” where anyone can demo platform improvements
  • Quarterly rotation where product engineers spend a sprint on platform work
  • Platform team members pair with product engineers on integration

The Question That Keeps Me Up

How do you prevent specialists from becoming gatekeepers?

I think the answer is: You can’t hire your way out of it with the “right people.” You have to design processes and incentives that reward collaboration over territorial behavior.

Luis, your T-shaped model sounds promising. Are you measuring adoption rates of platform features? In my experience, low voluntary adoption is the canary in the coal mine for silo formation.

3

I’m going to respectfully push back on the framing that specialization inevitably creates silos. I think we’re conflating two different problems: role clarity vs. organizational silos.

Our Experience Scaling Platform at 120 Engineers

When I joined as CTO two years ago, we had the opposite problem Luis describes—three “platform engineers” who were spread so thin they couldn’t go deep on anything. They were context-switching constantly and burning out.

We deliberately created specialized roles, and it’s been a net positive because we designed for coordination from the start.

Conway’s Law as a Design Tool, Not a Trap

Yes, Conway’s Law says your architecture mirrors your org structure. But here’s the insight: That means you can use it as a design tool, not just accept it as a constraint.

We structured our platform team like an API:

  • Each specialty (DevEx, Security, Observability) owns clear “endpoints”
  • We have explicit SLAs between platform teams
  • Weekly sync meetings with clear owners and decision-making authority
  • Shared OKRs that require cross-team collaboration

The key: Coordination is a first-class concern, not an afterthought.

Seven Competencies ≠ Seven Separate People

Luis, one thing that jumped out: You have 12 people covering seven roles. That’s actually pretty lean—it means multiple people are covering each competency, or some people wear multiple hats.

At our scale (120 engineers), we have:

  • 1 Head of Platform
  • 1 Platform PM (critical role—more on this later)
  • 6 platform engineers with overlapping specialties

That’s 8 people, not 12. The specialties are competencies they bring, not rigid job descriptions.

The Real Question

Are we confusing role specialization (having deep expertise in areas) with organizational silos (poor communication and coordination)?

You can have specialists who collaborate beautifully. You can also have generalists who work in silos because the org structure doesn’t incentivize cross-team work.

The problem isn’t the specialization—it’s whether you’ve designed processes that require integration, or accidentally created isolated fiefdoms.

Keisha’s point about measuring adoption is spot-on. We track:

  • Platform feature usage rates
  • Developer satisfaction scores (quarterly survey)
  • Cross-team collaboration metrics (PRs reviewed across teams)

When those metrics drop, we know we’re trending toward silos, regardless of whether we have specialists or generalists.

4

Coming at this from a design perspective, I’m seeing a parallel to what happened with design teams over the last 5 years. We went from “UX Designer” to specialized roles like UX Writer, UX Researcher, Product Designer, Interaction Designer, etc.

The Design Team Specialization Story

My failed startup made this exact mistake. We were a team of 8, and I hired our first dedicated UX Researcher when we hit 6 people.

What I thought would happen:

  • Better research would inform better design decisions
  • The researcher would uncover insights we were missing
  • Designers could focus on craft while research handled discovery

What actually happened:

  • Customer knowledge became siloed in one person
  • Designers stopped talking to customers (“that’s the researcher’s job”)
  • When the researcher left after 6 months, we realized nobody else knew how to run a research session

We had created a knowledge silo, not a functional team.

Scale Thresholds Matter

I think the answer to Luis’s question about scale is more nuanced than just headcount. It’s about different types of specialization at different scales:

<50 engineers:

  • Everyone is a generalist
  • Specialization is informal and rotates
  • Knowledge-sharing is easier because team is small

50-150 engineers:

  • Hybrid model with T-shaped specialists
  • Some formalization of roles but lots of overlap
  • Intentional rituals to prevent silos (what Keisha described)

150+ engineers:

  • Full specialization makes sense
  • Need dedicated coordination mechanisms (what Michelle described)
  • Investment in documentation and knowledge management becomes critical

The Silo Prevention Checklist

Based on my experience (both success and failure), here’s what prevents silos:

:white_check_mark: Shared context rituals (show & tells, demos, RFC reviews)
:white_check_mark: Rotation programs (temporary secondments across teams)
:white_check_mark: Documentation as a first-class deliverable (not an afterthought)
:white_check_mark: Pairing across specialties (researcher + designer, platform + product eng)
:white_check_mark: Hiring for collaboration (interview for willingness to share knowledge)

The common thread: Intentionality. Silos form when you specialize without deliberately designing for integration.

Optimistic Note

Here’s the thing: When specialization works well, it actually accelerates delivery because people can go deep and become truly excellent at their craft.

The goal isn’t to avoid specialization—it’s to specialize at the right time, in the right way, with the right collaboration mechanisms in place.

Luis, your T-shaped model sounds like you’re at that inflection point where you need some specialization but not full isolation. That’s actually the hardest stage to navigate, so kudos for being intentional about it.

5

Jumping in from the product side because I think we’re missing a critical piece of this puzzle: The Platform Product Manager role.

Michelle mentioned it briefly, but I want to emphasize why this role is the key to preventing platform silos.

The Data on Platform PMs

According to the 2026 Platform Engineering survey, only 21.6% of organizations have a Platform Product Manager, but 38% say they need one.

That gap matters because platform teams without product thinking become infrastructure teams that nobody wants to use.

Why Platform Becomes a Silo Without Product Thinking

I’ve watched this pattern play out at two companies now:

Scenario A: No Platform PM

  • Platform team builds what engineers think is cool
  • Adoption is mandated from the top (“everyone must use the new deployment pipeline”)
  • Developers complain but have no alternative
  • Platform team gets defensive (“developers just don’t understand the value”)
  • Silos form as developers build shadow systems to work around platform

Scenario B: Platform PM exists

  • Platform treated as an internal product with users (developers)
  • PM does Jobs-To-Be-Done interviews with engineering teams
  • Platform team measures adoption rates, velocity impact, satisfaction scores
  • Features are prioritized by user value, not technical elegance
  • Developers voluntarily adopt because it solves real problems

The difference is product discipline, not organizational structure.

Platform-as-a-Product Prevents Silos

When you treat platform as a product:

:bar_chart: You measure the right things:

  • Voluntary adoption rate (not mandate compliance)
  • Time-to-first-deployment for new engineers
  • Developer satisfaction (NPS for internal users)
  • Support ticket volume by platform area

:bullseye: You focus on user outcomes:

  • “Reduce deployment time from 45 min to 5 min” (developer outcome)
  • Not “Migrate to Kubernetes” (platform team goal)

:counterclockwise_arrows_button: You create feedback loops:

  • Regular user research with product engineering teams
  • Public roadmap with voting on priorities
  • Usage analytics inform what to build next

The Org Structure Question

Luis asked where Platform PM should sit. In my experience, two models work:

  1. Platform PM reports to VP Engineering alongside platform team lead

    • Pro: Close collaboration with platform engineers
    • Con: Can become too technically focused

  2. Platform PM reports to Head of Product alongside product managers

    • Pro: Product discipline and user focus maintained
    • Con: Can lack technical depth needed for platform work

At our company (Series B, 80 engineers), we do #2 and it works well because the PM acts as the bridge between product teams and platform engineers.

The Unified North Star

Michelle’s right that coordination mechanisms matter. But here’s what I’d add: A unified north star metric prevents silos better than org structure alone.

For platform teams, that north star should be: Developer productivity (measured by deployment frequency, lead time, MTTR, etc.)

When DevEx, Security, and Observability teams all optimize for the same outcome, specialization doesn’t create silos—it creates focused expertise working toward a common goal.

Bottom Line

You can have seven specialized platform roles and not have silos if you have product discipline.

The Platform PM is the role that ensures specialization serves user needs, not just technical elegance.