Time to Fill Developer Roles Will Double in 2026—But 90% of Enterprises Already Have Internal Developer Platforms. If Infrastructure Is Solved, Why Can't We Find Platform Engineers?

eng_director_luis · April 5, 2026, 9:21am

Time to Fill Developer Roles Will Double in 2026—But 90% of Enterprises Already Have Internal Developer Platforms. If Infrastructure Is Solved, Why Can’t We Find Platform Engineers?

I’ve been trying to hire two platform engineers for my team for the past 14 weeks. Our financial services company already has an internal developer platform—we’re not building from scratch. We use standard tools: Kubernetes, ArgoCD, Terraform, the usual suspects. Yet our time-to-fill has stretched from 6-8 weeks last year to what looks like it’ll be 16+ weeks this year.

According to Waydev’s 2026 report, time to fill developer roles will double in 2026. That tracks with what I’m seeing. But here’s what doesn’t make sense: platform engineering adoption hit 80% this year, up from 45% just four years ago. Nearly 90% of enterprises now have internal developer platforms.

If everyone has platforms, why can’t anyone find platform engineers?

The Skills Gap Nobody Saw Coming

The challenge isn’t that the role is new—it’s that we created an entire discipline faster than universities or bootcamps could train for it. Platform engineering emerged from the intersection of:

DevOps practices (which itself was only a decade old)
Distributed systems expertise (traditionally backend-heavy roles)
Developer experience thinking (often product management adjacent)
Cloud-native infrastructure (constantly evolving)

You need someone who understands infrastructure and developer workflows and product thinking. That’s not a profile you find on LinkedIn with a simple search.

Are We Competing for a Pool That Doesn’t Exist?

My theory: the 80% platform engineering adoption rate created demand that outpaced supply by an order of magnitude. We’re all fishing in the same pond of:

Former SREs who shifted focus to developer experience
Senior backend engineers who got into Kubernetes early
DevOps engineers who understand product thinking

That’s maybe 5-10% of the engineering workforce? And now 80% of companies want them.

Research shows that developer career ladders are evolving rapidly in 2026, but platform engineering as a distinct career path is still being defined. Most job descriptions I see are a Frankenstein’s monster of SRE + DevOps + Product Manager responsibilities.

What Are We Actually Hiring For?

I went back and looked at my job posting. Honestly? I’m asking for:

Infrastructure as code expert
Kubernetes wizard
CI/CD pipeline architect
Developer experience designer
Documentation writer
Internal tooling evangelist

That’s not one role. That’s three roles pretending to be one.

The Questions I’m Wrestling With

Are we creating specialties faster than the talent pipeline can support? Platform engineering went from niche (2020) to mainstream (2026) in 6 years. That’s faster than most engineering degrees.
Should we be training existing engineers instead of hiring externally? But training takes 6-12 months, and leadership wants the platform now.
Is the role definition too broad? Should we split “platform engineer” into infrastructure-focused vs. developer-experience-focused tracks?
Are we pricing ourselves out? The U.S. Bureau of Labor Statistics projects global shortages hitting 85 million by 2030. When supply is that constrained, compensation has to adjust—but our budgets were set assuming 2024 market rates.

What’s Working (or Not) for Your Team?

If you’re hiring platform engineers:

What’s your actual time to fill?
Are you training internally or hiring externally?
How are you defining the role?

If you’re in platform engineering:

How did you break into this specialty?
What skills actually matter day-to-day vs. what job descriptions ask for?

We solved the infrastructure problem with platforms. Now we need to solve the talent pipeline problem the same way—with systematic thinking, not just “hire harder.”

What’s your take?

cto_michelle · April 5, 2026, 9:22am

This resonates deeply. We’re facing the same challenge at my SaaS company—except we’re also still building our platform while trying to hire the team to run it.

The Talent Math Doesn’t Work

Luis, you nailed it with the “three roles pretending to be one” observation. I’ve been tracking our hiring data:

2024: Posted 2 platform engineering roles, filled both in 8 weeks
2026: Posted 4 platform engineering roles, filled 1 in 18 weeks (3 still open)

