Digital Transformation: Common Challenges and How to Handle Them

· Updated · 4 min read · Leadership

This post is for managers and executives responsible for a digital transformation programme. Most of the difficulty sits in people, governance and decision-making rather than in the technology, and four habits address the bulk of it.

What the term covers

Digital transformation means adopting new technologies and ways of working so that an organisation can meet changing customer and market demands. In practice it takes three forms, and most programmes combine them:

  1. Customer experience: the website, the customer journey from purchase to support, and how customers receive information about your brand.
  2. Internal processes: how people collaborate, run projects and share information, plus the supply chain and supplier relationships.
  3. Technology adoption: cloud, AI and similar. Buying the technology does not change the organisation without a strategy and a cultural shift to go with it.

Where programmes get stuck

Resistance to change is the most common obstacle, especially to new tools and practices, and it needs active management from the C-suite. The second is information overload: teams collect more data than they can interpret. Prioritise what you measure and use it to inform decisions. External specialists can help here, because they see your data without your assumptions.

The third is investment. Transformation costs money in people, processes and technology, so governance has to track where it goes and what it returns.

Setting the strategy

Start by documenting your current state and your customers’ current experience. Then define the desired state and list the gaps, ordered by impact. The strategy follows from that:

  1. Place the organisation in the context of its market, competitors and customers.
  2. Assess your assets, strengths and weaknesses.
  3. Analyse what your customers need and expect.
  4. Write the strategy and action plan from those findings.

Without sponsorship from the C-suite the strategy will stall, so secure that before implementation starts.

Four habits that help during delivery

Build a culture of experimentation

Test new technologies, processes and business models on a small scale and learn from the results. Make this acceptable at every level, so that decisions rest on what worked in your organisation rather than on opinion.

Improve how you decide

Large volumes of data make decisions harder, not easier. Agree which evidence a decision needs, and keep the process as objective as you can. This also limits the risk that experimentation carries.

Keep the customer at the centre

Understand what customers need and expect, and test each change against that. It also shows you where to engage them and what experience to deliver.

Get the C-suite behind it

Make the case for why the organisation needs the change and what customers gain from it. Executive backing is what carries a programme through the points where it meets resistance.

Two examples from my own teams

Both come from building the EMEA Specialist Technical Account Manager organisation at AWS in 2020. Neither involved new technology for customers; both changed how the team worked.

Onboarding. Six months into building the team, onboarding was inconsistent and mostly undocumented. External hires had a basic path, internal hires had none, and each senior TAM onboarded people their own way. The inconsistency showed in customer-facing quality. I ran it as a formal project (I was the only PRINCE2 Agile practitioner on the team) and designed a two-part framework: a common foundation every TAM needed regardless of specialism (culture, escalation, writing standards, consultative account management), plus a technical track per domain, with depth defined by senior specialists in that domain. About ten senior TAMs from EMEA, the Americas and APAC built the content with me, which gave the framework global ownership from day one. Some specialists worried about over-standardisation; I worked through that with them rather than overriding it, and the design let each track change independently as services evolved. It rolled out globally across 12 technical domains, and global CSAT rose 12% within six months of release.

Reporting. A newly adopted tracking system had no reporting for our use case, so seeing our own KPIs meant cross-referencing three sources by hand. There was no budget. My first version in Excel worked for EMEA but took hours a week to maintain once other regions wanted it. I had access to Tableau but did not know it, so I completed Tableau’s certification training through my MBA programme on my own time, in under two months, and rebuilt the dashboard. Requests from other regions went onto a single prioritised board instead of being scattered across meetings. The dashboard became the global reporting standard, cut reporting time by about 90%, and was used to build hiring plans on real demand data and to compare specialists in the same role fairly across regions.

The common point: decide on evidence, start small, and let the people who do the work shape the change.

After go-live

New problems follow implementation, and two habits apply. Manage risk explicitly: no transformation is free of it, and naming risks early lets you act before they become incidents. Keep the whole programme in view as well, rather than optimising a single step on one data point.