In a landscape where software delivery expectations are constantly rising, the gap between development and operations has never been more challenging to bridge. Cory O'Daniel, CEO and co-founder of MassDriver, brings over 20 years of experience in DevTools, SRE, and Platform Engineering to address this critical issue. In a candid conversation on the Dev Interrupted podcast, O'Daniel shares insights on why traditional DevOps approaches are failing many organizations and how platform engineering offers a potential path forward.
Developer Experience: The Declining Operations Expertise Problem
One of the most pressing challenges in software development today is the widening knowledge gap between development and operations. As more developers enter the field, many lack the foundational understanding of cloud infrastructure and operations that previous generations acquired.
"The amount of operations experts or expertise that we have as a community is going down year over year because we're making so many developers, you know, out of bootcamps, out of colleges and whatnot now, and we're not teaching them the cloud and operations," O'Daniel explains.
This knowledge gap creates a fundamental disconnect. While organizations expect developers to take on more operational responsibilities (the "shift-left" movement), these developers often lack the training and experience to handle these tasks effectively. The result is frustrated developers who struggle to deliver their primary value: building features.
O'Daniel argues that this approach fundamentally misunderstands what developers are hired to do: "Shifting everything left onto the developer isn't working. It's not what you pay them to do. You pay them to build features, to build, generate revenue."
A strong developer experience should enable developers to ship code on their first day, focusing on creating features rather than wrestling with operational complexities. Organizations that achieve this balance create environments where developers can thrive, focusing on their core strengths while having appropriate operational support.
Software Delivery Speed: The 30-Day Deployment Reality
Despite years of DevOps adoption, many organizations still struggle with lengthy deployment cycles. The data reveals a sobering reality about the state of software delivery.
"50 percent of the respondents that are tuned into responding to this report say that an outage can last them up to five days, and the average time of deploying software sits around once every 30 days," O'Daniel notes, referencing the DORA report findings.
This statistic highlights a significant gap between DevOps ideals and implementation reality. While elite teams might deploy multiple times per day, half of organizations are still operating on monthly deployment cycles. This disparity suggests that many DevOps initiatives have failed to deliver on their promises of accelerated delivery.
When measuring platform engineering success, O'Daniel recommends focusing on developer enablement: "Dev happiness and how unblocked people are, like that's in the grand scale of things. I think that's what really matters."
Rather than focusing solely on technical metrics, organizations should measure how effectively their platform removes obstacles for developers. Elite teams should aim for code-to-production times of 24 hours or less, but organizations should start with incremental improvements to their delivery processes before attempting larger platform engineering initiatives.
Want to measure your team against industry benchmarks? Download the 2025 Software Engineering Benchmarks Report below:
Technical Debt Management: Refactoring as Part of Feature Delivery
Technical debt often accumulates in deployment processes, creating significant barriers to efficient software delivery. O'Daniel advocates for a pragmatic approach to addressing this debt.
"If you can do what they ask and in the meantime, like you've delivered some success, that's good. And talk about it. Be like, Hey, I refactored this. I went in and added this caching thing that makes our builds faster," he advises.
This approach embeds technical debt management into regular feature development, rather than treating it as a separate initiative that requires special approval. By addressing technical debt while delivering requested features, engineers can demonstrate the tangible benefits of these improvements.
O'Daniel emphasizes that addressing technical debt is part of professional engineering responsibility: "We should be addressing technical debt and refactoring that's in our way." He suggests measuring improvement in delivery time (e.g., "increased delivery time by 20%") to demonstrate the value of addressing technical debt to stakeholders.
Many platform engineering initiatives begin by addressing accumulated technical debt in deployment processes. By starting small and demonstrating value, engineers can build momentum for larger improvements.
Scaling Operations Expertise: The Critical Shortage
Perhaps the most significant challenge facing organizations today is the shortage of operations expertise as companies scale. This shortage has led to concerning practices in hiring and team structure.
"Everybody needs them. A lot of organizations struggle to hire them. A lot of people are just hiring people straight out of college and saying you're the DevOps person now," O'Daniel observes.
This practice of placing inexperienced graduates directly into DevOps roles creates significant risk. Without proper mentorship and training, these new engineers are expected to manage complex infrastructure that directly impacts business operations.
O'Daniel frames platform engineering as a solution to this expertise scaling problem: "We need to scale those people. That's our scaling problem in 2024. It's not scaling compute." By creating platforms that encode operational best practices and provide self-service capabilities, organizations can extend the impact of limited operations expertise across larger development teams.
Different teams within an organization may need different platform approaches based on their specific needs. A one-size-fits-all approach to platform engineering often fails to address the diverse requirements across an organization.
The Future of Platform Engineering
As organizations look to improve their software delivery capabilities, platform engineering has emerged as a potential evolution of DevOps. However, O'Daniel cautions against viewing it as a silver bullet.
"Platform engineering is infrastructure provisioning, being a part of it, talking about the cloud, talking about getting self-service of cloud resources, which wasn't like the terms that we were using 15 years ago," he explains.
While Internal Developer Platforms (IDPs) are gaining popularity, O'Daniel warns against overestimating their impact: "IDPs are important. I think they're valuable... But I feel like there's a lot of people that are just like, Oh, if I get an IDP, that's going to solve my problems. And it's like, no, no, it's not."
The most effective platform engineering initiatives start small, address specific pain points, and demonstrate value before expanding. By focusing on developer happiness and removing obstacles to productivity, platform engineering teams can create meaningful improvements in software delivery capabilities.
Moving Beyond Buzzwords
Whether you call it DevOps or platform engineering, the fundamental goal remains the same: enabling developers to build and deliver software efficiently. The terminology matters less than the outcomes – faster delivery, happier developers, and more reliable systems.
As operations expertise becomes increasingly scarce, organizations must find ways to scale this knowledge through platforms and tools. By focusing on removing obstacles for developers and addressing technical debt incrementally, teams can improve their delivery capabilities without getting caught up in buzzwords and trends.
The path forward isn't about adopting a particular methodology or tool – it's about understanding your organization's specific challenges and addressing them pragmatically. As O'Daniel suggests, start by making small improvements, demonstrate their value, and build from there. In the end, what matters most is creating an environment where developers can focus on what they do best: building features that deliver value to customers.
Listen to Cory’s full Dev Interrupted episode here:
