Author: Mae Price

The Headcount Paradox: We Built It, But They Didn’t Come

Here’s something that keeps me up at night, and I suspect it’s keeping your VP of Engineering up at night too. Gartner called it back in 2023: by 2026, roughly 80 percent of large organizations would spin up dedicated platform engineering teams. They nailed that forecast. Walk into any sufficiently complex engineering org today and you’ll find them. Dedicated team, budget line, Slack channel, the whole setup. The problem is that none of this actually guarantees developers will use the thing.

We’ve created a curious inversion of the usual tech adoption curve. Instead of building something and watching people gradually discover its value, we’ve built the whole infrastructure, hired the teams to maintain it, established governance around it, and then watched developers find creative ways to bypass it. I’ve been in rooms where a platform team proudly demos their new microservices deployment workflow to an audience of engineers who are already three commits deep into their own ad-hoc bash script approach. The disconnect is real.

The irony deepens when you look at the data. Teams with genuinely mature internal developer platforms see deployment frequency that’s roughly 2.5 times higher than those without them, and their change failure rates drop accordingly. The DORA State of DevOps Report 2025 hammers this home with the kind of consistency that makes you wonder why adoption isn’t at 95 percent instead of hovering around 60 percent. But it is, and understanding why requires getting uncomfortable with some uncomfortable truths about how we actually build platforms.

The Cognitive Tax: Why Your Platform Feels Like Homework

I watched a senior engineer spend forty-five minutes last month trying to onboard onto our internal platform. Not trying to deploy something. Not trying to solve a problem. Just trying to understand how to get set up. At the end of it, they looked at me and said, quietly, “I could have written a deploy script in this time.” They weren’t wrong. That’s the moment you realize your platform has a problem that no amount of documentation can fix.

The Puppet State of DevOps 2025 survey uncovered the two reasons developers cite most often for skipping their internal platforms entirely: the cognitive overhead of onboarding, and the simple fact that the platform doesn’t integrate with how they already work. These aren’t minor usability quibbles. These are deal-breakers. A platform that requires developers to learn new abstractions, new terminology, and new workflows before they can ship code isn’t a platform. It’s a tax on velocity.

What makes this particularly frustrating is that it’s fixable, but fixing it requires platform teams to do something counterintuitive: listen to the people who aren’t using the platform. Not the power users. Not the early adopters who find the whole thing delightful. Listen to the people who looked at your beautiful abstraction layer and decided it was faster to kubectl apply their way through the problem. Those developers aren’t lazy. They’re efficient. And if your platform made them less efficient, that’s not a developer problem. It’s a platform design problem.

Backstage, OpenTofu, and the Age of Pragmatism

The CNCF Backstage project page shows you a framework already running in production at over 3,000 companies. That sounds impressive until you do the math. Internal surveys from the community reveal that actual active usage among eligible developers sits somewhere south of 50 percent at most large enterprises. You’ve got this developer portal framework that half your developers have basically ghosted. The platform exists. The infrastructure exists. Technically, adoption exists too, but it’s a statistical ghost.

What’s been more interesting to watch is the migration pattern around Terraform and its various cousins. When HashiCorp got acquired by IBM in 2024, the licensing and pricing shifted in ways that spooked a lot of platform teams. Enter OpenTofu, the open-source fork that hit 4 million downloads per month by early 2026. This tells you something important: developers and platform teams will vote with their feet when they feel squeezed. More importantly, they’ll move toward tools that feel like they’re built with them in mind, not around them.

The lesson here isn’t about specific tools. It’s that the successful platforms in 2026 are the ones that understand their users well enough to get out of the way. Backstage works when it’s not trying to be everything. OpenTofu succeeded because it respected the workflow people were already using. Platforms that enhance existing practices beat platforms that demand new ones. Every time.

What Actually Works: The Unsexy Secret

The platform teams that are winning right now are doing something that sounds almost embarrassingly simple. They’re starting with the workflows developers are already using and adding incremental value on top. No big abstractions. No mandatory rearchitecture. Just one small thing that makes the thing they’re already doing slightly better. Then another small thing. Then another.

This approach feels glacial to platform engineers. There’s no big reveal moment. No architectural elegance to write a conference talk about. But it works because it respects the reality that developers are not waiting around for your perfect platform. They’re shipping code today with the tools they have. If you want them to switch to something new, you need to be so clearly better that the switching cost is worth it, and you need to make that obvious immediately.

