Why most data transformations stall at the platform, and what has to fall first.
Most data transformations I've seen over twenty years of watching, buying, and running them have failed in almost exactly the same way. The failure isn't the platform. The failure is the sequence.
A company decides it's time to modernize. Leadership approves budget. A consultancy shows up, runs a discovery workshop, and recommends Databricks or Snowflake or Fabric or whatever the current answer is. Build begins. The platform comes online. Dashboards get published. There's a launch lunch.
Twelve months later, the platform is still technically running, but nobody trusts the numbers. The team that built it has rotated out. New reports get built in Excel. The cube that was supposed to be the single source of truth has three competing definitions of revenue. The organization is somehow back to where it started, plus a cloud bill.
I've watched this play out in four industries. It's not a technology failure. It's a sequence failure.
The idea that gives Domino its name
We're called Domino Collective because the work of real transformation looks like a cascade of dominos falling in order. Five of them. In a specific sequence.
Most firms sell you the fourth domino, the platform, and call it transformation. That's like selling you a beautiful kitchen without checking whether you can cook, whether anyone's going to eat the meals, or whether the ingredients will arrive on time. The kitchen works. The dinner doesn't happen.
Here's the sequence that actually compounds.
01. People
Nothing lasts if the people can’t hold it.
This is the domino everyone wants to skip. People questions are soft, slow, and uncomfortable. Do we have the right skills? Is the leadership capable of governing a modern data program? Do the owners of the key business processes have the bandwidth to actually adopt what we’re building? Are we upskilling our own team or just renting someone else’s?
I’ve been in rooms where executives wave this away with phrases like “we’ll figure out the people side later.” Later means never. Later means the platform goes live and the only people who understand it are the consultants who built it. Later means a $2 million annual dependency on an outside firm because the internal team was never part of the design.
The clients who get the most value from us are the ones who let us address People first. Sometimes that means hiring a Data Engineer before we’ve picked a platform. Sometimes it means coaching a senior leader on how to govern a data program, not just fund one. It’s almost never sexy work. It’s always the work that makes everything else possible.
02. Ways of working
How decisions get made. How work moves. How teams learn.
This is the domino that looks bureaucratic until you skip it. Without explicit ways of working, a backlog, a sprint cadence, a review rhythm, a deployment process, every decision becomes a judgment call and every judgment call becomes a negotiation.
I've seen data programs where every change required a Slack thread, three meetings, and a spreadsheet someone maintained in their head. Velocity at the start of the year: fine. Velocity by Q3: glacial. Not because the team was bad, because there was no mechanism for the team to move quickly without re-litigating every decision.
A real modernization introduces the plumbing of how work happens. CI/CD pipelines. Pull requests with actual reviews. Stand-ups that aren't theater. Sprint showcases that include the business, not just IT. Monthly progress updates that review accomplishments, challenges, scope shifts, and budget adherence, so there are no surprises at the steering committee.
Ways of working are the mechanics that turn intentions into output. Skip this domino and the fourth one, the platform, inherits a team that can't reliably change it.
03. Culture
Shared norms, trust, behaviors. The difference between adoption and avoidance.
Here's the uncomfortable truth about data transformations: the platform can be beautiful, the governance can be rigorous, the reports can be accurate, and the business can still ignore all of it. Culture is whether the business *believes* the data. And belief isn't earned through technology. It's earned through repeated experience of the data being right when it mattered.
I've watched companies ship a flawless migration and then discover that the Finance team was still running the old spreadsheet model alongside because they didn't trust the new one. Not because it was wrong. Because they had no cultural muscle for trusting something a consultant had built without their involvement.
The fix isn't a change management slide deck. It's weekly sprint reviews with the business. It's named stakeholders who get named data quality problems. It's issues surfaced and corrected in real time so data stewards can vouch for accuracy across the organization. It's training that happens alongside the build, not after it.
Culture is the domino that, when it falls right, makes the platform feel *inevitable* to the business. When it falls wrong, the platform becomes a curiosity parked next to the "real" way the business runs.
04. Technology platforms
Architecture, tools, engineering. Built to last.
Now, and only now, we talk about the platform.
Databricks. Microsoft Fabric. Azure. AWS. Unity Catalog. Delta Lake. CI/CD pipelines. A medallion architecture with deliberate separation between raw, staged, and business-ready layers. Whatever the specific stack, the platform is the fourth decision, not the first.
This ordering is almost the opposite of how most consulting pitches go. Most firms lead with the platform because platforms are what consultants know how to sell. "We're a Databricks partner." "We're certified in Snowflake." "We'll implement Fabric for you." The platform is the visible, sellable, billable object.
And the platform, by itself, is insufficient. If the first three dominos haven't fallen cleanly, if the people can't run it, the ways of working can't sustain it, and the culture doesn't trust it, the platform will be a technically impressive monument to a failed transformation.
The platforms we work with are all good. Databricks is excellent. Microsoft Fabric is excellent. The cloud infrastructure options are all mature. The question isn't which platform, the question is whether the three dominos in front of it have fallen properly. When they have, the platform is the *accelerant* on an already-moving program. When they haven't, the platform is a liability.
05. Data and analytics
Governance, insights, modeling. Decisions you can trust because the data earned it.
The fifth domino is what everyone thinks they're buying when they start the project. It's the dashboards, the cubes, the models, the decisions that get made differently because the data is finally trustworthy.
And the fifth domino only works, really works, if the first four have fallen. Data and analytics on top of capable people, disciplined ways of working, a culture of trust, and a sound platform: that's when you get compounding. A master data reconciliation across eight source systems becomes the foundation for a DOI variance process, which becomes the foundation for a corporate asset list, which becomes the foundation for a finance model, which becomes the foundation for automated forecasting. Each build reuses the last. Each build makes the next one faster.
Data and analytics on top of a team that can't run the platform, ways of working that don't scale, a culture that doesn't trust it, and a rushed platform: that's a spreadsheet with extra steps.
Why this matters for how you buy
If you're evaluating consulting firms for a data transformation, or worse, if you're a year into one that feels stuck, the five dominos are a diagnostic.
Ask your current or prospective firm how they think about the sequence. If they lead with the platform, they're selling you the fourth domino. If they lead with "our people will work alongside yours," they might be starting at the first. The language of compounding ("each piece makes the next one easier") is a signal. The language of deliverables ("we'll ship X by Y") is too, but a different signal, deliverables without a compounding story are just expensive outputs.
Also ask what happens to your team after the consultants leave. If the answer is "we'll transition everything to documentation," run. Documentation is where knowledge goes to die. The real answer is "your team will have been building alongside ours for so long that the transition is a formality." That's the fifth domino, earned.
A personal note
I didn't come up with the five dominos as a marketing framework. I watched them work, or fail to work, for twenty years on the buyer side of engagements. I've been the client who approved the platform build that nobody on my team could maintain. I've been the client who discovered that the "senior" names on the pitch deck had been replaced by juniors three months in. I've been the client who realized we'd built a beautiful piece of technology for a business that was never going to use it.
Domino Collective is the firm I wish had existed when I was buying. Small, senior, embedded, slow to make promises, fast to keep them. The five dominos are not a pitch. They're how the work actually has to happen if any of it is going to matter.
If this article resonated with a situation you're in, the thirty-minute conversation is open. No proposal attached.
About this piece *This is the first essay in a monthly Insights series on data, capability building, and what real engagements teach us. The next article examines what buyers actually want from consultants, drawn from two decades of buyer-side experience. You can subscribe for one email a month at dominocollective.com/insights.* *Mike Henry is the founder of Domino Collective, a Calgary-based data and technology partner. He's on the SAIT data analytics advisory board and previously spent twenty years on the buyer side of enterprise technology and data transformations.*
