Systems, Not Symptoms: the diagnostic framework

"Systems, Not Symptoms" means fixing the structure that produces a problem instead of treating the problem each time it reappears. In practice it is a four-step diagnostic loop: diagnose financially (trace the problem to a cause the ledger can confirm), architect technically (design the fix, not the patch), build operationally (put the fix into production with a number attached), and transfer through teaching (the owners end up running it, not you). The phrase is this site's tagline, but it began as a working method. I have run the loop through the replacement of a bank's core ledger in Lagos, a nine-country operational turnaround, analytics for a fintech operation across seventeen African markets, and the classrooms of St. Lawrence College.

This essay does three things. It names the problem the framework exists to solve, walks through the four steps with the receipts behind each one, and closes with a way to run the loop on your own business this quarter.

Why do the same problems keep coming back?

Because most fixes are applied at the point of pain, and the point of pain is rarely the point of cause. A business that runs short of cash every quarter arranges another overdraft. A product line that keeps missing margin gets a discount policy with more exceptions. A month-end close that takes three weeks gets a second temp accountant. A team that keeps missing deadlines gets a new project tool. Each fix works, briefly. That is exactly the trap: relief gets mistaken for repair, and the problem is filed as solved until it returns.

An accountant sees the pattern in cost terms. A recurring symptom is an expense that behaves like a subscription. If the quarterly cash crunch costs a week of management attention plus bridge-financing fees, four times a year, you are paying an annual price for the privilege of not fixing it. Run that arithmetic on any problem that has been "solved" more than twice and the cheap patch stops looking cheap.

The asymmetry is structural. Symptoms are urgent, visible, and downstream. Root causes are quiet, structural, and upstream. Under deadline pressure, urgency wins by default: through five years of banking days in Lagos that ran 7am to 9pm, I watched the urgent report outrank the upstream question almost every time. The only reliable counterweight is a method that forces the question upstream before a fix is chosen. That is what the four steps are for.

What are the four steps of the framework?

Diagnose financially. Architect technically. Build operationally. Transfer through teaching. I did not design this on a whiteboard. It is the pattern I found repeating across banking, telecom, fintech, my own software, and the classroom, and eventually wrote down. The same loop now scopes my consulting engagements and structures my teaching.

1. Diagnose financially

The numbers confess first. Whatever the presenting complaint (churn, missed deadlines, a stressed team, a cash squeeze), the cause is usually already recorded in the financial data, because everything a business does eventually lands in its ledger. Margin by product and by customer. Receivable aging. Unit costs. Variance trends. Credit notes and rework.

I learned to read for causes in performance management at Intercontinental Bank's head office in Lagos, between 2007 and 2012, a tenure that ran through the bank's 2011 merger into Access Bank, tracing which products, branches, and decisions actually produced the variances of an institution whose footprint reached 12 countries and more than US$12.5 billion in assets.

At MTN Nigeria, between 2012 and 2015, the same discipline ran at consumer scale: pricing analytics and business planning models for an operator with 47.4 million subscribers and a 47.8% market share, where a mispriced bundle shows up in the revenue line long before anyone can articulate what went wrong. The model tells you where to look; the ledger rarely lies for long.

The step has a finish line. Diagnosis is complete when you can state the root cause as one falsifiable sentence with a figure in it. "We lose money on rush orders below a set threshold because setup cost is fixed" is a diagnosis. "Operations needs to be more efficient" is a mood.

2. Architect technically

Design the thing that removes the cause, not the thing that compensates for it. A patch lives inside the broken structure and works around it. A fix changes the structure so the symptom has nowhere to come from.

The formative receipt here is the Oracle FLEXCUBE core-banking implementation I worked on at Intercontinental Bank, alongside an IFRS conversion. A bank whose core ledger cannot support the reporting its managers and regulators need does not solve that with cleverer spreadsheets layered on top. It replaces the system the whole institution runs on. That project taught me the question every architect must answer before drawing anything: at what level does the cause live? Sometimes the honest answer is a rebuilt chart of accounts, not a new dashboard. A data model, not another report. A pricing table, not another discount memo.

The design test I use: what would have to be true for this problem to be unable to recur? Design toward that condition and no further. The best fix is usually the most boring one that meets the test, because boring structures survive their builders.

3. Build operationally

A fix earns nothing until it runs in production and reports its number weekly. Diagnosis and design are still theory until somebody operates them, and operating them is where most fixes die.

From 2015, I ran regional operations and performance analysis at MTN Group for nine West and Central African countries, resident in Nigeria and travelling to the operating companies from the group's Johannesburg base. The ledger then read nine markets, seven of them in the red. The nine-country turnaround that followed was led by regional vice-president Karl Toriola; I built the performance analysis and planning underneath it. Two years later the ledger read nine of nine profitable, with customer NPS up in every market. The turnaround was not a strategy document. It was a build: diagnosis converted into operating plans, plans into targets, targets into weekly measurement, measurement into corrections, market by market.