The organizations I know that have cracked adoption above 70 percent share a characteristic: they measure what matters. Not platform team throughput or configuration management efficiency or any of the usual platform metrics. They measure developer satisfaction with deployment velocity. They measure time to first commit in a new service. They measure the number of decisions developers have to make before code can ship. And then they obsess over making those numbers better. When you lead with what actually matters to developers, adoption stops being a marketing problem and starts being a natural outcome.

The Conversation Worth Having

If your platform adoption is stuck in the 40 to 60 percent range, the numbers suggest you’ve got one of the best-resourced team problems in engineering. You have the budget, the headcount, the executive support, and the infrastructure. What you might not have is alignment between what you’ve built and what developers actually need. That’s worth investigating with genuine curiosity rather than defensiveness. Your developers aren’t being difficult. They’re being rational actors in a system that hasn’t yet made the new tool obviously better than the old approach.

I’d love to hear what you’re seeing on your end. Are you running a platform team? Are you the developer sitting here thinking all of this sounds familiar? Have you figured out something that actually moved the needle on adoption? Drop me a line. The platform engineering conversation is only interesting if we’re actually being honest about where we are and what’s not working.

The Headcount Paradox Nobody Talks About

By now, you’ve probably noticed that nearly every large engineering organization has a platform engineering team. Gartner called it back in 2023, predicting that 80% of enterprises would have dedicated platform teams by 2026, and they weren’t wrong. Walk into any Fortune 500 tech org and you’ll find someone whose business card says “Platform Engineer.” The problem is that while the headcount materialized right on schedule, developer adoption never quite showed up to the party.

This is where things get interesting. You can build the most elegant internal developer platform, staff it with brilliant engineers, and still watch three-quarters of your team ignore it in favor of their own scripts and workarounds. I’ve seen this pattern repeat enough times across different organizations to know it’s not a bug in execution. It’s a structural problem that most platform teams don’t adequately address until they’re already six months into wondering why adoption is stuck at 40% to 50%.

The teams that actually cracked this problem have something in common: they stopped thinking of adoption as a marketing problem and started treating it like a product problem. That distinction matters more than it probably should.

The Evidence Is Right There in the Data

The DORA State of DevOps Report 2025 dropped some genuinely compelling numbers. Organizations with mature internal developer platforms deploy 2.5 times more frequently and see significantly lower rates of change failures. That’s not marginal improvement. That’s the kind of lift that actually moves the needle on your incident response metrics and gets you out of Friday night firefighting sessions.

But here’s the twist: those numbers are dominated by the organizations that already achieved high adoption. The teams stuck in the middle, the ones with a platform that technically exists but that half their developers actively avoid, don’t see those benefits. They get the cost of maintaining the platform with almost none of the upside. It’s like paying for a gym membership and never going past the lobby.

Take Backstage. The CNCF Backstage project page shows over 3,000 companies running it in production, which is genuinely impressive for an open-source project. Except when you dig into the community discussions and internal case studies, you find that most of those deployments are running somewhere between 30% and 50% active usage among the eligible developer population. Three thousand successful implementations masking a massive adoption ceiling nobody seems comfortable discussing publicly.

Why Developers Are Choosing the Workaround

The 2025 Puppet State of DevOps survey asked a straightforward question: why aren’t developers using the platform? The top two answers were refreshingly honest. First, “too much cognitive overhead to onboard.” Second, “not integrated with our actual workflows.” Notice what’s absent from that list? Philosophical objections to the platform’s existence or fundamental disagreements about its value proposition.

Developers aren’t rejecting internal platforms because they’re fundamentally broken concepts. They’re rejecting them because the friction to adoption exceeds the perceived benefit. A developer’s immediate workflow runs in their IDE, their terminal, and their git client. If your internal platform requires context-switching through a web portal with three layers of navigation and authentication that doesn’t integrate with their usual tools, you’ve already lost half your battle before anyone even tries to use it.

I watched one organization spend eight months building an absolutely gorgeous Backstage implementation. Custom plugins, beautiful UI, integrated service templates, the whole production. Then they watched adoption plateau at 35% because developers still had to log into a separate system, navigate to the service catalog, find their component, and trigger a workflow when they could just run a shell script they’d written three years ago that lived in their home directory. The friction math didn’t work in the platform’s favor.

The winning organizations solved this by moving the platform to where developers already live. GitHub interfaces, IDE extensions, CLI tools that hook into existing command palettes. The adoption curve looks fundamentally different when you reduce context-switching from four steps to one.

The Infrastructure Decisions That Ripple Forward

