Digital transformation: doing what you do, but better
Digital transformation is one of the most abused terms in business. It's been used to describe everything from moving files to the cloud to complete organizational redesigns. What I mean by it is simpler and harder: changing how an organization thinks, decides, and delivers value, using technology as an enabler, not as a goal.
Why most transformation efforts fail
The most common failure mode is starting with tools. A company decides it needs to be 'more agile' or 'more data-driven' and immediately starts evaluating software. Six months later, the tools are in place, adoption is low, and the underlying problems are unchanged.
Technology doesn't fix broken processes. It amplifies them. If your decision-making is slow and consensus-dependent, a new project management tool makes that more visible and more frustrating. The work has to start upstream.
Agility as a capability, not a process
Agility gets reduced to ceremonies: standups, sprints, retrospectives. Those can be useful. They can also become a new kind of rigidity, where the process becomes the goal and the actual outcomes get lost.
What agility actually means is the ability to adapt direction based on learning. Short feedback loops. Decisions made as close to the work as possible. A culture where changing your mind based on evidence is valued, not penalized.
What this looks like in practice
It means moving from plan-driven execution to hypothesis-driven execution. Instead of 'we will build X by date Y', you have 'we believe X will achieve outcome Z, and here's how we'll know if we're right'.
It means aligning teams around outcomes rather than outputs. Not 'ship the feature' but 'improve activation by 20%'. That shift changes what gets prioritized, how progress is measured, and what counts as success.
Tools and workflows that serve the organization
The right tooling question is not 'what's the best tool for this category?' It's 'what does this team actually need to do their best work, and what's the simplest thing that enables that?'
Most organizations have too many tools, not too few. Each tool added creates integration overhead, context switching, and a new surface for information to get lost. The discipline is in adding only what genuinely removes friction.
How I approach tool selection
I start by mapping the actual workflow: where do decisions get made, where does information live, where does things slow down or get lost. That diagnosis usually reveals that the problem isn't missing tools, it's unclear ownership and inconsistent process.
When tooling changes are warranted, I evaluate them against adoption likelihood as much as capability. A tool that's 80% as capable but actually gets used beats a perfect tool that nobody touches.
Building internal adoption
The hardest part of any transformation is not the technical implementation. It's getting people to change how they work. That requires clarity about why the change is happening, what it means for each person affected, and what success looks like in concrete terms.
I've seen transformations fail because leadership communicated the vision but not the reasoning. People comply when they have to and revert when they can. Genuine adoption requires understanding, not just instruction.
My role in transformation work
I act as a facilitator and a catalyst, not a consultant who delivers a report and leaves. The work is to help leadership and teams build shared understanding, clarify responsibilities, and create feedback loops that sustain change over time.
That sometimes means having uncomfortable conversations about what's not working and why. That's the part most transformation projects skip, and it's usually the most valuable.