48 Hours Left: Seats Go Back to Full Price After

Today’s CloudPro is written by George Hantzaras, Director of Engineering at MongoDB, and a featured speaker at KubeCon and PlatformCon.

In this issue, George shares why most platform teams struggle with adoption: not because of tools, but because they don’t treat knowledge as a product. His insights will help you build platforms that developers actually want to use.

If you want to dive deeper, George will also be leading a hands-on workshop this Saturday, September 27: AI-Powered Platform Engineering. Across five hours, he’ll cover everything from golden paths to AI-driven ops.

Here’s what you’ll walk away with:

Last few tickets left. Don’t miss your chance to learn directly from George and leading platform engineers. Secure your spot now before seats are gone.

Cheers,

Shreyans Singh

Editor-in-Chief

48 Hours Left: Seats Go Back to Full Price After

Cloud ransomware isn't a matter of if, but when. Are you truly ready?

Watch our immersive fireside chat on October 1st @ 9 AM PDT as we unpack a fictional, yet alarmingly realistic, cloud ransomware attack on Horizon Retail.

- By George Hantzaras

Hey everyone,

I've been thinking a lot lately about why some platform teams absolutely nail developer experience while others struggle to get adoption. After working with dozens of organizations, I've noticed something interesting: it's rarely about the tools.

The teams that win treat knowledge as a platform capability. The ones that struggle? They're still playing whack-a-mole with scattered docs and tribal knowledge.

Let me paint you a picture. Your best senior engineer just spent 45 minutes figuring out how to deploy a simple service change. Not because the deployment is hard, but because they couldn't remember which of the three "official" ways actually works, who to ping for approval, and whether the security policies changed since last month.

Sound familiar?

Most platform teams I talk to are obsessed with building the perfect CI/CD pipeline or the most elegant service mesh. But here's what I've learned: if developers can't easily figure out how to use your beautiful platform, you might as well not have built it.

I was working with a team at a mid-sized startup recently. They'd spent months building this gorgeous deployment system with all the bells and whistles. Adoption was terrible. Turns out, the "getting started" doc was three months out of date, buried in Confluence, and written by someone who'd left the company.

The fix wasn't technical. They needed to treat knowledge as a product.

The teams getting this right do four things consistently:

They catalog everything. Not just services, but owners, docs, health metrics, cost data. All searchable, all in one place. Backstage is great for this, but the specific tool matters less than the commitment to making information findable.

They make standards executable. Instead of hoping people read the security guidelines, they bake them into CI/CD. Policies become code that runs automatically and leaves an audit trail. Much harder to ignore a failing pipeline than a Slack reminder.

They productize their knowledge. This is the big one. Take that complex, error-prone workflow that only two people really understand and turn it into a golden path that anyone can follow. Start small. Maybe it's just a better way to set up CI/CD, but treat it like a product with real users and feedback loops.

They keep Git sacred. Discovery happens in the portal, but changes flow through Git. Period. Whether you go with one big monorepo or team-owned repos doesn't matter as much as consistency and reviewability.

Here's something I'm excited about: when you get the knowledge foundation right, AI becomes incredibly powerful. Not in a "replace developers" way, but in a "supercharge the platform" way.

All that clean, structured context in your service catalog? Perfect retrieval corpus for RAG systems. Those golden paths you built? They become scaffolding for AI-generated suggestions that actually make sense in your environment. Your Policy as Code setup? Natural guardrails for AI-proposed changes.

I'm seeing early experiments where AI can draft infrastructure PRs that pass all your checks because it understands your actual standards, not just generic best practices.

The measurement piece is crucial. DORA metrics are great, but they're lagging indicators. I'm more interested in leading signals: How long does it take a new engineer to make their first production deploy? What's your golden path adoption rate? How often do teams bypass your "blessed" workflows?

Track this stuff in your developer portal, not some executive dashboard. Make the feedback loop as tight as possible.

You don't need to boil the ocean. Pick one workflow that causes the most pain, usually it's CI/CD setup or production deployments, and make it bulletproof. Document it, template it, instrument it. Then expand from there.

The teams that succeed start with developer empathy, not technical architecture.

I'll be diving much deeper into all of this at our upcoming workshop, including some real-world examples from teams who've made this transition successfully. We'll look at specific implementation patterns, common pitfalls, and how to measure success.

If your platform team is struggling with adoption, or if you're curious about the AI angle, I'd love to see you there.

Talk soon,
George

48 Hours Left: Seats Go Back to Full Price After

📢 If your company is interested in reaching an audience of developers and, technical professionals, and decision makers, you may want toadvertise with us.

If you have any comments or feedback, just reply back to this email.

Thanks for reading and have a great day!