Compared to What? A Retail Client, a Kubernetes Prescription, and a 20-Year-Old System
· 3 min read
A retail client came to me with the answer already decided.
The pandemic had battered their business, competitors were circling, and another vendor had handed them a confident prescription: containerize everything, deploy Kubernetes, and the operational pain would disappear. They didn’t want a conversation about architecture. They wanted someone to execute the plan.
The trouble was what sat underneath the plan. The system they wanted to wrap in Kubernetes was twenty years old, and nobody left in the building fully understood how it worked. “Nobody knows what the content is,” is roughly how it was described to me. You cannot containerize your way out of not knowing what you have.
Don’t decorate the weakness
The instinct, when a client is certain, is either to argue or to comply. Arguing about Kubernetes would have made everyone defensive. Complying would have meant building something new and shiny on top of a foundation no one could see — what I think of as decorating the weakness. It looks like progress. It quietly moves the risk somewhere you’ll find it later, at a worse time.
So instead of debating the solution, I worked backwards toward the problem.
The question behind the question
The most useful question I know is deceptively small: compared to what?
Kubernetes will fix the operational pain — compared to what? What does the pain actually cost today? A million-plus active members, promotions that run for hours, hardware with six-month lead times — once you make those numbers visible, “just deploy Kubernetes” stops being an answer and becomes one option among several, each with a price.
That reframing doesn’t require you to be right about the technology. It only requires you to separate the symptom the client is feeling from the cause they haven’t named yet.
The silence in the room
To find the cause, I ran an impact mapping session with the decision-makers and functional leads. I set a goal — grow month-on-month revenue — and asked a question that should have been easy: who supports this goal?
The room went silent.
It wasn’t that they didn’t care. It was that they had spent years taking orders, not owning outcomes. That silence told me more than any architecture diagram could. The problem was never really the database or the deployment model. It was that no one had connected the technical system to the business it was supposed to serve.
A two-day Event Storming workshop — forty to fifty people, many of them sitting together for the first time — surfaced where to actually begin: merchant management. Not because it was the newest or the most interesting, but because it was where the domain, the money, and the pain lined up.
I found I was a businessman
Somewhere in the middle of that workshop, I had a small, disorienting realization: I found I was a businessman, not a technical guy. Connecting marketing, inventory, and logistics wasn’t a detour from the architecture work. It was the architecture work.
This is what I mean when I say architecture is a socio-technical activity. The hard part isn’t choosing between Kubernetes and something else. It’s the space between people — their language, their incentives, their ownership — and the systems they build. Miss that space and the best technology in the world will still land on a foundation nobody understands.
The takeaway
If a client arrives with the answer already in hand, that’s not a problem to route around. It’s the most important signal you’ll get. Slow down just enough to ask compared to what?, get the right people in one room, and let the domain tell you where to start.
Understanding the problem first is almost always the faster route to solving it.
This essay grew out of a conversation on Virtual DDD with Andrea Magnorsky, Andrew Harmel-Law, and Kenny Baas-Schwegler.