No. 1At MuleSoft · Walmart · Retail
Selling a pattern, not speed
An engineering lead saw no integration gap. I earned the right to expand by delivering what he asked for first.
- The challenge
- Negotiated discounts reached a new CRM hours late, so deals went live at the wrong rate and finance caught the errors at billing.
- My contribution
- Reframed a speed problem as an ownership problem, and earned the engineering lead's trust by delivering the demos he asked for, in his order.
- The outcome
- First use case bought. The larger pricing and billing opportunity is still open.
Business challenge
Walmart was moving one of its newer business units onto a new CRM. The move was done quickly, so old data habits came along. Records travelled through a central store on a schedule of hours. Most changes could wait. A negotiated discount could not. When it arrived late, deals went live at the wrong rate and finance found the error at billing. Staff retyped values by hand to get around it. More business units were about to join the same CRM, which meant the problem was about to be copied.
Strategic insight
Everyone called this a speed problem. It wasn't. Most of the business was happy to wait a day. One process cost real money when it ran late. The deeper issue was ownership. Every fix meant changing older systems, each on a different team's roadmap, and the proper fix was more than a year away. The customer could integrate just fine. It lacked a standard way to do it that didn't queue behind other teams. So I stopped selling real time. I sold a reusable, governed pattern, and kept real time for the one place it earned its keep.
My approach
The engineering lead told me plainly he saw no gap. I didn't argue. He asked for two working demos, so I led with those, in his order, built around the pain points the business had already named. The pricing delay came last, as a question: here is the same pattern applied to the problem your team raised. I asked him for the volume and cost figures so the numbers were his, not mine. I also didn't propose replacing anything. Their data store stays. We only touch flows where delay costs money.
Stakeholder alignment
The business sponsor had already bought the first use case, but followed the engineering lead's advice. That made him the person to win. I didn't go around him. I did his homework with him, so he could recommend with confidence. Internally, I kept the integration specialist, the solutions engineer and the delivery architect on one story. I was careful never to describe anything as decided before the customer decided it. Where a delivery team was an ally, I checked with them before anything that might read as new scope.
Business outcome
The first use case was bought and is moving through the customer's internal approvals. The engineering lead agreed to a working demo so his team would be ready when the business brought him the request, with a broader evaluation to follow. The larger opportunity, applying the same pattern to the pricing delay and to usage billing, is still open. I can't claim a result yet. What changed is the conversation: from 'we see no gap' to 'show us where this beats our current path.'
“The strongest argument only lands after trust.”
What I learned
I came close to leading with my strongest idea instead of the one I was asked for. The pricing delay was the best business case, and the engineering lead had never raised it. Showing it first would have told him I'd gone around him. The lesson is that earning the right to expand matters more than being right about where the value is. Deliver what they asked for. Then ask a question about the next thing. The strongest argument only lands after trust.
Permalink to this story