Paving the Path for Platform Engineers: Strategies for Success

Instead, let’s talk about what platform engineering is really about—building less, enabling more, and delivering real value to your teams. Because if you’re not treating your platform like a product, you’re already doing it wrong.

You’re Not Building the Platform. Everyone Else Is.

If you think being a platform engineer means building the whole thing yourself, let me stop you right there. You can’t. And even if you could, you shouldn’t.

Your job isn’t to build a monolithic tower of tech. That would mean that you know everything about everything. No one does. Your job is to create the scaffolding that lets everyone else plug in their expertise. Got a database guru in the basement? Enable them to turn their knowledge into a self-service database offering. Someone loves networking? Great—help them build networking-as-a-service. Your job is to connect the dots, not draw the whole picture.

The moment you try to do it all yourself, you’re sunk. So stop pretending you’re the hero and start enabling others to shine.

Start Small, or Start Failing

One of the biggest mistakes I see? Trying to boil the ocean. You don’t need to solve every problem for every team on day one. Start with an MVP—a minimum viable platform. Focus on one or two high-impact use cases, deliver real value, and grow from there.

Think of it like a startup. Early adopters are your biggest asset. Find the teams that are desperate for a solution, give them what they need, and use their success to build momentum. They’ll become your champions. Everyone else? They’ll come around once they see it works.

Oh, and mandates? Don’t bother. If your platform is only getting used because the CTO said so, congratulations: you’ve built a product no one actually wants.

It’s Not About Tools. It’s About Outcomes.

Let’s talk about tools. Everyone loves to talk about tools. Kubernetes! Backstage! Crossplane! The CNCF landscape is basically an all-you-can-eat buffet of shiny things. But let me break it to you: tools aren’t the platform.

Picking tools is just step one. What really matters is how you use them. Backstage doesn’t magically solve your developer experience problem. Crossplane won’t configure itself. You still need to build the plugins, compositions, and workflows that make these tools useful for your organization.

Reference architectures like CNOE are a good start, but they’re not a shortcut. You’ll still need to do the work to tailor the platform to your specific needs. Sorry, no easy buttons here.

Security, Developer Experience, and the Myth of “Perfect Balance”

"How do we balance security and developer experience?" I hear this a lot. The answer is: you don’t. You prioritize outcomes.

Policies and guardrails are essential, but they shouldn’t feel like roadblocks. Tools like Kyverno can enforce best practices—like ensuring signed container images—while empowering developers to innovate within safe boundaries.

However, as I pointed out, blocking actions isn’t enough. “Policy violations are signals. They tell you there’s an education gap. Use them to teach developers why something is restricted and how to fix it.”

The goal isn’t a frictionless developer experience. The goal is to make the right thing the easiest thing. And if your developers are spending more time complaining about your platform than using it, you’ve missed the mark.

Crossplane and Upbound

As I mentioned earlier, a platform engineer’s job isn’t to build everything—it’s to create the scaffolding that enables others to contribute their expertise. That’s where tools like Crossplane come in. Crossplane makes it easier to turn Kubernetes into a platform that teams can build on. It lets you compose the abstractions and workflows that your organization actually needs, without reinventing the wheel every time.

At Upbound, we’re all about helping platform engineers focus less on plumbing and more on delivering outcomes. With Crossplane, you can create self-service infrastructure and standardize workflows, freeing teams to innovate within guardrails you define. It’s the perfect example of enabling—not enforcing—the kind of collaboration that makes a platform successful.

Final Thoughts: Build Less, Enable More

If there’s one thing you take away from this, let it be this: stop trying to do it all. Your job as a platform engineer isn’t to build a monolithic solution. It’s to create a framework where everyone else can contribute their expertise.

Treat your platform like a product. Listen to your users. Iterate. And most importantly, focus on outcomes, not tools.

Because at the end of the day, a good platform isn’t about paved paths or golden tickets. It’s about making life easier for your teams—and delivering real value to your organization.

Now go build something awesome.