Driving Change: Selling the Problem, Not the Solution

The most common mistake platform teams make is falling in love with their own solution and leading with it.

"We built an incredible new service mesh. It uses the latest eBPF-based data plane, it's horizontally scalable, and the architecture is genuinely elegant. You should all migrate to it."

The reaction from application teams is almost always the same: "We're busy shipping features. That sounds like extra work for us. Why should we care?"

The problem is not the technology — it might genuinely be excellent. The problem is the framing. You led with your excitement about your solution, not with their pain.

Start With "Why" — Their Why

People are motivated to change when they feel a pain point acutely, not when they are shown a shiny new tool. Your job is to connect your solution to a problem they already know they have.

The three-step influential approach:

Step 1 — Deeply understand their pain.
Before you pitch anything, listen. "I noticed your team spent the entire weekend dealing with network timeouts during the Black Friday sale. What happened? What was the impact on your team?" This is not a sales tactic — it is genuine curiosity. You cannot accurately frame your solution as a remedy if you do not understand the disease.

Step 2 — Quantify the problem.
Vague pain is easy to deprioritize. Quantified pain is hard to ignore. "Those timeouts resulted in roughly $50,000 in lost transactions and pushed your next feature release back by a week. That's a real cost." Numbers give stakeholders a concrete reason to act and give executives a basis for approving budget.

Step 3 — Offer your solution as the specific remedy.
Only now do you introduce your tool — and you frame it precisely against the pain you just quantified. "The service mesh we built handles retry logic and circuit breaking automatically at the infrastructure layer. In our testing, it would have absorbed those timeout spikes without any application-level changes. Would you be willing to run a two-week pilot?"

By following this sequence, you stop being a "tool pusher" and become a partner solving a real problem. The ask at the end — a pilot, not a full migration — is also deliberate. Small, reversible commitments are far easier to get than large, permanent ones.

The Pilot Strategy

Asking for a full migration upfront is a high-stakes ask that triggers risk aversion. Asking for a two-week pilot on a non-critical service is low-stakes and easy to say yes to. Once a team has run a successful pilot, they have evidence, experience, and often enthusiasm. The migration conversation becomes much easier because they are now advocating for it internally, not just complying with an external mandate.