Domain Knowledge Is the Bottleneck, Not Python
Getting StartedAug 8, 202612 min read

Domain Knowledge Is the Bottleneck, Not Python

Every technical skill in analysis is now cheap. Domain judgement is the only expensive input left. Act accordingly.

QI

Quantified Insights Lab

Data Education & Analytics

AI closed the tooling gap in eighteen months. It did not close the other one and that is the whole story of what analysts are worth now.

In 2023 I published an analysis of hospital emergency room data. I calculated the average wait time before a patient was seen by a consultant. It came to 35 minutes. I wrote one sentence about it:

That's a lot for an emergency patient.

Then I moved on to the next column.

The SQL was correct. The aggregation was correct. The article did reasonably well. And that sentence is the exact point where the analysis stopped and the exact point where it should have started.

I have spent most of the last eighteen months not writing. I was doing the analysis for other people's research somewhere north of fifty dissertations across infection prevention compliance, TB case detection yield, vaccine cold chain practice, oral PrEP acceptability, maternal health service uptake, dietary diversity, menstrual hygiene, food safety, and hypertension in occupational cohorts. Cleaning their data, correcting their statistics, rebuilding their results chapters, and then sitting in rooms watching some of those results get defended.

In that period I watched a specific failure happen repeatedly, to people whose technical work was clean.

It is the same failure I made in that 2023 article. It is the failure I now think is the central problem in how analysts are trained. And in 2026, with AI absorbing most of the technical labour, it is the only thing left that determines whether an analyst is worth hiring.

The four-minute collapse

Here is what it looks like from a seat at the back of the room.

A candidate presents. The dataset is clean. The tables are formatted correctly. The regression ran. The p-values are reported. Everything a bootcamp would grade as complete is complete.

Then someone on the panel asks a question that is not about method.

You've grouped facilities by ownership public and private. Your private facilities show better outcomes. Did you check whether private facilities in this state refer their complicated cases out?

And the analysis is over. Not because the statistics were wrong. Because the variable never meant what the analyst assumed it meant. Referral patterns were the entire explanation, the model had no way of knowing that, and neither did the person who built it.

The categories of collapse repeat:

  • Comparing mortality across facilities without case mix. One is a tertiary referral centre. It receives the sickest patients by design. Its raw mortality rate is supposed to be higher, and reporting that as a performance difference is not a finding, it is a misunderstanding of how a health system routes patients.

  • A coverage denominator that doesn't match its numerator. Immunisation doses given at a facility include children brought from outside the catchment. Divide by catchment population and coverage exceeds 100%. I have seen that number reported without comment more than once.

  • Self-reported practice collected in front of a supervisor. A 94% hand hygiene compliance figure is not a measurement of hand hygiene. It is a measurement of what people say about hand hygiene when their line manager is standing there. The instrument produced the result, not the practice.

  • A sample drawn from people well enough to attend. Occupational health screening data describes workers who showed up for the company medical. The workers whose hypertension is worst are disproportionately the ones who didn't.

None of these are statistical errors. Every one would pass a code review. Every one is fatal.

The pattern is always the same: the analysis was performed correctly on a question the analyst did not understand.

The thesis

The bottleneck in analytical work has never been the tooling. It is the ability to know what a number means in the setting it came from.

I argued a version of this two years ago and it remains the most-read thing I have written, which tells me people recognise the problem even when they cannot name it. But I argued it too softly, and I argued it before AI made it urgent.

The strong version is this:

Every technical skill in analysis is now cheap. Domain judgement is the only expensive input left. Any career strategy that inverts this is a strategy for becoming redundant.

What changed, and what didn't

Give a competent AI model the same emergency room dataset I had in 2023. It will do everything I did, faster and better. It will profile the columns, handle the datetime parsing, compute the mean wait time, produce a distribution, build a clean visualisation, and write a paragraph explaining that 35 minutes is above benchmark for emergency care.

It will also stop in exactly the same place I stopped.

I spend my working life around how health data gets made who writes what, on which form, under what pressure, and what happens to it afterwards. From that vantage point, here is what the same table looks like.

35 minutes for whom? Emergency departments triage. A patient in respiratory distress and a patient with a sprained ankle are not in the same queue and should never be averaged together. An overall mean is a number that describes no actual patient. The figure that carries meaning is door-to-provider time stratified by acuity, and the band that matters urgently is the highest one. A department with a 35-minute overall mean and an 8-minute high-acuity mean is performing well. The same mean with a 30-minute high-acuity band is a patient safety problem waiting to be written up.

Who isn't in this table? It records patients who were seen. It does not record patients who arrived, waited, and left before anyone saw them. Left-without-being-seen is one of the most informative things an emergency department produces, and it is structurally invisible in a file of completed encounters. The waits of the people who gave up are missing precisely because the wait was too long. The missingness is not a nuisance. It is the finding.

Why does nothing exceed 60 minutes? My 2023 article reported a maximum wait of exactly 60 minutes and treated it as a real observation. A ceiling that clean is almost always an artefact of how the value was captured a bounded field, a dropdown that stops there, a form that asks for a band rather than a time, or a local rule that reclassifies anything longer as a different encounter type. I reported a data collection constraint as a clinical fact. Anyone who has watched that field being filled in would have caught it in seconds.

