THE BELIEVED REALITY
The strategy is clear.
The dashboard is green.
Communication is open.
Each function is performing.
The transformation is on track.
Independent problem-solving studio
Sometimes the problem isn't where you think it is.
We work outside your organisation, but deep inside the problem — across people, customers, systems, technology, incentives and evidence — until the picture becomes clear.
Interactive. Move your cursor across the map to reveal the second view. Scroll to zoom out.Interactive. Tap or drag across the map to reveal the second view. Swipe up to zoom out.
01 / TWO REALITIES
Every organisation
contains two versions
of itself.
One is what the organisation believes is happening. The other is what its people, customers, systems and evidence show is actually happening.
We work in the distance between them. That is where dysfunction grows.
THE EXPERIENCED REALITY
Meaning changes as strategy travels.
People have stopped escalating.
Important work does not move.
Handoffs quietly fail.
Workarounds keep the system alive.
We find the gap.
We uncover what is true.
We help close the distance.
02 / LOOK AT THE SEAMS
The pieces don't have to be broken for the whole thing not to fit.
PRODUCThigh quality
COMMERCIALhigh quality
interface
FIG 02 — THE DISTORTION EXISTS WHERE THE SYSTEMS MEET
A company can contain excellent Product, Engineering, Sales, Operations and leadership — and still function badly.
The failure can live in the handoff, the translation, the incentive collision, the sequence, the decision boundary, or the information that never travels.
03 / PROBLEMS WE SOLVE
Does any of this
sound familiar?
These are some of the problems that bring companies to us. What they look like on the surface is rarely the whole story.
We keep fixing the same customer problem.
Repeated symptoms may be downstream of information loss, ownership gaps, incentives or translation failures.
Bring this problem ↗We hired more people.
We're somehow getting slower.
Headcount can rise while usable capacity falls through coordination cost, reprioritisation and rework.
Every department has a different explanation.
What worked at 20 people doesn't work at 80.
Sales keeps promising things Product can't deliver.
It may not be a Sales problem or a Product problem. It may be the system between them.
“The transformation is green on the dashboard.”
Everyone living through it says otherwise.
04 / PUBLIC CASES
Problems that arrived
from somewhere else.
Five public examples where the visible failure was real — but the useful explanation sat deeper in the system.
These are brief summaries of published cases. They are here to show the pattern, not to reduce complex events to one cause.
The market leader
that couldn't turn quickly enough.
VISIBLE
Nokia lost its position in mobile phones as smartphones shifted toward software, touchscreens and app ecosystems. In 2014 it completed the sale of substantially all of its Devices & Services business to Microsoft.
UNDERNEATH
Published research based on Nokia insiders describes slow decisions, internal rivalry, fragmented software development and important information being filtered on its way upward. The market changed quickly; the organisation struggled to respond at the same speed.
A flagship launch
that became a recall.
VISIBLE
Reports of Galaxy Note7 battery incidents led Samsung to launch a replacement programme and later end production of the device.
UNDERNEATH
Samsung's investigation, alongside three independent organisations, concluded that the batteries caused the incidents. The visible failure was the phone; the identified cause sat inside a critical component and the checks around it.
Sources: Samsung investigation · Samsung Australia
Eleven lines
that stopped builds.
VISIBLE
Software projects began failing when the small left-pad package disappeared from the npm registry. npm recorded hundreds of failures per minute and a disruption lasting about two and a half hours.
UNDERNEATH
The package sat inside dependency chains used by thousands of projects. The code was tiny; the dependency was not. Removing one small piece exposed how much of the wider system relied on it.
Sources: npm postmortem · The Register
The numbers
nobody could verify.
VISIBLE
Wirecard said in June 2020 that €1.9 billion recorded in trust accounts probably did not exist. Three days later, the company filed for insolvency.
UNDERNEATH
The auditor had been unable to confirm the cash balances, and Wirecard reported evidence of false balance confirmations. The case shows why a number is only as reliable as the controls and independent checks behind it.
A small component
that stopped assembly lines.
VISIBLE
Semiconductor shortages caused severe vehicle-production disruption in 2021 and 2022, including assembly lines being brought to a standstill.
UNDERNEATH
A missing semiconductor could constrain the output of an entire vehicle plant. More capacity elsewhere could not compensate for the component the finished product still needed.
Sources: U.S. Federal Reserve · U.S. Commerce
05 / QUICK DIAGNOSTIC
Start with what
you can see.
A short interactive tool to help separate the problem you are experiencing from the solution you may already be considering.
It will not diagnose your business. It will help you organise the question before you make a decision.
Try the diagnostic ↗06 / INSIGHTS
Clear thinking.
Useful language.
Look at the seams
The pieces can all be good and the system can still fail between them.
When the obvious problem is the wrong problem
Why capable teams can spend months improving the symptom.
AI can only work with the reality you give it
Good analysis starts after the right problem is visible.
07 / SPECIALIST NETWORK
The room should be smarter
than any one person.
Founder & Lead Problem Investigator
Works across the problem rather than from inside one discipline: following contradictions, hidden assumptions, information loss, system effects and the distance between what an organisation believes and what is actually happening.
Technical Architecture
Examines architecture, integrations, dependencies, technical debt and ownership boundaries to separate genuine technical constraints from organisational symptoms.
Data & AI
Interrogates data quality, provenance, measurement, analytics, automation and AI systems to establish what the evidence genuinely supports — and where technology creates useful leverage without replacing judgment.
Product
Looks behind the roadmap at customer evidence, prioritisation, decision rights, commercial pressure and delivery constraints to reconnect product decisions with the outcome the organisation is actually trying to create.
Service Design
Follows the experience across handoffs, workflows and organisational seams to expose where customers or employees are compensating for failures elsewhere in the system.
Organisational Systems & Change
Examines structure, decision authority, incentives, workload, trust and change history — not to diagnose personalities, but to understand how organisational conditions shape behaviour and information flow.
Security, Risk & Regulatory
Tests security architecture, governance, controls and regulatory constraints where risk materially shapes the intervention, distinguishing real safeguards from risk that has merely been transferred elsewhere.
Finance & Economics
Follows commercial models, unit economics, cost structures, pricing, resource allocation and incentives to identify hidden costs, value leakage and metrics that may be driving the behaviour they were meant to measure.
08 / NEXT STEP
Tell us what is happening. We’ll work out whether we’re the right people to investigate it.Bring us the problem ↗