Engineering for Economics
The question changed from how do we build more, to how do we deliver the same for less.
The situation
After Broadcom acquired VMware, the strategy changed and it changed quickly. The priority was margin and the retention of very large enterprise customers, not the pursuit of new ones. We were already a leader in the category. The question was no longer how to grow the platform but how to run it for materially less, without customers noticing anything except that it got better.
I had spent the previous three years modernizing this platform. Now I owned the engineering roadmap under an inverted set of constraints. Headcount was not the lever. Adding capacity was not the answer to anything.
I had also led the adoption of a distributed SQL engine during the growth phase, and its economics assumed we would keep growing into it. That assumption no longer held.
There was one advantage, and it mattered more than anything else I did that year. The platform was a FinOps product — it existed to tell enterprises what their cloud spend was doing. I had also spent the modernization years instrumenting our own pipeline: what each artifact cost to generate, how long it took, who actually consumed it, and how the data lineage ran. So when the mandate arrived, I did not have to start by guessing where the money went.
What made it hard
Strategically. Protecting margin and retaining the largest accounts pull against each other. The customers who cost the most to serve are frequently the ones you can least afford to lose. Deciding what not to do became the main engineering decision, and every one of those decisions had a name and an account attached.
Technically. Taking cost out of a live system under enterprise commitments is harder than building the same capability new. Everything already worked. Every change risked a regression a customer would feel, in exchange for a benefit no customer would see.
Organizationally. The executive cadence got heavier — steering committees, quarterly business reviews, annual operating plan cycles, finance partnership on allocation. My job was to translate that into priorities a team could act on, and to keep people motivated on work whose success looks like nothing happening.
What I did
I owned the engineering technology roadmap and balanced it across platform scalability, customer commitments, operational excellence and cloud economics. I partnered directly with VP Engineering, Product Leadership, Customer Success and Architecture, and represented engineering in the planning cycle where investment was allocated.
On the architecture, we attacked cost by mechanism rather than by directive. The largest category was work avoidance: generating artifacts when a customer actually reached for a capability rather than producing everything upfront. That is not a capability cut — the customer sees the same thing — but it removes an enormous amount of processing nobody ever looked at. Alongside it: caching at the boundaries where data stopped changing, framework rewrites where the framework was the bottleneck, compute-efficient instance types and spot capacity, savings plans, retention policies on intermediate artifacts nobody needed twice, and a single organizational data catalog replacing the several that teams had each built for themselves.
Routing mattered more than it sounds. Workloads had been going to the heaviest available execution engine by default. Matching each workload to the right engine — and scheduling some of it into windows where compute was otherwise sitting idle — took out a large share of the waste without changing a single customer-facing behaviour.
I led the engineering strategy to move off the higher-cost query architecture to a lower-cost design, holding performance and customer experience flat.
I also led AI in two directions. Internally, operational intelligence across engineering operations — using what we could see about customer usage to troubleshoot faster. What that involved is constrained by IP and I can describe only the effect. Externally, we shipped conversational analytics into production. Customers can ask what a business unit spent on a service, what next month projects to, which group is consuming most, or where the anomalies are — instead of navigating to a report, applying filters and building a categorization. The part worth explaining to an engineer is how the questions are answered: they are grounded against the platform’s known data and schema before being translated into an executable query, rather than being asked of a model that has to guess at the shape of the data.
Product and Customer Success owned the customer-facing prioritization conversations. The engineering teams owned the migrations and the mechanism work. I owned what we would and would not spend capacity on, and the argument for it.
The decisions
Keep the query engine or migrate off it
The fork. Staying meant a known quantity, a working system and no migration risk. Migrating meant recovering meaningful cost and unwinding a decision I had made myself.
The call. I led the transition to the lower-cost architecture, with performance and customer experience held steady.
The cost. Months of engineering capacity spent producing nothing a customer could see. That is a hard project to justify and a harder one to keep people motivated on, because the best available outcome is that nobody notices. It also meant publicly unwinding my own earlier call, which is cheap to describe and less comfortable to do.
Protect every commitment or deprioritize explicitly
The fork. Find savings while honouring every existing feature commitment, or explicitly stop work not aligned with retention or margin.
The call. Deprioritize, including things customers had asked for.
The cost. Real friction with account teams, and some customers waiting longer than they wanted. I worked that directly with Customer Success rather than letting the roadmap absorb it silently. Some of those conversations were uncomfortable and none of them got easier by being deferred.
Broad efficiency or targeted mechanisms
The fork. A blanket cost-reduction directive would have shown motion immediately. Targeting specific mechanisms would take longer to show anything.
The call. Mechanisms.
The cost was that we moved cost rather than removing it, and I want to be precise about that. Generating artifacts on access takes an enormous amount of work out of the pipeline and pushes some of it into the query path — which ran on the most expensive dependency we had. It was still comfortably net positive. But the mechanism that saved us the most made the thing we were already trying to get off work harder, and for a period we were paying down one decision with another.
What changed
| Before | After |
|---|---|
| Growth-oriented investment | Margin-oriented investment |
| Higher-cost distributed query engine | Lower-cost architecture, equivalent performance |
| Expanding footprint | Focused, retention-oriented footprint |
| Headcount-linked capacity | Efficiency-linked capacity |
We moved to a materially lower-cost architecture while holding performance and customer experience steady. Time to value improved. The conversational analytics capability shipped to customers.
I am deliberately not putting a second cost-reduction percentage on this page. The figure on the modernization study is the one I can attribute cleanly, and adding a softer number beside it would make both look weaker than they are.
What I carried forward
I championed the distributed SQL engine. Three years later I led the work to remove it.
That is the clearest evidence I have for something I believe about technology leadership: choosing a technology and staying loyal to it are different things. The reasoning is the same one I learned from a database decision that failed in production early in my career, applied at platform scale instead of to a single service. A technology that works under one set of assumptions is not evidence that it works once those assumptions change. The job is to keep checking which assumption you are still standing on.