The shift happened fast. And you’re right about the competitive landscape—we’re not just competing with other tech companies. Financial services, healthcare, retail—everyone adopted platform engineering simultaneously. The 80% adoption rate means 80% of companies are fishing in the same talent pool.

We’re Training Internally (Out of Necessity)

After 6 months of failed external hiring, we pivoted to an internal training program:

Identify strong senior backend engineers who show curiosity about infrastructure
Pair them with our one experienced platform engineer (who’s now spending 40% of their time mentoring instead of building)
Give them real projects with guardrails—not just “read the docs”
6-month rotation—if it doesn’t click, no hard feelings

Early results: 2 out of 3 engineers stuck with it. One went back to backend (preferred application logic over infrastructure). The two who stayed are productive but not yet senior-level.

The Trade-Off Nobody Talks About

Here’s the uncomfortable truth: training delays your platform roadmap by 6-12 months. Leadership wanted our developer portal live Q1 2026. We’ll be lucky to hit Q3 because our team is half-staffed with engineers who are still learning.

But what’s the alternative? Wait another 6 months for perfect external hires who might not exist?

What Actually Matters in Platform Engineering

After watching our internal training program, I’ve realized the job descriptions are wrong. The skills that matter most:

Systems thinking (can they see the whole developer journey, not just infrastructure?)
Empathy for developers (do they want to solve DX problems, or just build cool infrastructure?)
Communication (can they explain complex systems to product engineers?)

Technical skills—Kubernetes, Terraform, CI/CD—are teachable in 3-6 months. Systems thinking and developer empathy? You either have it or you don’t.

We’ve been screening for the wrong things.

My Take on Your Questions

Should we be training existing engineers instead of hiring externally?

Yes—but not as a replacement for external hiring. Do both. External hires bring experience. Internal training builds institutional knowledge. You need both.

Is the role definition too broad?

Absolutely. We’re splitting platform engineering into two tracks:

Infrastructure Platform Engineers (Kubernetes, cloud, reliability)
Developer Experience Engineers (tooling, workflows, docs, evangelism)

Different skills, different career ladders.

Are we pricing ourselves out?

Yes. Our comp bands were set in 2024. We had to create a “Platform Engineering - Staff” level that didn’t exist before, with 20% higher comp than Staff SWE. Finance pushed back hard. I showed them the cost of 6 months of delays.

They approved it.

The Systemic Fix

You’re right that we need “systematic thinking, not just hire harder.” Here’s what I’m proposing to our board:

Partner with 2-3 bootcamps to create platform engineering curricula (we’ll provide real-world projects)
Sponsor internal training rotations (engineers spend 20% time on platform projects for 6 months)
Redefine the role (split infrastructure vs DX tracks)
Adjust comp bands (acknowledge market reality, not 2024 assumptions)

The talent pipeline problem is solvable—but it requires investment in training infrastructure the same way we invest in platform infrastructure.

We can’t “hire harder” our way out of an 85 million global talent shortage.

vp_eng_keisha · April 5, 2026, 9:23am

Michelle’s internal training program resonates—we’re doing something similar at our EdTech startup. But I want to push back on one assumption in this thread: the idea that we’re “solving” a talent shortage.

I don’t think we have a talent shortage. I think we have a recognition and opportunity problem.

The Talent Exists—We’re Just Not Looking in the Right Places

My platform engineering team has 6 people:

1 former SRE (traditional path, hired externally)
2 backend engineers we trained internally (Michelle’s model)
1 former DevRel advocate who wanted more technical depth
1 bootcamp grad who built their portfolio on personal Kubernetes projects
1 Black woman engineer who was stuck in QA because nobody would give her an infra opportunity

That last one is the story I want to focus on.

We’re Filtering Out Talent at the Resume Screen

Amber (not her real name) was in QA for 3 years at her previous company. Solid engineer, but every time she expressed interest in infrastructure work, she got the “we need you where you are” response. She was maintaining test infrastructure—literally running CI/CD pipelines—but couldn’t get an SRE title because she didn’t have “infrastructure experience.”

Classic catch-22.

I hired her as a platform engineer because:

She had deep understanding of CI/CD (from a QA perspective)
She was obsessed with developer pain points (every flaky test was a DX problem to her)
She taught herself Terraform on weekends and built a personal homelab

