Let me be honest about something: most digital operations transformations are done in the wrong order.
I've walked into enough companies mid-transformation to have a strong opinion about this. The instinct, almost universally, is to start with the exciting parts. New tools, new AI capabilities, new automation. The org chart gets a Chief Digital Officer. The tech vendors get invited in for demos. The roadmap gets built around capabilities.
And then, six to twelve months later, the transformation is stalling — not because the technology failed, but because the foundation wasn't there to absorb it.
If someone handed me the keys to a 200-person company's digital operations tomorrow and asked me to fix it, I would do four things first — none of which involve buying anything.
First: I'd Run a 48-Hour Audit of What Already Exists
Not a six-week consulting engagement. Forty-eight hours of focused discovery.
I want to know three things specifically: what tools are currently in use (including the ones nobody officially approved), where the single sources of truth actually live versus where they're supposed to live, and where the most painful coordination failures happen on a weekly basis.
The gap between the official tool stack and the actual tool stack is always informative. Shadow tools exist because the official tools are failing someone. Those failures are data. The tools that got adopted without permission tell you more about real operational needs than any requirements document.
I'd spend one day talking to people in sales, support, finance, and engineering — not their managers, the people doing the work — asking one question: what's the most annoying part of your workday that involves finding or sharing information? The answers cluster around three or four root causes in almost every organization.
Second: I'd Identify the Coordination Seams
Every organization has seams — points where information has to cross from one system, team, or workflow to another. These seams are where fragmentation costs concentrate.
The handoff from sales to customer success. The status update from engineering to product. The project brief from marketing to design. The budget request from a department to finance.
Each seam that requires a person to manually translate between systems — pull data from one place, format it, put it somewhere else — is a coordination cost. In a 200-person company, there are typically 10 to 15 significant seams. Each one is consuming somewhere between 2 and 15 hours per week across the people involved.
I'd map those seams on a whiteboard. Not to immediately fix them — to understand where the highest-leverage interventions are. The seam that costs the most time and creates the most errors is the right place to start. Not the most technically interesting problem. The most expensive one.
Third: I'd Talk to the People Who've Given Up
Every organization has them: people who tried to improve processes, got blocked, and stopped trying. They're sitting on a goldmine of institutional knowledge about what doesn't work and why.
These are usually not the loudest voices in any room. They've learned that raising operational problems doesn't lead to solutions. They've adapted to the dysfunction and quietly built workarounds that nobody else knows about.
I'd find three or four of them and ask: what did you try to fix, what happened, and what are you doing instead now? Their workarounds are usually better solutions than the official process, implemented at the individual level because the organizational level was too slow to move.
The answers tell you two things. What the actual failure modes are, without the political filtering that happens when problems get escalated through management layers. And whether there's organizational capacity to actually implement change, or whether the change-blocking mechanism itself needs to be addressed first.
Fourth: I'd Set One Metric That Everyone Understands
Before touching a single tool, before running a single vendor evaluation, before writing a single line of a transformation roadmap, I'd establish one operational metric that measures the thing we're actually trying to improve.
Not a laundry list of KPIs. One metric. Something like: average time from customer request to first substantive response. Or: percentage of projects delivered on the original scope without scope change meeting. Or: average time a new employee takes to reach independent operation.
The metric has to be specific, measurable from existing data, and visibly connected to business outcomes. Not a vanity metric that IT can report on — a metric that a COO would care about and that a frontline employee can understand their contribution to.
Everything that comes after — the tool decisions, the process redesign, the AI investments — gets evaluated against that metric. Not "did we deploy the technology" but "did the number move."
Without this anchor, digital transformation becomes a series of technology deployments without a coherent theory of what better looks like. With it, every decision has a clear test.
What Comes After
Once I've done those four things — usually in the first two weeks — I have a very different picture than the one I'd get from reading the existing strategic plan.
I know where the actual pain is. I know who has institutional knowledge worth preserving. I know what the political dynamics are. I know what one metric will tell me if I'm making progress.
Then, and only then, would I start evaluating what to change. Because the worst thing that can happen to a digital transformation is that it solves the wrong problems quickly. The tools are fast to deploy. The organizational dysfunction they're deployed into takes much longer to fix.
Getting the diagnosis right first is the only approach that consistently leads to transformation that actually sticks.
Top comments (0)