For the past eight years, PlatformEngineering.org has been the place enterprise platform teams come to figure out what to do next. Thousands of practitioners have come through our training and certifications, and hundreds of enterprises have benchmarked against our State of Platform Engineering report. PlatformCon has grown into the largest gathering of platform engineers in the world. Much of what the discipline now takes for granted was named here first.
We have seen the patterns. The same five mistakes show up in financial services, healthcare, retail, hi-tech, telco, automotive, and manufacturing — same mistakes, different industry:
- No product thinking. No defined users, no roadmap, no adoption metric. The backlog is a ticket queue, not a product roadmap. When users are defined, they're treated as one undifferentiated group without domain awareness, or bounded contexts. The data team, the payments team, and the ML team get the same toolchain that fits none of them well.
- No business case. Can articulate engineering value, not business value. Leadership funds the work for a year, then quietly stops asking. The team becomes invisible right before it becomes vulnerable.
- Tool-first. Vendor solutions adopted before the problem is named. A stitched-together stack that nobody can explain end-to-end. Procurement decisions making the architecture by accident.
- Wrong measurement, or none. Reporting deployments per day instead of business outcomes. Or measuring nothing because "platform is hard to measure." Adoption flat, leadership skeptical, no narrative to defend.
- Skipping the foundation before scaling. Adding AI workloads, agents, or self-service onto a platform that hasn't earned the right to support them. Governance, identity, observability gaps compound. The thing that breaks in year three was decided in year one.
Avoiding these five is the line between the platform initiatives the leadership funds and the ones leadership stops asking about. We've also learned which vendor pitches survive contact with a real enterprise codebase and which ones don't. That's why we keep getting the same calls: we know what to build, we just need someone who has seen this before to tell us we're on the right track.
For a long time, the answer was a workshop, a course, or a community introduction. That was enough when the question was "how do we run a platform as a product?" or "how do we measure adoption?"
The agentic shift has changed what enterprise platform teams are being asked to do. AI mandates land on platforms that were not built to support them. Governance, identity, and sandboxing, all the components that made the deterministic platform work, will no longer transfer cleanly to a world where probabilistic systems write production code. And they break worse on platforms built as one shared substrate for everyone. Agentic workloads expose every domain boundary that was assumed away: identity per agent, blast radius per domain, validation loops that look different in payments than in ML. Leadership wants a roadmap. The platform team has a six-month backlog and no time to invent that roadmap from scratch. The vendor in the room is selling them a piece of the answer and calling it the whole answer.
Platform engineering consulting based on decades of experience
Platform Engineering Consulting grew out of that work. PEC is the consulting and advisory wing of PlatformEngineering.org. You can learn all about PEC by visiting our website pec.platformengineering.org.
Same people, same body of work, same vocabulary, pointed at engagements that are too specific for a course and too consequential for a community thread. Diagnostic calls, maturity assessments, business case sprints, and embedded advisory.
We've spent decades building these systems before we ever wrote about them. We led platform organizations through every wrong turn the industry has now packaged into best practice. We've shipped infrastructure, run engineering orgs, sat on the vendor side through enterprise procurement, and helped enterprises course-correct after a platform decision made two years prior turned into the thing blocking them. That's the substrate. Everything else we're known for (the State of Platform Engineering data, the certifications, the publications, the maturity frameworks) was built on top of it.
Most consultancies have one of those two layers. The long-view ones tend to be a year out of date by the time they engage. The current-view ones don't have the scars yet. We do something different: put the practitioner who would have built this thing in the room, and have them stay there.
Our leadership team is small and specific. Kaspar von Grünberg coined the term Internal Developer Platform and built the community that turned it into a discipline. Mallory Haigh runs the education and certification programs that have credentialed thousands of practitioners, and coaches teams using the frameworks out in the wild. Luca Galante and Sam Barlien keep us close to where the community is heading next. Rachael Wilhite runs partnerships. I, Ajay Chankramath lead this initiative as the CTO. I’ve built systems, infrastructure, and led developer experience transformation across multiple industry verticals as both a product leader and an advisor over the past four decades. While I have also been an author or co-author of a few of the platform engineering books along the way - Platform Engineer's Handbook, Effective Platform Engineering, and Domain-Driven Platform Engineering - that have found their way into enterprise learning and enablement programs, the work I'm proudest of is the time I've spent sitting with platform teams trying to figure out their next move and helping them get there.
You'll see us at all the PlatformCon live days and the regional live events throughout the year. These rooms are where the discipline keeps getting written: platform teams comparing notes on what's working, what isn't, what's about to land. We bring back what we're seeing: the bleeding-edge solutions emerging across client engagements, the patterns surfacing across the community, the problems that don't yet have a name. Building the community forward is part of our DNA which we will double down on.
If you are a platform leader making sense of the agentic shift, building the business case for a multi-year program, or working out which AI capabilities your platform actually needs to support, we'd like to hear from you.
We are not the only people who can help. But we named this discipline, we've watched the agentic shift coming for two years, and we are in the room with the enterprise platform teams working it out right now.
Take the Platform Maturity Assessment or book a call if you’d like to talk it through.
