Platform engineering - Anaconda: It’s a journey, not a destination

A solution looking for a problem

Organisations follow a predictable pattern. They hear of others’ success and decide they want platform engineering. They begin with poorly defined success criteria such as an “improved developer experience” without tying it to customer or business needs. This leads to over-engineered solutions biased toward implementing known technical solutions like Kubernetes without having the problems these systems solve. This results in expensive teams and time-consuming projects that yield minimal business results.

I witnessed this at a company that built a new platform for integrations and asynchronous processes.

A team of 35 engineers worked 18 months with minimal customer-facing improvements. They used the latest technology: event-driven architecture, NoSQL databases and serverless computers. Both projects were abandoned after leadership realised it would take another 18 months to see any customer impact.

A better path

The best platforms start by iteratively solving actual pain points with customer or business impact.

At a marketing company where I worked, deploying custom campaign experiences required manual effort across different teams. This took up to two weeks from start to finish. Automating this process would save weeks of calendar time, leaving more time for client iteration and better resource utilization.

The solution didn’t require an entire platform. We started with simple scripting that eliminated manual steps and reduced mistakes. Over time, we improved iteratively: rewrote the script in a proper programming language for better testability, encapsulated functionality into an API for access controls and compliance, then put it behind a button on a webpage so non-engineers could use it.

The button and the platform it lived on wasn’t the goal, it was the result of iterative improvements.

Golden paths: temporary side effect

This approach creates golden paths as a side effect. In my example, there was now a single way, a button, to deploy applications. It saved time, improved uptime and ensured security and architecture standards for scalability.

These golden paths tarnished as applications evolved. What was once a single golden path became two when one application needed deployment in multiple regions. It became four when new customer requirements broke our automated assumptions. It became eight when we needed different options for lower environments to manage growing cloud costs.

These are good problems, often coinciding with business growth. But they illustrate that platform engineering represents an approach to tackling problems, not a solution.

If the goal was creating a golden path for deployment, the initiative would have been dead on arrival.

The bottom line

Platform engineering is effective, but organisations must treat it as a journey, not a destination.

Otherwise, they’ll be caught off guard by the ongoing investment required to maintain systems of increasing complexity without understanding or getting the benefits.

Before embarking, every organisation should ask: what are we trying to achieve and can we do it iteratively without creating a platform first?

Platform engineering succeeds when it emerges from actual operational pain points and maintains clear connections to business outcomes. It fails when it becomes the solution before the problem is understood.