It's 2017, and Uber is in crisis. #DeleteUber protests flood social media. Our CEO has been caught on video berating a driver. Susan Fowler's revelations about workplace culture have rocked the company. Drivers are angry. Riders are leaving. Investors are nervous.
In the scramble to rebuild trust, leadership hands down a clear directive: make drivers happier.
If only it were that easy...
At the time, one of drivers' favorite features is "Destinations." It allows them to pick up a ride along their route—perfect for heading home after a shift. But we cap it at two trips per day because uncapping it would throw off the marketplace. Drivers would cluster in certain neighborhoods, surge prices would spike, and riders would be left stranded elsewhere.
Since drivers love this feature and management wants to boost driver satisfaction, removing the cap seems like an obvious solution. Simple fix, right?
Within hours, the system unravels. Prices skyrocket. Riders bail to Lyft. Drivers game the system. The very change meant to improve the experience makes it worse for nearly everyone. We have no choice but to roll it back—publicly, embarrassingly, almost immediately.
The mistake wasn’t in execution. It wasn't even about insufficient information. It was a failure of systems thinking—of understanding how one part of a business affects the whole.
At Uber, our crisis wasn't just about fixing driver happiness. It was about learning that when you move one piece, you have to see the whole board. And Uber, at its core, wasn't built to optimize driver satisfaction.
The Technology-Operations Paradox
Our response to this systems failure was telling: we tried to solve driver happiness by adding more features to an already complex system. It's a pattern I've watched repeat across a decade of leading products at operations-heavy companies: when problems arise, we instinctively add more people, processes, and spreadsheets.
The Paradox
It starts when something in your business isn't working, and the instinct is to layer on solutions. But each solution adds new dependencies and more overhead. Instead of solving the root issue, you build an increasingly fragile system that requires constant maintenance. Herein lies the paradox:
The more we try to fix problems with added technology and processes, the more operational complexity we create. That complexity then demands even more tech to manage it, trapping us in a vicious cycle.
Consider a food-services company I worked for, hemorrhaging $2 million annually in waste. Our model – offering multiple cuisines from various brands – seemed appealing until spoilage ate at profits. The team's instinct? Build better forecasting models (aka add complexity). But with manual processes everywhere, we couldn't even get reliable data to forecast with.
The Quick Fix Spiral
I've seen this so many times. The pressure to show immediate results ("DO MORE FAST!") overwhelms any opportunity for stepping back and thoughtfully examining the system itself, creating a self-reinforcing spiral of false productivity. With each quick fix, the underlying problems become more entangled and harder to address.
Problems trigger quick fixes (more processes/tools/features)
New solutions create more moving parts
More moving parts make data tracking harder and less reliable
Unreliable data leads to more problems
In our food delivery example, juggling multiple vendors, brands, and cuisine types had created such system instability that no amount of process optimization– from improved Standard Operating Procedures to data instrumentation to hail-mary UI changes– could solve the problem because they were addressing symptoms rather than root causes.
Eventually, the complexity becomes unsustainable. This is when the hard truth emerges: adding more layers won't work. The only way forward is to step back and rethink the system itself.
The Reset
There's a principle in systems thinking known as POSIWID: the purpose of a system is what it does.
In other words, success isn't about adding more features or checkpoints - it's about building structures that naturally encourage the right behaviors.
Instead of optimizing a broken system, we needed to fundamentally redesign how humans, technology, and processes interact in a scalable way. This means:
Identifying what behaviors your system naturally produces
Understanding why users struggle to do the right thing
Determining what data actually drives decisions
For the food-services startup, this meant recognizing that our distributed supply chain, with multiple brands, was creating a system that was neither profitable, nor frankly, that desirable by our users. When we moved to direct food sourcing with proprietary recipes the results were transformative.
By simplifying our supply network, and creating our own menus, the waste problem vanished. This created a positive feedback loop: without a large distro team to manage, we could pour resources into what actually mattered: our kitchen crews and food quality. And when we pointed our technology at making great food instead of just tracking spoilage, something magical happened: customers started coming back more often and our ratings shot up.
Each win fed into the next, proving something I've seen time and time again - when you nail the system design, problems have a funny way of solving themselves.
The Systems Design Sequence
When you break free from the Quick-Fix Spiral and decide to hit reset, a clear action plan emerges:
Design the right system first (product thinking): Build a system that naturally guides people toward better outcomes. At Uber, this would have meant creating a marketplace that balanced both driver satisfaction and reliable service from day one. You can't improve your way out of a flawed design.
Measure what matters (data instrumentation): Only once your foundation is solid can you track meaningful progress. Remember our food delivery company – we only got accurate insights after simplifying our operation to focus on what worked.
Then, fine-tune (operational excellence): This is when process improvements really take hold. Each small change builds on the last because you're working with a system designed for success, not fighting against it.
Here's the truth I've learned the hard way: operational excellence isn't about layering on complexity - it's about creating an environment where good outcomes happen naturally.
Why isn't this obvious? Because when we see a fire, our instinct is to grab an extinguisher—not redesign the building's sprinkler system. Systems design demands we resist this reactive urge, stepping back when everything in us wants to leap forward.
Good systems design often feels counterintuitive. At Uber, it would have seemed absurd to suggest that limiting driver flexibility could actually make drivers happier. At our food delivery startup, arguing for fewer menu options when sales were dropping felt like madness. Yet in both cases, constraint was exactly what the system needed to thrive.
So next time you’re faced with a complex business problem, ask yourself: Are you fixing symptoms, or redesigning the system? The difference is the key to long-term success.
Does this align with what you’ve seen? I often find the hardest part is recognizing when your system needs a reset rather than a patch. What signals and patterns have you seen emerge to know the difference? I’d love to hear your thoughts in the comments!
Special thanks to the wide-ranging expertise involved in this week’s edits including framework guru
, narrative storytelling queen , accountability partner and Biz Ops Superman Sam Wang.
I see this in vibe-coding too! The AI tends to fix a problem with another bandaid rather than seeing the forest from the trees. Sometimes it works, but often more cruft grows...