Here’s something that doesn’t get enough attention in platform engineering discussions: your infrastructure tooling choices have downstream effects on adoption that go far beyond infrastructure itself. HashiCorp’s 2024 acquisition by IBM triggered pricing and licensing changes for Terraform that rippled through platform teams everywhere. A lot of organizations that built their internal platforms on top of Terraform-centric workflows suddenly faced uncomfortable conversations about licensing costs and contractual terms.

That shift pushed significant momentum toward OpenTofu, the open-source fork that hit 4 million downloads per month by early 2026. The technical reasons are solid, but the adoption story matters here too: when a platform team’s foundational tooling becomes a friction point, that friction propagates upward to every developer trying to use the platform built on top of it. Suddenly your onboarding story includes “and by the way, here’s why we switched away from the tool you saw in that blog post.” That’s not a selling point.

The lesson here isn’t about Terraform specifically. Platform decisions that feel like infrastructure concerns actually have direct effects on user experience and adoption. When you’re evaluating the tools and frameworks that will underpin your internal platform, that downstream adoption impact belongs on your evaluation rubric right alongside technical merit and operational overhead.

What Actually Moves the Needle

The platform teams I’ve watched reach 70% to 80% adoption share a few consistent patterns. They obsess over the first-use experience with an intensity that borders on fanatical. They measure activation metrics like they’re tracking production SLOs. They build integrations into existing workflow tools rather than asking developers to add new tools to their already-crowded stack. And they iterate based on actual usage telemetry, not just on feature requests from leadership.

They also tend to accept that 100% adoption probably isn’t realistic or even necessary. The goal isn’t unanimous adoption. The goal is getting adoption high enough that the platform’s positive effects become self-reinforcing. When enough developers are using the platform to drive meaningful deployments and incident response, when that becomes the cultural norm and the workarounds become the outliers, adoption stops being a problem you have to solve and becomes a natural emergent property of your engineering culture.

If you’re sitting in a 40% adoption situation right now, the good news is you’ve already done the hard part. Your platform exists. Your infrastructure is in place. What you’re missing is optimization for human friction, and that’s something you can actually fix. Start measuring adoption like you’d measure any user-facing product. Find three developers who actively avoid your platform and schedule honest conversations with them. Read their feedback as design requirements rather than excuses. That’s where the real work happens.

The Numbers Don’t Lie, But They Do Scream

The CISA Known Exploited Vulnerabilities catalog crossed 1,200 entries in late 2025. That’s not a milestone to celebrate with champagne. It’s a fire alarm you’ve been hearing for three years and finally decided to acknowledge while scrolling through Slack.

Here’s what matters: federal agencies are legally required to patch anything flagged as critical severity within 15 days under BOD 22-01. Fifteen days. In an enterprise of any meaningful size, that’s the time it takes to get through three steering committee meetings, one surprise production incident, and the inevitable discovery that your asset inventory is incomplete. The compliance theater is real. The actual security posture is another story entirely.

What makes this worse isn’t the size of the catalog. It’s the velocity. CISA added 47 actively exploited vulnerabilities in January 2026 alone, including multiple zero-days hitting Palo Alto Networks PAN-OS and Ivanti Connect Secure systems. Both vendors had already released patches. Both. Already. Released. And yet organizations were still discovering exploitation attempts against unpatched instances. This isn’t a supply chain problem. This is a process problem wearing a compliance costume.

The Exploit Window Is Collapsing in Real Time

The median time between CVE publication and active exploitation has compressed to five days as of 2024, down from 32 days in 2021. Let that number sink in. You have a work week. Five business days if you’re optimistic about meeting before Monday rolls around again. The Verizon 2025 Data Breach Investigations Report documents this precisely because this isn’t speculation anymore. This is measured, observed reality.

Most patch management processes were designed for a 90-day cycle. Test in dev, validate in staging, schedule maintenance windows, communicate to stakeholders, execute during a Tuesday at 2 AM when nobody’s looking. That was the playbook when exploits took a month to materialize. Now you’re running a process built for a completely different threat environment. It’s like using a flip phone to respond to urgent messages. Technically possible. Obviously broken.

The worst part: threat actors aren’t waiting for you to get your act together. They’re actively scanning for unpatched instances of known exploited vulnerabilities. They’ve already written the tooling. They’re already automating the reconnaissance. The only variable left is how long your systems stay visible.

You’ve Got 40,000 New CVEs Per Year. Your Triage Team Has Eight People.