When are patients arriving relative to when staff are there? I noted that arrivals peaked at 11pm and 7am and found it interesting. Interesting is not a deliverable. The deliverable is the gap between the arrival curve and the duty roster, because that gap is the only part of this anyone can act on.

Not one of those four questions is technical. Not one requires a library, a model, or a line of code you don't already know. And not one is available to a system human or artificial that has never seen how the record gets created.

AI eliminated the gap between knowing what to do and being able to do it. It did nothing to the gap between having a dataset and knowing what to ask it. That second gap is where analytical value now lives, and it has become dramatically more valuable because the first gap no longer filters anyone out.

The objection worth taking seriously

The obvious counterargument: this is a convenient thing to say if your technical skills are weak. Tools do matter. An analyst who cannot write a window function or debug a merge is not going to do serious work, domain knowledge or not.

That is correct, and I want to be precise.

Technical skill is a threshold, not a differentiator. Below it you cannot function. Above it, additional technical depth produces sharply diminishing returns on the quality of the answer, while additional domain depth does not diminish at all.

The threshold is also lower than it was, and falling. Most analytical work in a health setting is descriptive statistics, correct denominators, appropriate stratification, and honest interpretation. The techniques are not exotic. The judgement is.

So the argument is not learn less Python. It is stop treating Python as the thing you are accumulating. Cross the threshold, then spend the next decade on the thing that compounds.

What domain knowledge actually is

The reason people don't build it deliberately is that it sounds mystical something you either absorb by osmosis or don't. It isn't. It decomposes into four learnable things.

1. What the variable means where it was recorded. Not the column name. The thing that happened in a room that caused a value to be written down. Who entered it, on what form, under what time pressure, with what incentive, and what they do when the answer doesn't fit the box. "Diagnosis" written into a paper register at the end of a twelve-hour shift is a different variable from "diagnosis" in a coded discharge summary, even when both arrive in your dataframe as a string.

2. Who is missing and why. Every dataset records who reached the system. In health data, the people who did not reach it are usually the people the analysis is about. Facility data excludes those who never came. Survey data excludes those who declined. Follow-up data excludes those who died, moved, or gave up. Missingness in health records is essentially never random, and treating it as random is the most common serious error I correct in other people's work.

3. What would have to be true for this result to be wrong. The single most useful analytical habit I know. Before reporting a finding, generate the three most plausible non-findings measurement artefact, selection effect, confounding and check each one. This is what a panel does to you. Doing it to yourself first is the entire difference between an analyst and someone who runs analyses.

4. What decision this number is attached to. Numbers in a health system exist to change something: a roster, a budget line, a referral pathway, a stock order. An analyst who doesn't know which decision their number feeds will produce technically correct output that nobody uses. Most dashboards fail here, not on the maths.

What to do about it

If you already work in health. You are holding the scarce input and you have probably been told it's worthless. It isn't. Someone who has run a records department understands what a folder number does to a duplicate rate in a way that cannot be reconstructed from a dataset, and that understanding is the expensive half of the job. Your task is to cross the technical threshold genuinely cross it, not gesture at it while treating your health background as the asset rather than the thing you're escaping.

If you're a technically strong analyst entering health. Your task is the inverse and it is harder, because your existing skills will let you produce confident, fluent, wrong work indefinitely without feedback. The correction is exposure. Sit with the people who generate the data. Watch a register being filled in. Ask a records officer what happens when a patient arrives with no folder. Read the data collection instrument before you read the dataset. Six hours in a facility will change more of your analysis than six months of courses.

If you're working with AI, which is all of us. Use it for everything below the threshold code, syntax, boilerplate, debugging, first-pass exploration. It is better at these than you are and pretending otherwise is expensive. Then apply your own judgement at three fixed gates: question framing before anything runs, variable interpretation before anything is modelled, and the wrongness check before anything is reported. AI will not raise those gates for you. It will produce something plausible in their absence, and plausible is the specific failure mode you are being paid to prevent.

The standard

The reason I organise everything I teach around defence panels is not academic tradition. It is that the panel is the only reliable simulation of reality.

A panel does not ask whether your code ran. It asks: why that variable, why that sample, why that test, why that interpretation, and what if you're wrong. It interrupts. It does not accept "the model said so." It is exactly the interrogation a hospital management team, a programme officer, a peer reviewer, or a good manager will eventually give your work usually later, when the decision has already been made on it.

So the standard I hold my own work to, and the one I'd encourage you to adopt regardless of who teaches you:

Would this analysis survive being challenged by someone who knows the setting better than I do?

If the answer depends on nobody asking a hard question, the analysis isn't finished. It's just complete.

I did not meet that standard in 2023. The article was competent and empty, and I published it as a portfolio piece because that was what I understood the work to be. What I understand now is that the technical part was never the hard part, and every year that passes makes that more obviously true.

If you want to know where your own gap sits technical threshold, domain judgement, or analytical reasoning I built a short diagnostic that scores all three and tells you which one is actually limiting you. It takes about eight minutes and it's free: Healthcare Data Analyst Readiness Assessment →

Ayomitan Adesua is a Health Information Manager and data scientist working in a Nigerian tertiary hospital, and a graduate student in school of public health. He has handled the data analysis for more than fifty postgraduate health research studies. He founded Quantified Insights, which trains health professionals and analysts in analysis that survives scrutiny.

 

Ready to Go Beyond Articles?

Our hands-on programs give you structured learning, real projects, and expert guidance—so you can build skills that actually stick.

Explore Programs