The Hard Problems in Tech Aren't Technical
What if the Minimum Viable Platform is just Email and Empathy?
Gather round everyone, and let me tell you about the time I built "the cloud" in a weekend.
Okay, not the cloud in the AWS/GCP/Azure sense—there was no Kubernetes, no infrastructure-as-code, no auto-scaling groups or global edge networks. Just a simple portal, a few email templates, and a bunch of humans having slightly better conversations with each other. But in the eyes of the people using it? It was the cloud. It gave them what they needed. And more importantly, it helped a team reframe what they were already doing in a way that made them feel proud and appreciated.
This all happened many years ago while I was consulting, and it's one of those stories that sticks with me because it highlights a theme I see again and again in platform engineering: most of the really gnarly problems aren’t technical; they’re human.
The Setup
I was invited to speak with a mid-sized company where the executive had some internal conflict on how they could “adopt the cloud”. Their internal IT team said it couldn’t be done because of security and lack of budget. Tensions were high because some of the exec had been hearing from their peers at other firms of how great their cloud projects were going.
At first glance, it seemed like a familiar standoff. Leadership wanted agility and modernity. IT was stuck in risk mitigation and operational realities. Both sides had solid reasons, but they were talking past each other.
So I started digging—not into the network diagrams or IAM policies, but into what people were actually trying to achieve. And what I discovered was that leadership didn’t really want “the cloud”. They wanted the experience they associated with cloud.
They wanted self-service. Speed. Simplicity. A nice portal where someone could click a few buttons and get a virtual machine without waiting weeks.
That wasn’t a technical problem. That was a perception problem.
The Real Ask
I sat down with the IT team and asked: “What are the three most common virtual machine requests you get?”
They squirmed. They weren’t used to thinking in terms of patterns or products. They were used to handling one-off tickets. One request said 4GB RAM. Another wanted 6GB. One person asked for “whatever is fastest,” while another just forwarded an email chain with 17 contradictory replies.
When I suggested we boil things down to small (2GB), medium (4GB) and large (8GB), they immediately pushed back. “What if someone needs 6GB?” they asked. “Or 3.5?”
They were stuck on precision. But the users? They were just trying to get work done. They didn’t want perfection—they wanted something that worked.
So, over a weekend, I built a simple, stylish website and created some html-formatted email templates. Users could pick a size, enter their details, and click submit. That sent a basic email to the IT team with desired build spec and contact details. The IT team still did the build manually, but when they were finished, they’d use the fancy email template to inform the user their machine was ready. The template included useful info like how to login, how to request additional software, and how to raise a support ticket if needed.
All stuff they were already doing, just now packaged nicely and predictably.
The Result
By Monday morning, the team had their new “cloud portal”. Users were thrilled. Leadership was thrilled. And the IT team, initially skeptical, started getting praise from across the company. Not for being faster (they were doing the same work as before), but for feeling more responsive and easy to work with.
That shift in perception? Huge. As a result, the IT team were given additional funds to improve automation and begin to think about “real” cloud adoption.
The Takeaway
There’s a lot of talk in platform engineering about how we build better systems. But we often forget that platforms are as much about people and perceptions as they are about code. What I did that weekend wasn’t about technology, it was about translation.
Leadership wanted agility but didn’t have the words for it. IT wanted to do a good job but lacked a product mindset. The introduction of a tiny bit of design thinking—a simple interface, some basic defaults, and clearer comms—was enough to bridge that gap.
It's about clarifying intent, designing for humans, and making the invisible work visible.
We throw around words like "Developer Experience" a lot these days. But the best platform work often starts by asking: what do people actually need? Not just users, but the teams building and maintaining the systems too.
This article topic was suggested by the content club set up by the CNCF Platforms Community. Each month we choose a topic and invite anyone to contribute articles, videos, podcasts or commentary. If you enjoyed it, you might also like the follow related articles from other platform engineering practitioners. If you’d like to take part, come visit us on our #content-club Slack channel.
Atul discusses the broader organizational and cultural readiness required for successful platform adoption, emphasizing that platform engineering is as much about people and processes as it is about tools.
Graziano’s “13 Atomic Habits Playbook for Platform Engineers” breaks down reproducible, small-scale practices that platform teams can adopt to improve consistency, collaboration, and impact.
Kalle’s video explores the often-overlooked non-technical dimensions of platform success—such as effective communication, team alignment, and habit formation—through the lens of real-world engineering leadership.