The National Vulnerability Database processed over 40,000 new CVEs in 2024. That’s a 38 percent increase from 2022. Your security team’s response to this information was probably to add one more alert feed to your SIEM and call it a day. That works until 3 AM when the pager goes off because something that was supposed to be filtered actually reached your infrastructure.

Automated triage pipelines are buckling under this load. Most organizations are still using keyword matching and CVSS scores as primary filters. That’s a heuristic from 2015. It doesn’t account for asset criticality, compensating controls, or actual exploitability. So you end up treating CVE-2024-XXXX affecting an obscure font rendering library the same as CVE-2024-YYYY affecting your primary authentication infrastructure. Efficiency: zero. Alert fatigue: maximum.

The CISA Known Exploited Vulnerabilities Catalog is supposed to help with this. It does, to a point. But using KEV as your sole intelligence feed means you’re always one step behind. By definition, these vulnerabilities are actively exploited. You’re defending against yesterday’s threats while tomorrow’s are already in the development queue.

The Patch Availability Paradox Is Still Breaking Your Security Model

Here’s the number that should actually keep you awake: 60 percent of breaches in recent studies involved known vulnerabilities where patches had existed for more than 30 days before exploitation. Thirty days. Most organizations have patch windows scheduled monthly. The math here is not complicated. Patches exist. Organizations are breached. The patch was available the whole time.

This isn’t about technical capability. Vendors are shipping patches. Automation tools can deploy them. The blockage is organizational. It lives in change control boards that meet infrequently. It lives in the disconnect between security teams saying “this is critical” and operations teams saying “we have another five critical items already scheduled.” It lives in the fact that nobody’s willing to stake their career on patching without a maintenance window because the last time someone tried that, production went dark for six hours.

The vulnerability disclosure timeline hasn’t changed much. Vendors still operate on their own schedules. But the exploitation timeline has become ruthless. You’re stuck trying to run a careful, deliberate process in an environment that rewards speed and punishes hesitation. The system is optimized for patch management theater, not actual vulnerability remediation.

What Does Actually Matter, Then

Forget compliance metrics for a moment. Forget the KEV catalog milestone. Focus instead on asset visibility, prioritization criteria that actually reflect risk, and patch deployment mechanisms that don’t require seventeen approval layers. Some organizations are running quarterly security validation cycles instead of monthly patches, with real-time vulnerability scanning to catch drift. Others have implemented micro-segmentation to limit blast radius, reducing the urgency of individual patches to a manageable priority level. None of these are silver bullets. All of them work better than pretending you can manually triage 40,000 CVEs per year.

The uncomfortable truth: your patch management process isn’t broken because you lack tools. It’s broken because you’re optimizing for the wrong variables. You’re measuring time-to-patch instead of time-to-safe-state. You’re treating every CVE as equally important instead of letting data about actual exploitation drive your priorities. You’ve built processes that made sense in 2015 and are now wondering why they don’t scale.

The CISA KEV catalog hitting 1,200 entries is just a symptom. The real problem is sitting in your current change control board meeting, where someone’s explaining why a critical patch needs to wait another week for the next maintenance window. That’s where the vulnerability lives. What’s your process actually optimizing for?

The Uncomfortable Truth About Our AI-Assisted Future

After fifteen years of watching junior developers evolve from copy-pasting Stack Overflow snippets to wielding AI assistants like digital Swiss Army knives, I’ve noticed something unsettling. GitHub’s new AI code review assistant has attracted 2.3 million active users in just three months, with an overwhelming 67% being developers with less than three years of experience. That’s not inherently problematic. What keeps me up at night is what happens when these developers hit production issues that their AI assistant can’t solve.

The pattern became clear during a recent incident at 2 AM when a junior engineer on my team couldn’t trace a memory leak through code they’d written with AI assistance just weeks earlier. They could describe what the code was supposed to do but couldn’t explain why it was consuming 400MB per request. When your AI co-pilot becomes your primary navigator, you never learn to read the map yourself.

The Stack Overflow 2025 Developer Survey confirmed what many of us have observed firsthand: 43% of junior developers using AI assistants couldn’t adequately explain core algorithms they’d implemented. These aren’t esoteric computer science concepts. We’re talking about basic sorting algorithms, data structure traversals, and fundamental design patterns that form the bedrock of software engineering.

When AI Reviews Replace Human Understanding

