The Limitations of Platform Engineering with Vilas Veeraraghavan and Bryan Finster

About Bryan Finster

Bryan Finster is a passionate advocate for continuous delivery with over two decades of experience building and operating mission-critical systems for very large enterprises. He is the founder and former lead for the Walmart DevOps Dojo with hands-on experience both executing continuous delivery for production systems and helping other organizations find and remove the constraints that prevent a CD workflow. Bryan is a co-author of "Modern Cybersecurity: Tales from the Near-Distant Future," and the author of the "5-Minute DevOps" blog on Medium. He currently works for Defense Unicorns, helping to solve the hardest software supply chain problems.

About Vilas Veeraraghavan

Vilas is an experienced Engineering leader who has driven Platform, Product and Developer tooling innovation at Comcast, Netflix, Walmart, Bill and Truckstop building high performance teams that do efficient software delivery of distributed workloads in the cloud, chaos engineering, CI/CD at scale and improving DevEx across the enterprise by enabling engineers to do more with tools. He has deep expertise in varied industries like Media Streaming, Retail, Fintech and the transportation and logistics industry.

The Definition of Platform Engineering

Bryan: To me, platform engineering means: I'm a developer building tools for other developers to help them do their jobs more easily — and make it really hard for them to make mistakes. It means asking ourselves every day, “How do I make it really easy for developers to do their work and really difficult for them to make mistakes?"

VIlas: What matters is are developers’ jobs better now than it was before we existed? If we can’t answer that with confidence, the platform is not delivering. Do we even track how developers' lives have improved since we existed? What is the reason for the platform team to exist? If the reason is to improve the tooling we built last year, that’s not enough.

Platform Engineering vs. DevOps

Bryan: This is a pet peeve of mine. DevOps, in its proper definition, is the union of people, process, and product to deliver continuous value to end users. Platform engineering is just one piece of that, the product piece.

Platform Team as a Police

Vilas: Platform teams are about enabling, not policing. Sometimes they become exactly that, the thou-shalt-not-do-this police. No, you can’t use Jenkins. No, we don’t support that library. You have to use this because we said so.

Bryan: You can’t make users adopt internal tools by force. You have to market your internal platform just like any product. We had t-shirts, stickers, lunch-and-learns. You need internal advocacy and you have to very transparent with engineers about your intentions. I

like the analogy of “paved paths with room for off-roading.” Platform teams create a golden path that’s easy, safe, and well-supported, but leave the door open for teams with good reason to do something different.

Measuring the ROI of Platform Engineering

Vilas: People love saying “we saved 1,500 developer hours.” Cool, and what did those devs do with that time? Did they ship features? Take longer coffee breaks? That metric is meaningless on its own.

Bryan: What really matters is whether you're helping teams deliver value faster and more safely. But that’s hard to measure. It's often lagging indicators — like customer satisfaction or revenue tied to faster delivery.

IDP won't Solve All Your Problems

Bryan: An IDP is just a toolbox to help developers do their jobs more easily. A useful one, if it helps developers get started quickly, find documentation, and request resources without begging on Slack.But a tool is not a platform. A tool does not fix a broken culture, poor communication, or a lack of product thinking. Backstage won’t save you. It worked for Spotify because it solved their problems. You need to understand yours.

Vilas: I think of it as a self-service hub of documentation, tooling, access requests. But companies see Backstage and go, “That’ll solve all our problems.” It solved a specific problem at Spotify. You might not have that problem.

How to Succeed at Platform Engineering

Vilas: When teams are transparent, embedded, and open to feedback. When they listen and reprioritize based on actual developer pain.

Bryan: When platform teams act like real product teams, with goals, roadmaps, customer conversations. When they earn adoption through value, not mandates. You want to know if your platform is any good? Check in a year. The strength of a good platform is only defined by how long it sustains.