The second receipt is from MTN Group Fintech, where I managed decision support and analytics across seventeen African markets running mobile financial services, for a customer base above 200 million, from 2019 to 2023. The systems my team built drove BI adoption to 97% across the organization, supported 21.4% subscriber growth, and optimized US$45 million in revenue. The operating rule underneath all of it: a fix you are not measuring in production is a hope with a budget.

4. Transfer through teaching

The finish line of this step is an owner who can run the system with its builder out of the room. When the owners cannot operate what you built, nothing structural has been fixed: the dependency has not been removed, it has simply been transferred to you.

Teaching is not a sideline in my practice; it is the fourth step of the method. Since 2023 the step has run year-round in a Canadian classroom: 200+ students a year at St. Lawrence College in Kingston, Ontario, in courses that stretch from accounting and finance to business strategy and information systems. And the 97% adoption figure above was earned the same way: it took coaching and patient explanation across seventeen African markets, because no data system is real until the people it was built for run their daily decisions through it. In consulting terms, transfer means documentation, training, handover, and a scheduled exit. The handover belongs in the scope from day one, not in a negotiation at the end.

Why is teaching the audit of the other three steps?

Because a failed transfer is itself diagnostic. If nobody but its builder can run a system, one of three things is true.

The diagnosis was wrong. A genuine root cause can be explained in plain language with a figure attached. If the explanation cannot survive a classroom, the analysis was a hunch wearing structure.

The architecture is too clever. A design only its author can maintain has not removed a dependency; it has replaced one. Consultant-dependency is a symptom too, and a common one.

The build ignored its operators. If people route around a system rather than through it, the system was measured against the wrong reality. The clerk who runs month-end knows things the architect does not.

Teaching, in other words, is not the victory lap. It is the audit. Explaining a system to the person who must run it exposes every hidden assumption in the design, and students make rigorous auditors because they have no stake in nodding along. The same test travels beyond business: a governance system, too, is only real when the institutions that own it can run it without its designers.

How do you run the loop this quarter?

A quarter is long enough to run the loop once on one problem, and short enough to keep you honest. Here is the version I would give a small or medium business.

Pick the fix that never holds. Choose one problem your business has "solved" at least twice in the past 18 months. Recurrence is the tell; it marks a symptom with a structure behind it.

Diagnose in the numbers, weeks one to three. Pull twelve months of every figure that touches the problem: margin by product and customer, receivable and payable aging, credit notes, rework, payroll hours against output. Write the root cause as one falsifiable sentence with a figure in it. If your records cannot support that sentence, you have already found the real root cause, and it is a data problem.

Architect the smallest structural fix, weeks three to five. Prefer a pricing rule, an approval threshold, a rebuilt chart of accounts, or a data model over new software. Name the one number that will prove the fix worked, and the date by which you expect it to move.

Build inside the quarter, weeks five to eleven. Ship it, then measure that one number weekly. If it does not move, go back to the diagnosis rather than applying more force to the fix.

Transfer, weeks eleven to thirteen. Teach the system to the person who owns it, in their language, then step out of the routine. The first month of the next quarter is the exam: the system runs without you, or you loop back to find which of the first three steps failed.

Then do the arithmetic on the cadence. One loop per quarter is four structural fixes a year. The alternative is the same four symptoms, re-treated every quarter, at the same annual price, indefinitely. The compounding favours the loop.

I hold my own work to the same test. 1Carton, the SaaS product I build under Stratborne, runs on this loop, and I write its production code myself, so the architectural decisions are mine to live with. If your business has a fix that keeps needing to be reapplied, that is not bad luck; it is a symptom announcing its system. Start in the numbers. The longer story of where the method comes from is on the about page, and if you would rather run the loop with a second pair of eyes, start a conversation.

Receipts

• Oracle FLEXCUBE core-banking implementation and IFRS conversion: Intercontinental Bank head office, Lagos, 2007 to 2012. Intercontinental was merged into Access Bank in 2011; the role continued on the technical integration team, and the merged bank grew to operate across 12 countries with more than US$12.5 billion in assets.
• MTN Nigeria, 2012 to 2015: pricing analytics, geospatial analysis, and business planning models for an operator with 47.4 million subscribers and a 47.8% market share.
• MTN Group (West and Central Africa), 2015 to 2019: regional operations and performance analysis across nine West and Central African countries, resident in Nigeria and travelling to the operating companies from the group's Johannesburg base. Seven of nine operations were loss-making at the outset; all nine were profitable within two years, with NPS rising across every market. The turnaround was led by regional vice-president Karl Toriola; I built the performance analysis and planning underneath it.
• MTN Group Fintech, 2019 to 2023: decision support and analytics across seventeen African markets running mobile financial services, for a customer base above 200 million; mobile-money users grew from about 35 million to 72.5 million (2019 to 2023). BI adoption reached 97% across the organization; 21.4% subscriber growth; US$45 million in revenue optimized.
• St. Lawrence College, Kingston, Ontario, 2023 to present: 200+ students a year across accounting, finance, business strategy, and information systems.
• 1Carton: the flagship SaaS product for small businesses, in build under Stratborne, which I incorporated in Kingston, Ontario, in November 2024. I write the production code.