She’s now one of our strongest platform engineers. But traditional hiring processes would filter her out at the resume screen—“3 years QA, no platform engineering experience, pass.”

The Diversity Angle Nobody’s Talking About

Luis, you mentioned you’re active in SHPE. I’m active in several Black women in tech communities. And here’s what I see:

Underrepresented engineers get stuck in “support” roles—QA, technical writing, customer engineering—that teach them infrastructure skills but don’t give them infrastructure titles.

Then when platform engineering becomes the hot specialty, they don’t have the “right” resume to get past automated filters.

Meanwhile, we’re all complaining about talent shortages.

Michelle’s Right About Split Tracks—But Let’s Go Further

Michelle proposed splitting platform engineering into two tracks:

Infrastructure Platform Engineers
Developer Experience Engineers

I love this. But I’d add a third pathway: apprenticeship.

We launched a 9-month “Platform Engineering Apprenticeship” program:

Cohort model: 3 engineers at a time
Structured curriculum: 50% learning (formal training), 50% real projects (with mentorship)
Intentionally diverse: We recruit from non-traditional backgrounds (QA, customer engineering, bootcamps, career changers)
Clear success criteria: At 9 months, you’re either promoted to full Platform Engineer or the fit wasn’t right (and we help you find a better role)

Results so far: 2 cohorts completed (6 engineers total). 5 stayed in platform engineering. 1 switched to product engineering (turns out they loved DX from the product side, not the infrastructure side).

What About the Time-to-Value Problem?

Luis, you’re waiting 14 weeks to fill roles. Michelle’s internal training takes 6 months. My apprenticeship is 9 months.

None of these solve the immediate staffing need.

Here’s my controversial take: If your platform is so complex that it requires 6+ months of training, your platform has a design problem.

Good DevEx principles apply to platform engineering teams too:

Can a new engineer make a meaningful contribution in week 1? (Documentation improvements, developer interviews)
Can they ship a small feature in week 4? (Add a new integration, improve a workflow)
Can they own a subsystem in month 3? (CI/CD, secrets management, monitoring)

If the answer is “no” to all three, you’re not building a platform—you’re building a cathedral. And cathedrals take decades.

The Questions I’m Wrestling With

How many qualified candidates are we filtering out because they don’t have the “right” job titles? What if we screened for problem-solving and learning agility instead of “5 years Kubernetes experience”?
What if the talent shortage is partly self-inflicted? If everyone demands senior platform engineers with specific experience, nobody is creating entry-level platform engineering roles. No entry-level roles = no pipeline.
Who benefits from declaring a “talent shortage”? Higher salaries? External consulting firms? I’m not saying it’s a conspiracy, but incentives matter.

What’s Actually Working for Us

Our hiring now focuses on:

Problem-solving over credentials: Take-home exercise shows systems thinking
Developer empathy over technical depth: Can you interview 5 developers and synthesize their pain points?
Learning agility: Teach us something complex in 5 minutes (your choice what)

We’ve hired 4 platform engineers this way in the past 6 months. Time-to-fill: 8-10 weeks.

Not 14+.

The talent exists. We just need to recognize it, train it, and give it opportunities instead of demanding 5 years of experience in a field that’s only been mainstream for 3 years.

maya_builds · April 5, 2026, 9:24am

Okay, I’m coming at this from a totally different angle as someone who leads design systems (which is basically “platform engineering but for design”). And honestly? You’re all making the same mistake we made 5 years ago.

Design Systems Had This Exact Problem in 2020

When design systems became a “thing” around 2019-2020, companies scrambled to hire “Design Systems Engineers.” Job descriptions looked like:

Expert in React component architecture
Deep understanding of design tokens and theming
Figma/Sketch API knowledge
Accessibility expert (WCAG 2.1 AA minimum)
Strong communication skills to work with designers
Documentation wizard

Sound familiar? It’s the same “three roles pretending to be one” problem Luis called out.

Here’s what happened:

