Minimally Viable Platform Engineering

Engineers are often tempted to over-optimize and over-engineer for future problems that may never come.

A lot of effort is often wasted on imaginary future problems.

It’s often better to build just enough for the problem in front of you and iterate.

Most of the time, the future problems are different than you thought.

They might hit you later than you thought or not at all.

So, how do you know when something is good enough to ship and then iterate on?

A good rule of thumb is to ship when it’s minimally viable. Ship it when you can deliver a solid chunk of value to your users.

Here’s an example:

I’m working on migrating Kubernetes deployments from GitHub Actions workflows to ArgoCD. We assumed that to migrate services to ArgoCD, teams would want all sorts of documentation and automation.

We started building all sorts of workflows we assumed were needed instead of taking a more concierge, white-glove approach of working directly with a single team and migrating services.

Building just enough to learn is just as important in platform engineering as in product engineering.

---