The CTO walked us through the disaster. Eighteen months into a platform migration. $4.3 million spent. Zero production workloads migrated. The team was demoralized. The board was furious. Consultants from a major firm had been on-site for a year and had delivered hundreds of PowerPoint slides but no working system.
"Tell me honestly," he said. "Is this salvageable, or do we cut our losses?"
We spent three days talking to engineers, reviewing architecture docs, and examining what had actually been built. Then we delivered our assessment:
"The migration plan is technically sound. The technology choices are defensible. The timeline was aggressive but achievable. None of that matters because you're solving the wrong problem."
He stared at us. "What do you mean, the wrong problem?"
This is where most turnarounds begin. Not with bad execution of good plans, but with excellent execution of fundamentally flawed plans. The plan was answering a question nobody had properly asked.
Stripping to First Principles
First principles thinking means questioning every assumption until you hit bedrock—the fundamental truths that can't be broken down further.
Most technology projects are built on layers of inherited assumptions:
"We need to migrate to microservices" ← Why?
"Because our system doesn't scale" ← Doesn't scale to what?
"We're adding new features and deployment is too slow" ← What features? Why are deployments slow?
"The codebase is monolithic and tightly coupled" ← What would need to be true for deployments to be fast enough?
Each answer reveals another assumption. Most organizations stop digging after two or three layers. First principles means going all the way down.
For the CTO's migration disaster, we asked: "What business outcome are you trying to enable?"
After peeling back layers of technical justification, we got to the core: The company had acquired two competitors and needed to integrate their products into a unified offering. The migration to microservices was supposed to enable that integration.
But nobody had asked: "What's the fastest path to integrate these products?" They'd assumed: "We need to modernize our architecture first, then integration will be easier."
That assumption killed the project. They were eighteen months into architectural modernization with at least twelve more to go. Meanwhile, customers from the acquired companies were churning because the products weren't integrated.
The first principles question: "What's the minimum architecture change needed to deliver an integrated product experience to customers?"
Answer: An API gateway and some middleware. Maybe six weeks of work.
Would it be beautiful? No. Would it be the long-term architecture? No. Would it solve the actual business problem while they figured out the right long-term approach? Yes.
They shipped integrated functionality in two months. Customer churn stabilized. Revenue started flowing from the integrated offering. The platform migration continued, but now it was driven by actual learnings from running the integrated system, not theoretical architecture goals.
The Consultant's Curse
Large consulting engagements often fail because of misaligned incentives. Consultants get paid for time and deliverables, not outcomes. A hundred-slide deck is a deliverable. A working system that solves the problem in six weeks instead of eighteen months means less billable time.
We're not saying consultants are malicious. But the incentive structure creates perverse outcomes. Complexity is rewarded. Simplicity is penalized.
First principles consulting inverts this. The goal is the simplest path to the desired outcome. If that takes six weeks, great—bill for six weeks and move on. If it takes six months, fine—but every week should deliver tangible progress toward the outcome.
A retail company hired us after a disastrous ERP implementation. Three years in, $12 million spent, the system still wasn't live. The previous consulting team had customized the ERP so heavily it was essentially bespoke software.
First principles question: "Why do you need an ERP?"
After cutting through the buzzwords: They needed better inventory visibility and automated reordering.
"Does the ERP actually do that in your environment?"
Turns out, their inventory was so distributed (hundreds of small retail locations plus several warehouses) that the ERP's inventory model didn't fit. The consultants had spent three years trying to force-fit it with customizations.
Alternative: A lightweight inventory tracking system integrated with their existing point-of-sale systems and warehouse management. Not called an "ERP." Just software that did what they actually needed.
Built and deployed in seven months. $800K total cost. Delivered the visibility and automation they'd been chasing for three years.
The previous consultants weren't incompetent. They were answering the wrong question. They'd been hired to "implement an ERP," so they implemented an ERP. Nobody stopped to ask if an ERP was the right solution.
The Five Whys Plus One
Toyota's "Five Whys" technique is powerful for root cause analysis. You ask "why" five times to dig past symptoms to causes.
We add one more: "So what?"
This forces you to connect the root cause to actual business impact.
Example: A fintech startup's API was slow.
Why? Database queries were inefficient. Why? Missing indexes on key tables. Why? Nobody prioritized database optimization. Why? Engineering was focused on shipping features. Why? Roadmap was driven by sales promises.
So what? Sales was selling features customers asked for, but slow API performance was causing existing customers to churn. The company was gaining customers on the front end and losing them on the back end.
The solution wasn't "add database indexes" (though they did that). It was changing how they prioritized work. Stop selling features until performance met acceptable thresholds. Otherwise they'd be in a perpetual churn cycle.
That "so what?" revealed the real problem. Technical debt wasn't a technical problem—it was a go-to-market strategy problem.
Rebuilding from Bedrock
Once you've stripped to first principles, rebuilding is surprisingly straightforward. You're no longer constrained by assumptions about how things "should" work. You're building from what actually matters.
A healthcare company had a patient portal project that had failed three times over five years. Each time, they hired new vendors, got new technology, ran into issues, and gave up.
First principles: What do patients actually need to do?
Through interviews and observation, we identified six core workflows: schedule appointments, view test results, message providers, request prescription refills, pay bills, update insurance.
Previous attempts tried to build a comprehensive portal with dozens of features, sophisticated integrations, and beautiful UX. Took years, cost millions, never launched.
New approach: Six features. Basic UX. Minimum viable integrations.
Three months to MVP. Launched to a subset of patients. Measured usage. Learned what mattered. Iterated.
Turns out, patients cared most about viewing test results and messaging providers. Appointments and prescriptions were important but less urgent. Bills and insurance could wait.
Subsequent development focused on what users actually used. A year later, the portal had grown to fifteen features—but those fifteen were driven by real usage patterns, not assumptions.
The project succeeded not because the technology was better (it wasn't particularly novel) but because the problem definition was clearer.
When Expertise Becomes Blindness
Subject matter experts are invaluable. They know the domain, the constraints, the history. They also carry assumptions so deeply ingrained they don't recognize them as assumptions.
An enterprise software company wanted to add real-time collaboration to their document management system. Their engineering team insisted it required a complete rewrite—the system was built on a request-response model, and real-time meant websockets, event streams, and architectural overhaul.
First principles: What does "real-time collaboration" mean to your users?
User research revealed: They didn't need Google Docs-style simultaneous editing. They needed to see if someone else was currently viewing or editing a document so they didn't create conflicting changes.
That's not real-time collaboration. That's presence indicators and simple locking.
Implementable with their existing architecture: Polling every few seconds to check document status. Not technically elegant. Perfectly sufficient for the use case.
Shipped in two weeks instead of the six-month rewrite.
The engineers weren't wrong that real-time collaboration would require architectural changes. They were wrong about what users meant by "real-time collaboration." Their expertise created a blind spot.
First principles thinking often means bringing in outsiders who ask "dumb" questions. "Why does it have to be that way?" isn't dumb—it's the question insiders stop asking.
The Turnaround Pattern
Across dozens of turnarounds, we've seen a consistent pattern:
Week 1: Listen without solutions Talk to everyone involved. Engineers, product managers, executives, customers, support teams. Don't propose solutions. Just understand what people believe the problem is.
Week 2: Map the assumptions Document every assumption you heard. "We need to..." "Users expect..." "It has to..." "The industry standard..."
Week 3: Challenge everything For each assumption, ask: Is this actually true? How do we know? What would happen if it weren't true?
Week 4: Define first principles What are the actual, non-negotiable constraints? What business outcome are we trying to achieve? What would success look like?
Week 5-6: Design from bedrock Given only the first principles, what's the simplest path to success? Ignore existing architecture, sunk costs, and how things are "supposed" to be done.
Week 7+: Build and validate Ship the simplest version fast. Measure against the actual success criteria. Learn. Iterate.
A manufacturing company's quality control system implementation followed this pattern. Eighteen months of failed attempts with multiple vendors.
Week 1: We learned everyone had different definitions of "quality control." Operators wanted defect tracking. Managers wanted trend analysis. Executives wanted compliance reporting.
Week 2-3: We identified the assumption stack: "We need a comprehensive QMS" ← "Quality management systems are complex" ← "Compliance requires extensive documentation" ← "Industry best practices require certain features."
Week 4: First principles: Reduce defect rates, pass audits, improve process over time.
Week 5-6: Simple system—defect logging on the production floor (tablet-based forms), automated trending (basic analytics), compliance reports (generated from the defect logs).
Week 7-12: Built, deployed, refined based on actual usage.
Result: Defect rates dropped 34% in the first quarter because operators actually used the simple system, whereas they'd ignored the complex previous attempts. Audits passed. Management got their trend data.
The comprehensive QMS they thought they needed? Turned out they didn't need it. They needed something people would actually use.
The Hidden Cost of Sunk Costs
The biggest barrier to first principles turnarounds is sunk cost fallacy. "We've already invested $4 million and two years. We can't just throw that away."
Yes, you can. Because the alternative is investing another $4 million and two years into something fundamentally flawed.
Sunk costs aren't recoverable. The only question that matters: What's the best path forward from here?
A logistics company had built a custom routing optimization system. Three years, $6 million, marginal improvement over their old manual process. They wanted to "finish" it—estimated another year and $2 million.
First principles analysis: The custom system was trying to solve a general optimization problem. Their actual need was narrower—optimize specific routes under specific constraints.
Alternative: Off-the-shelf routing software ($200K/year subscription) configured for their constraints.
They balked. "But we've already spent $6 million building our own."
"And if you spend another $2 million, you'll have an $8 million system that underperforms a $200K solution. The $6 million is gone either way. The question is whether you spend another $2 million making it worse."
They made the switch. The off-the-shelf software worked better, and they freed up their engineering team for projects that actually needed custom development.
Teaching the Mindset
First principles thinking isn't just for turnarounds. It's a skill organizations can develop internally.
Start by making it safe to ask "why" repeatedly. In many organizations, questioning established plans is seen as obstructionist. Change that culture.
Reward people who surface flawed assumptions early, even if it means killing projects that have momentum.
Build "assumption maps" into project planning. Before starting major work, document: What are we assuming is true? How do we know? What would invalidate that assumption?
Run pre-mortems: Before launching a project, imagine it failed spectacularly. Work backward: Why did it fail? What assumptions were wrong?
One company we worked with implemented "first principles Fridays." Once a month, a project team presents their work to the broader organization. The organization's job: Ask "dumb" questions.
"Why does it work that way?" "What if we didn't do that part?" "Who actually needs this feature?"
Uncomfortable at first. But it caught flawed assumptions before they became expensive mistakes.
One team was building a mobile app redesign. First principles Friday question: "Who asked for a redesign?"
Awkward silence. Turned out, nobody had. The design team wanted to modernize the UI. But users weren't complaining about the interface. They were complaining about missing features.
The redesign was canceled. Effort redirected to features. User satisfaction improved.
The redesign would have taken six months and delivered no value. One hour of first principles questioning saved the company from that mistake.
The Uncomfortable Truth
First principles consulting is often uncomfortable. It challenges egos, invalidates prior decisions, and forces people to admit they were solving the wrong problem.
But the alternative—continuing down flawed paths because everyone's committed to them—is worse.
The best turnarounds start with someone willing to say: "I don't care how much we've already spent or what the plan says. Let's figure out what actually matters and do that."
That's first principles mastery. And it's the difference between consultants who optimize bad plans and consultants who help you build better ones.
When your tech project is failing, the question isn't "how do we execute better?"
It's "are we building the right thing?"
Answer that first. Everything else follows.