Nobody could find these unicorns
Companies poached each other’s design systems engineers (I got recruited 8 times in 2021)
Comp inflation went crazy (I got a 40% raise by switching companies)
Eventually, smart teams realized they needed to build design systems teams, not hire them fully formed

What Actually Worked: The “Core + Contributors” Model

The design systems world figured out you don’t need a team of 10 specialists. You need:

1-2 Core Platform Engineers (your infrastructure experts)

Own the build/release pipeline
Maintain the technical architecture
Set standards and review PRs

+

A network of “contributor” engineers across product teams

They’re product engineers who contribute 20% time to design systems
They build components for their own product needs
Core team reviews and helps refactor for general use
They get credit/recognition for platform contributions

This model scaled our design system from 3 dedicated engineers (who couldn’t keep up) to effectively 3 core + 12 contributors (who could).

Platform Engineering Can Steal This Playbook

Instead of trying to hire 8 platform engineers, what if you:

Hire 2-3 experienced platform engineers (your “core team”)
Create a Platform Contributors program (product engineers contribute 20% time)
Make platform contributions a promotion criterion (incentivize participation)
Build community and recognition (monthly demos, internal tech talks, contributor leaderboards)

The “contributors” don’t need to be platform experts. They need to:

Understand their team’s developer pain points
Have enough infrastructure knowledge to propose solutions
Learn from the core team’s code reviews

Over time, some contributors become core team members. That’s your talent pipeline.

The DX Paradox

Here’s the thing that bugs me about this whole thread: Platform engineering is supposed to make developers’ lives easier. But if your platform is so complex that it takes 6-9 months to train someone, you’re failing at DX.

Keisha mentioned this—if new engineers can’t contribute in week 1, your platform has a design problem.

In design systems, we call this “dogfooding.” If our design system is so complex that designers can’t use it without engineering support, the system failed, not the designers.

Same principle applies here. If your platform requires 6 months of training, maybe the platform needs better docs, simpler abstractions, or clearer golden paths.

What I’m Seeing in Product x Platform Collaboration

My team (design systems) works closely with our platform team. Here’s what I’ve observed:

Platform engineers who succeed:

Treat product engineers as customers, not just “users”
Spend more time on DX (docs, error messages, onboarding) than infrastructure
Run regular office hours and demos
Measure success by “time-to-first-successful-deployment” not “infrastructure uptime”

Platform engineers who struggle:

Love building cool infrastructure more than solving developer problems
Write docs as an afterthought
Get frustrated when “product engineers don’t understand Kubernetes”
Measure success by technical metrics that don’t map to developer happiness

The skill you’re actually hiring for is product thinking applied to infrastructure. That’s the rare combo.

My Practical Suggestion

Instead of posting another “Platform Engineer - Senior” job req that’ll take 16 weeks to fill, try this:

Option 1: Hire a technical product manager

They understand infrastructure enough to collaborate with engineers
Their whole job is understanding user needs (in this case, developer needs)
They can ruthlessly prioritize platform features based on developer impact
Platform engineers can focus on building, not deciding what to build

Option 2: Hire a DevRel engineer

They already think about DX from a user perspective
They’re great at docs, demos, and internal evangelism
They can learn infrastructure (it’s teachable in 3-6 months)
They bring a “how will developers experience this?” lens

Option 3: Steal from design systems

Hire 1-2 experienced platform engineers as “core team”
Launch a Platform Contributors program (20% time model)
Build community, recognition, and clear contribution paths
Pipeline problem solved

The Meta Question

Why is “platform engineer” even a separate job title?

In design systems, we don’t hire “design systems engineers” anymore. We hire:

Frontend Platform Engineers (build/infra for design systems)
Component Engineers (React/Vue/whatever experts)
Design Engineers (bridge design and code)

Each role has a clear definition. Each has a learnable skill set.

Maybe “platform engineer” is too broad because it’s trying to be everything. Michelle’s idea to split Infrastructure vs Developer Experience tracks makes way more sense.

Or maybe the endgame is: every engineer should have platform skills, just like every engineer should understand basic DevOps. Then “platform engineering” is a specialty, not a separate career track.

Just thinking out loud here

But seriously—if design systems figured this out in 2020-2022, platform engineering can figure it out in 2026. The playbook already exists.