Microsoft’s latest metrics show that teams using GitHub’s AI review tools caught 34% fewer critical bugs during human code review sessions. On the surface, this looks like a win for automation. Dig deeper, and you’ll find the real story: human reviewers are becoming complacent, assuming the AI has already caught the important issues. The result is a dangerous blind spot where both human intuition and AI pattern matching fail simultaneously.

I’ve witnessed this firsthand during code reviews where junior developers present AI-generated solutions they clearly don’t understand. When I ask probing questions about edge cases or performance implications, I’m often met with blank stares or responses like “the AI said this was the best approach.” The problem isn’t that the AI is wrong. The problem is that the developer has given up their responsibility to understand their own code.

Carnegie Mellon’s recent study drives this point home with uncomfortable precision. Junior developers who relied heavily on AI tools scored 28% lower on independent coding assessments compared to their peers who used traditional learning methods. These weren’t trick questions or academic puzzles. These were practical programming challenges that any competent developer should handle confidently after two years of experience.

The most damaging aspect isn’t the immediate performance gap. It’s the confidence gap that follows. Developers who can’t debug their own AI-assisted code begin to doubt their fundamental abilities, creating a vicious cycle where they become even more dependent on AI tools for basic tasks they should have mastered months ago.

The Technical Debt Time Bomb

Atlassian’s engineering team documented something that should terrify every senior engineer: a 45% increase in technical debt when junior developers relied heavily on AI code generation without adequate senior oversight. This isn’t just about messy code or inconsistent naming conventions. We’re talking about architectural decisions that compound over months, creating systems that become increasingly difficult to maintain, extend, or debug.

AI assistants excel at producing syntactically correct code that solves immediate problems, but they lack the contextual understanding to make decisions that help long-term system health. A junior developer might ask an AI to implement user authentication and receive perfectly functional code that introduces three new dependencies, bypasses the existing security framework, and creates a maintenance nightmare for future teams. The AI delivered exactly what was requested, but the developer lacked the experience to request the right thing.

The GitHub Copilot Workspace documentation emphasizes collaboration between human intelligence and AI capabilities, but the reality in most organizations is that junior developers are operating these tools without sufficient guardrails or mentorship. The result is code that works in the short term but creates exponentially more work for senior engineers down the line.

Building Better Developers in the AI Era

The solution isn’t to abandon AI tools. That ship has sailed, and trying to turn back the clock would be both futile and counterproductive. Instead, we need to fundamentally rethink how we onboard and mentor junior developers in an AI-enhanced world. The goal should be creating developers who can leverage AI effectively while maintaining deep technical understanding.

Start by establishing AI-free zones in your development process. Require junior developers to implement core algorithms from scratch before they’re allowed to use AI assistance. Make them trace through their own code line by line during code reviews. When they present AI-generated solutions, don’t just verify that the code works. Ask them to explain the underlying principles, identify potential failure modes, and propose alternative approaches.

Implement pair programming sessions where senior engineers work alongside junior developers, not just reviewing their final output but observing their problem-solving process in real time. This reveals gaps in understanding that wouldn’t surface during traditional code reviews. When a junior developer immediately reaches for an AI assistant to solve a basic problem, that’s a teachable moment.

Create debugging challenges using code that AI assistants typically generate. Present junior developers with AI-written code that contains subtle bugs or performance issues, and have them identify and fix the problems without AI assistance. This builds the critical thinking skills they’ll need when their AI tools inevitably fall short.

The Path Forward for Senior Engineers

We’re at a crossroads where our response will shape the next generation of developers. We can either embrace our role as technical mentors who help junior engineers navigate the AI landscape thoughtfully, or we can give up that responsibility and deal with the consequences later. The choice seems obvious, but it requires intentional effort and a willingness to slow down short-term delivery in service of long-term technical excellence.

The most successful teams I’ve observed treat AI tools like powerful but potentially dangerous equipment. Junior developers earn the privilege of using these tools by first demonstrating mastery of fundamental concepts. They learn to prompt AI assistants effectively because they understand what good code looks like. They catch AI-generated bugs because they’ve trained their instincts through hands-on experience with similar problems.

This isn’t about gatekeeping or nostalgic attachment to “the old ways.” It’s about ensuring that the developers we’re training today will be capable of building and maintaining the complex systems that tomorrow’s problems will demand. AI will continue to evolve and improve, but the need for developers who can think critically about code, debug complex systems, and make sound architectural decisions will never disappear.

What strategies have you found effective for mentoring junior developers in your AI-enhanced development environment? I’d love to hear about both your successes and your failures as we collectively navigate this transition.