I built BI for two IPOs. Here's what I got wrong.

I spent twelve years inside a global consumer cybersecurity business, building business intelligence through a NYSE listing and then, years later, a London one. At that scale, the failures you survive teach you more than the successes you ship — because the failures stay paid-for long after the press release goes out. The ones I want to talk about here are the kind no consultant writes essays about: the moments I solved the wrong kind of problem, and made the engineering elegant in the wrong place.

I now run advisory engagements as a fractional Chief Data and AI Officer for boards looking at exactly the same kind of decisions I once made — usually before the diagnosis has happened. The thing I sell, when I'm honest, is a calibrated paranoia about what kind of problem is sitting in front of us. That paranoia was bought at scale, in a real company, by my own hands. Here is how.

Mistake one — the wrong-layer mistake

My BI team needed to report on business events — subscriptions, renewals, cancellations, refunds — that should have come, cleanly and authoritatively, from the billing system. They didn't. Either the billing system didn't emit them in a form anyone outside its own team wanted to wrangle, or the work to fix that upstream felt slower than just routing around it.

The easy answer, the one we took, was: we can reconstruct those events from logs. The data is technically there. We have engineers. We can do it.

We did. And we paid for it every day, for years.

Deriving operational business events from logs in the analytical layer creates exactly the kind of brittle, slow, dependency-laden process you would never design on purpose. Every time the source system changed shape — a deployment, a refactor, a new product line — our derivation broke or drifted. The BI operations team spent more time reconciling derived events back to the source-of-truth than producing analysis. Data-quality conversations stopped being conversations and became standing meetings. The cost wasn't the engineering. The cost was the trust: a number had to be defended every single time it appeared.

The same period produced a sibling mistake, harder to admit. We let the data warehouse become the master record for customer — the golden record — and then, because the data was there and the marketing team needed it, we let the warehouse double as a campaign-execution system. Two things that should have lived in the operational stack quietly took up residence in the analytical one. The warehouse stopped being a place where insight was synthesised and started being a place that operations depended on to run the business. When it slowed down, marketing slowed down. When it had an outage, the company had one.

Both mistakes had the same shape. We let the analytical layer compensate for a gap in an operational system, instead of insisting the gap be closed where it actually lived. We told ourselves we were being pragmatic. We were being polite. The cost of that politeness was carried by everyone who came after us.

The lesson, written in the only language that teaches it: not every truth belongs in the analytical layer. Some truths belong upstream. The job of a data leader is sometimes to refuse the request, point at the source system, and force the work back to where it should live.

The classifier I now apply to any new request:

If the source system is broken or incomplete, should we be paying to fix it there — or paying ten times that amount to compensate for it here?

Almost always, the honest answer is fix it there. Almost always, the political answer is compensate here. The data leader's job is to refuse the political answer when it is the wrong one — and to make that refusal cheap enough for the rest of the organisation to accept.

Mistake two — the cooperation problem dressed as a tech problem

The second pattern is more painful, because it's harder to see. It looks like a tech problem. It has tickets. It has architectural diagrams. It has a roadmap. But the actual cause is that two parts of the organisation aren't allowed to, or aren't equipped to, work together — and the engineering is silently absorbing the cost.

The version that taught me to spot this had two halves, running in parallel.

The first half was Finance. Finance pulled almost everything out of the analytical cubes into their own spreadsheets — into what I now call spreadsheet hell — because they wanted full control over the numbers and didn't want to coordinate with IT to evolve the source. Every month they made manual adjustments, froze their copies, and reconciled against the live data, which had moved. The cubes ground under the load of repeated full-data extracts. The monthly close turned into a forensic exercise.

From inside IT, this looked like a performance problem. We tried to fix it with better caching, smarter partitioning, friendlier extracts. None of it landed — because the real problem was that Finance and IT did not have a working relationship in which evolving the analytical layer together was a normal activity. Finance was working around us. We were optimising for the workaround.

The second half was inside the engineering team itself. We had more than twenty developers, an overloaded delivery queue, and a frustrated business. From the outside it looked like a capacity problem, or an estimation problem. The truth was that knowledge of the system was held by exactly one person. The other developers were each working in their own corner of the codebase, without peer review, without git used the way git is meant to be used, without incident tracking that produced learning, and without any mechanism by which one person's insight became the team's insight. Waiting time ran into years. Rework was constant. Promotions felt arbitrary because nobody else could see what anyone was doing.

This is Conway's law in its native habitat. The architecture of our systems mirrored the architecture of our teams — and the architecture of our teams could not produce coherent systems, because the team members couldn't see each other's work. We weren't behind on tickets. We were behind on cooperation. The tickets were just the visible smoke.

The lesson: if two parts of an organisation that depend on each other don't have a working rhythm of cooperation, no amount of engineering will close the gap. The diagnosis is organisational. The prescription has to be too.

The classifier I now apply:

Before we commission this technology project — are the two or three teams who'd have to cooperate on it actually allowed to, and equipped to? If not, that is the project.

The application — what changed at the construction-logistics group

Years later, I walked into a €1bn-revenue construction-logistics business that had asked me to help modernise its IT. The brief was, on its face, a tech brief. Within a few weeks the diagnosis was the one I'd seen before. There were fifty-plus people in IT and data. The systems and the team structure had grown around each other in a way that meant changes to either were now unaffordable. The board had been told this was a platform problem.

It wasn't. So we didn't replace the platform.

We installed a different style of work — across IT, data, and the business functions that depended on them. DevOps was put in place not as a tooling project but as a way of holding work in the open. Git was used as it's meant to be used — as the visible, peer-reviewed memory of how the code became what it is. A kanban board and a light agile rhythm replaced the queue of invisible commitments. Components and patterns became reusable rather than re-implemented every quarter by someone who hadn't seen the previous version. Data was treated as a product, with named owners, defined consumers, and contracts between them. Peer reviews and small, deliberate experiments replaced the heroics of one or two people knowing everything.

None of this is novel inside a software company. In a construction-logistics group, it was the difference between an IT and data team being a bottleneck and an IT and data team being an instrument. The systems weren't replaced. The work that flowed through them was. That was the point.

The classifier I'd give a board

If I had four questions to give a board before it commissions a data or AI programme, they would be these.

Where should this truth actually live? If the answer is "upstream of where we'd build it," start there or do not start at all. Compensating in the analytical layer for a gap in the operational stack is the most expensive form of politeness in a business.

Are the two or three teams that would need to cooperate on this currently allowed to, and currently equipped to? If not, the project will absorb the cost of their non-cooperation. The teams are the project. Fix that first.

Who, by name, would be the product owner of the data or the model six months from now? If nobody is willing to put their name to it, the project has no future tense — only a present in which everyone is busy.

What is the smallest decision in the business that would change if this worked? If you cannot answer in a single sentence, the brief is not ready. Send it back.

What I now sell

I still misread problems. I expect to keep misreading them. The job isn't to be infallible at classification — it's to misread quickly, cheaply, and out loud, and to build engagements where the diagnosis is allowed to shift mid-flight when it should.

That, more than any platform and more than any model, is what I now sell. It is also why my work is informed by twelve years of getting it wrong at scale, and not only by the parts I would put on a slide.

---