What makes digital execution tick

  • Home
  • /
  • Digital Transformation Blog

Digital Transformation Blog

Practical insights on the digital revolution

What makes digital execution tick

Good execution has always been an important value driver. So, what’s so special about digital execution?

As we move to a digital world, the factors of production are changing from being primarily physical items (plant, warehouses, machinery, …) to being primarily digital items, such as software code. With that shift, the execution premium is moving from detailed upfront planning to iterative, “always on” execution.

When investing large sums in physical assets that cannot be easily moved or altered, it’s important to make the right decisions upfront: where to locate a plant, what capacity to build, and so on. And iterative execution is entirely impractical as error correction can be prohibitive. But when investing in software, it’s typically more efficient to create a high-quality product by exposing it to its users early, and iterate it quickly based on real world feedback. Investments are made in smaller increments (maybe weekly “sprints”) and improvements can be made quickly in situ. And in any case, it is often impossible to know upfront what will ultimately work with users. Hence the focus on “Minimum Viable Products” and agile software development processes.


broken railway bridge_1022851228

Iterative execution doesn’t always work.

However, it’s not enough to deploy agile software development. Rather, an organisation must rewire itself more comprehensively for successful execution in a digital world.

Whilst there are many ways to structure the requirements for success, we have found four elements to be common across industries:

1. User focus

This might seem obvious and it’s easy to say, but really difficult to hardwire across the organisation. In a digital world, decision making needs to be decentralised: agile teams make decisions about features and user designs daily. For those teams to make the best decisions, they must be exposed to user feedback on a granular, but also a macro level. People building a customer service app, for instance, need to understand the organisation’s long-term product roadmap, as well as whether users are more likely to respond to radio buttons or tick boxes.

It’s all about balance: too much granular user input runs the risk of building a beautiful app that delivers no value. Conversely, overemphasising the organisation’s financial goals can yield a high margin product that doesn’t sell because it is too hard to use.

An added complication is that for large multi-product organisations, users carry their existing perceptions and needs when they visit the company website or app. Their expectations will be higher and their needs broader when compared to a “born digital” single product company. Nothing is more annoying than being told to “please call us or visit a store” after installing a customer service app.

It is therefore paramount that user adoption be used as a metric right across the organisation. After all, if no one is using a digital asset, it will not deliver any value either.

2. Iterative, fast to market approach

Again, it’s easy to say “we’re agile” and use phrases like “let’s fail fast”. But in practice, such a mindset is directly opposed to many traditional ways of running a large company: from annual, fixed budgets, the prevalence of financial KPIs to fixed project approvals - none of these tools are naturally conducive to a fast-to-market, iterative way of working.

In a digital world, a project is not finished when a product launches. In many ways, the work starts in earnest only after the market launch. And the very definition of “launch” is being challenged: should you launch a “pilot,” a “beta”, or a fuller version?

Business cases need to allow for ongoing work on a digital asset and adoption expectations need to reflect that it will likely require several iterations post launch before user take-up reaches a meaningful level.

Ultimately, leadership is critical to guide a team, project or product through the murky waters of uncertainty until, finally success is achieved - or to make the difficult decision to cut your losses and abandon the pursuit.

3. Business – technology alignment

The blurring of “project” and “operations” requires a much more aligned organisation: in the old world, a product team might write a lengthy requirements document (which will invariably be half wrong), pass it on to a delivery team who then – months later – hand back the finished product. The familiar outcome is a heavily compromised solution with a healthy dose of blame.

In a digital world, product teams must be highly involved on a daily basis. Requirements are adjusted in real time and compromises made accordingly. Delivery teams are often accountable for post launch fixes, operational support and continuously evolve their own code as user requirements are becoming clearer or evolve further.

For this to occur, a new style of leadership must be present. “Old world” leaders who are used to approving granular decisions need to become “agile leaders”: leaders who provide clear guidance on objectives but leave plenty of room for distributed decision making that takes technical constraints and real time user feedback into account. The basis of leadership shifts from control to trust and support. Digital leaders inspire and attract top talent and keep their teams connected to the rest of the organisation, without compromising their freedom to innovate and execute.

It also means that a digital program cannot just be “outsourced” to a vendor. Even the most advanced platform is unable to solve complex business challenges on its own.

4. Traditional fundamentals of good execution

Finally, whilst many things are fundamentally different in a digital environment, several traditional aspects of good delivery remain important:

a.) Initiatives must be prioritised by their expected value. User adoption is a key goal, but usage must also translate into value. It needs to be clear upfront how this value is being created and measured. It’s quite practical, for example, to settle on a “value per regular user” figure upfront, and then focus on user adoption to deliver that value in a measurable way.

b.) Organisations must be “wired” to execute consistently. This includes clarity and focus on a small number of carefully chosen KPIs that are aligned throughout the company. It also means that accountabilities are clearly assigned to a single point and embedded into line management. We have seen good success, for instance, with the appointment of “user adoption managers” who were singularly focused on driving the adoption of a new app or digital feature. These managers must cover a very broad spectrum to achieve their objectives, working closely with technology delivery teams, marketing executives, call centre managers and franchise owners.

New capabilities must be built into the organisation’s core. It is not enough to hire a new agency, or partner with an agile coding shop. Treating capability gaps as a sourcing task means that critical capabilities remain outside of the organisation. For example, when we automate large portions of an organisation, a training program must be designed and delivered to build capabilities for all roles surrounding the automation (appropriate to their role and level in the organisation) – some need to know how to evolve the code, others need to know how to manage the coders, and so on.

As a consequence, several traditional elements of the organisation must be challenged and adjusted: new job roles must be created and the way those roles are graded for compensation and performance evaluation must evolve: no longer are the most valuable, best paid roles those with the most people or biggest budgets; instead, the highest paid jobs might be the ones with the biggest potential impact on customers or the ones tasked with the creation of new revenue sources.

c.) Views on organisational design should be equally questioned: efficient “spans and layers” might be better judged by the organisation’s needs, rather than department sizes. CEO direct reports (and Board composition, for that matter) must include a healthy mix of direct accountability for managing the existing businesses and creating new, digital ones. Tucking “hot” talent with the digital skills of the future into large, traditional business units is the quickest way to smother their flame of excitement.


Digital “transformation” programs are often established with a mindset that at the end of the project, everything will be back to normal. The reality is that organisations must continuously evolve, at an ever-greater rate, just to stay alive. The term “transformation” is a misnomer, rather a “permanent, ongoing re-invention” is needed.