So your move towards becoming a digital leader is consuming vast amounts of resources and you’re wondering when the hefty payoff will finally come about?
Wonder no more, here’s your answer: it’s not coming.
The relevance of becoming more digital can hardly be overstated. It is very high up on the agenda of almost every CEO and yet, it’s completely misunderstood by most.
It seems that while many jobs can be automated, the increasing complexity of the digital landscape requires hiring more and more of the (expensive) services of specialized providers (i.e. consultants). The reason for this is what I call:
The Digital Sisyphean Cycle
It begins when someone (often a consultant) uncovers a potential for optimization by leveraging a digital solution. A tool assessment is carried out (often by consultants) and the “best tool”, according to some criteria that were cobbled up in a handful of workshops, is implemented. Once it’s there, the employees are being trained to perform their previously analogue job in the digital realm. Typically, the original task can be carried out much faster. However, very soon new tasks emerge. They revolve around the new tool: Administrational to dos as well as translational duties to bridge the gaps to other business areas and functions.
And here the cycle begins anew to rid the organization of this eas ily automatable stack of annoyances. Compared to the first run, there is one noteworthy difference: In the first cycle the focus lay on optimizations of the original purpose, a process that presumably was somehow contributing to the value creation of the organization. In the second cacle, the scope now revolves around reducing administrational overhead. So, in the first cycle, the consultants were talking to specialized employees of the organization. In the second cycle, it’s not uncommon that the “new” consultants now exchange requirements with other, “old” consultants that implemented the first tool and the actual employees of the organization can only contribute bits and pieces. That is because the discussion is not about value creation anymore, but about fighting systemic complexity.
In large organizations, one of these cycles can easily take twelve to 24 months (or even more). So after two to three cycles, it’s common that people lose track of how digitization actually contributes to the overall organizational goals. And on top of that, due to the rate at which technology evolves, the original tool stack will be outdated and must soon be replaced with an updated version of the tool, or an entirely different solution.
This begs the question: Is that just how it is? Do you need complexity to fight complexity?
Moving from Digital Transformation to Value Transformation
Let’s assume for a moment, that instead of implementing tool stacks that simply shift complexities from operations to a more diffuse level, you could focus your transformational efforts on improving the value generation and use the right tools as the means towards the right ends.
That instead of fighting increasing levels of administrative overhead, the (digital) relaunch of a set of processes makes the overhead manageable and dispensable in the first place.
That instead of bending cutting-edge tech to somehow fit into outdated processes, you were able to purposefully redesign your value chain around newly available technologies.
You’d be able to build your enterprise of the future around delivering customer value, putting innovation and efficiency at the core of your organization.
And this can, in fact be achieved! The solution is to purposefully build an enterprise architecture before working on process improvements and implementing tools.
Specifically, the answer lies in enterprise engineering.
Skipping enterprise engineering is like skipping leg day in the gym. Doing so will get you to progress faster at bench pressing, but will eventually allow an 8 year old to outrun you on your way to the ice cream stand. Skipping enterprise engineering will make some pockets of your enterprise lightning fast but allow many competitors with a broader vision to outmanoeuver you on the broader market.
To fully understand where things are going south, let’s take a step back: In order to understand why most digital transformations fail to deliver their expected value, you need to understand two key topics:
The actual difference between digital and analogue (hint: it’s not what you think)
The fundamental engineering principle of abstraction (spoiler: it’s not as boring as it sounds)
Digitalization 101 - Moving from Analogue to Digital
The definition of digital is: “recording or storing information as a series of the numbers 1 and 0”. So it sounds as if scanning a piece of paper and storing it on a computer is exactly what digitization is about. But it turns out that, while that’s technically true, it’s often missing the point. Because the whole point of digitizing an object is to enable multi-purpose interactions with it. Most digital processes are stored as ones and zeros, but there is still a defined set of steps required to carry out the process itself. So most of the time what’s being created by the perceived digitization is an analogue process that happens to be stored on a digital medium.
Sounds strange? Here’s an example: Let’s say you scan a piece of paper and it’s being stored on a computer. Did you digitize it? Yes and no. The storage solution is digital. If the purpose is to send the document to multiple people and someone ends up manually creating a number of emails, putting in the text and attaching the document, you have created an analogue process that coincidentally is carried out while using a computer. A less digital, but more efficient solution would be create copies of the physical piece of paper, print a list of labels for each of the recipients in one batch and then let the entire batch of papers run through a folding-and-inserting machine.
For a good story at your next party keep the following two examples in mind: a physical Abacus is a digital multi-purpose device that has been around for millenia. A computer chip that is specifically designed for blockchain calculations happens to run on electricity and uses ones and zeros, but it is still an analogue device.
So in a nutshell (and slightly oversimplified): Digital solutions are multi-purpose, analogue devices serve specific purposes.
Now how is all of this related to the digital transformation of organizations? I’m so glad you asked! Let’s move on to abstraction.
Abstraction in a nutshell - thinking in layers of indirection
When building (or programming) a system to solve a problem, you are building something that needs to complete a set of tasks that each require a series of steps. Fundamentally, such a system is always comprised of three layers:
Layer 1) At the lowest level, you have a routine that carries out the steps required to complete a task. In an organization, a routine is represented by employees who follow certain processes. The goal of most digitization efforts is to replace parts (or everything) of what the employees do with a routine that is carried out by a computer.
Layer 2) One level higher, a routine is required to understand the problem space. It directs the sub-routines in layer 1. In an organization this what a team lead does. This is where most digitization efforts reach their natural limitations.
Layer 3) The highest level of abstraction (as far as the scope of this article goes): This is a routine that solves a problem or completes a task by directing the routines in layer 2. In an organization, this is what a manager does. Mostly when attempting to digitize on this level, you will encounter resistance in the form of “this is too complex to be digitized” (spoiler alert: it’s not).
Almost all digital transformation efforts focus on layer 1. Some aspire to digitize parts of middle management (layer 2) while very rarely they attempt to take a shot at layer 3.
So how does this abstract concept of abstraction help with digitization programs?
To answer this, we need to start with a famous quote in the programming world: “All problems in computer science can be solved by another level of indirection."
Indirection in software engineering is the concept of building highly decoupled components, each built to perform separate tasks. Abstraction is a concept used by engineers to create reusable, multi-purpose modules that can be used across their system.
So, didn’t we build digital components just like in the books?
At first glance, looking at your digital transformation, this is exactly what you’re doing all along, right? Building reusable, decoupled components within your organization. The key difference between your organization and leading practices in system engineering is, that the system engineers build an architecture first, and then start building components that are clearly documented and can be called from across the system. In the typical organizational transformation, the components and modules are built haphazardly across the organization. They are organized locally, but globally within the organization they are not only decoupled, but completely disconnected and virtually unfindable unless someone knows specifically what they are looking for.
Instead of a homogenous, top-down architecture, the end result is a mosaic of different tools, standards and practices.
Transforming your… transformations
So you’ve taken the road less travelled on far too many times and it’s time for a framework that yields better results in your transformational efforts? Here you go with an easy-to-follow, three-step guide:
Step 1) Bridge the gap between expert knowledge and leadership vision
As always, a deep understanding of your business processes is essential. However, you must not stop there. The key to building a solid foundation for your transformation is to first determine how the single business processes contribute to the overall value creation of your enterprise. Once you have clarity on this, you need to follow a top-down approach to work out how a transformation will increase the ultimate value delivery. Finally, consolidate these findings into specific, desired business outcomes of your transformation.
Step 2) Construct an enterprise architecture and design your organizational model top-down
In short, the capability to fuse high-level organizational objectives into an effective organizational model that will accommodate the new, soon-to-be digital solutions, is what sets you up for making your transformation a success story.
The key is the ability to formulate your desired business outcomes on an organizational level and then transform them into specific requirements for a digital solution.
In other words: Instead of digitizing single processes and hoping that they will somehow turn out to form a coherent big picture, you’ll need to remain on a level of abstraction that allows you to keep your focus on building your enterprise architecture around the core value creation, while avoiding the undergrowth of the detailed business processes.
For this, enterprise architecture capabilities are essential to design the target organization so that the right tools can be evaluated and utilized effectively. It is vital to be clear on the differences between your target operating model and your organizational design.
Step 3) Decisively lead the change with purpose
Once the vision is established, the goals are defined and the organizational design is construed, it will seem almost trivial to select and implement the right tools and methodologies that can deliver your desired business outcomes.
However, there will be significant backlash throughout your organization. And the opposition will be broader than usual, because this time the change is not only about what the organization does to deliver its value, but how you do business.
And that brings us to an important side note: It may be tempting to venture into the the organizational purpose, your why. After all, you’re shaking up the how and the what, so why stop there? Everything is being turned upside down, so you could as well increase the scope a bit further and attempt a complete makeover.
This brings us right to how you and your leadership can and must drive the change with determination and certitude. All the fundamental changes you’re making will spark resistance and it’s essential to have a basis for argumentation you can stand on firmly. To gain real acceptance throughout the organization, your logic must be grounded in more than “because the board decided”. Whenever you’re being dragged into the undergrowth of politics, people trying to stake their claim and the “but-what-if” concerns, you need to guide the discussion back to a level where people can find common ground and agree on. This level is your organizational purpose. It gives you a sound line of argument for why the different aspects of the transformation are necessary. Your organizational why will will help you to stay the course.
With that in mind: If you can’t concoct a good three-minute pep talk that connects the purpose of your company with why the specific changes you are pushing for are inevitable, then it may be wise to revisit your plans. If you’re in the middle of things and you feel a tingle to challenge the organizational why because you can’t really connect what you’re planning with your why - don’t! You’re opening up a flank that will catch you cold once you are deep in the actual change process. Either change the planned outcomes of the transformation, or first revisit your why and then begin with step 1).
Whichever path you take: As a leader, it will be your responsibility to lead your people with confidence and decisiveness while remaining empathetic for the late majority and the laggards. They are the ones that are most fiercly objecting to change, but at the same time they are the backbone of the organization because they carry the deep knowledge that comes with long years of loyalty.
If you want to get notified when a new article comes out, join my newsletter!
Like what you read? It would mean the world to me if you'd share it on social!