3 biggest reasons why a company’s digital transformation fails

Watching technology spread throughout almost every industry has been one of the most fascinating things I’ve watched over the course of my career. Companies, who 15 years ago thought setting up internal storage, firewalls, and VPNs were as technical as they’d ever get, now have entire engineering teams devoted to building apps and services. 

Whether it’s a shoe company using apps to supercharge e-commerce, department stores building tech to boost in-store and online sales, or heavy equipment makers building tech services and autonomous tractors, I’ve watched so many old-guard companies undertake huge digital transformation so they can survive and compete.

Change is hard, though – especially the massive systemic changes required by digital transformation. In my 20 years in tech, I’ve worked with several companies where the initiative for change was there to start, but the end results were lackluster. 

[Read: You need to stop hiring ‘cultural fits’]

It’s rarely a complete failure – pockets of success usually exist within teams or departments – but when big projects stall, I have almost always seen a common set of patterns emerge. Here are three that throw up the biggest roadblocks and how to get around them.

Teams don’t buy into the plan

Managing any big, structural change has to come from the bottom up, rather than simply mandated from the top. The first thing leaders in any organization focus on before starting structural change – whether it’s installing a new email system or security tool, or reorganizing an entire business unit around DevOps – is how they can pull everyone along in those efforts. 

If there’s a cadre of cynical employees who think an important project is just the next fad, I assure you, it will be.

It’s essential that leaders realize that these projects require cultural change along with procedural change. Do employees understand how the role they perform changes and evolves in the new world they’re entering? Do they want to be a part of it?

A good strategy to combat these problems is to make sure that each organization involved in any big change has internal champions people can rally around.

Champions can’t simply be appointed, though. The key is look for someone who truly understands why a project is important and is motivated and inspired to get it done. An employee who understands how and why a project will make things better for their jobs as well as for the people around them, will.

Part of owning or running large projects is knowing what motivates the people delivering on that project. I’ve seen a few times where a company will make launching a new project into a huge production, then someone will get up and attempt to rally the employees by telling them how much it will affect earnings per share. 

Well, I may not have a ton of stock, so that doesn’t matter to me, so how does that make me fired up to get this done? Think of simple ways to incentivize great work. Maybe the team that has the best results gets a vacation, or more budget for another project.

Companies fail to standardize

I once worked at a place that used five different operating systems in distributed environments. It didn’t start off that way, but the culture was such that if a group of people decided that they wanted to use a new OS, they would do so and it would eventually become part of how we did things. 

This burden was minimal for application teams, as to them, they had one standard way of running that specific application. 

To the systems teams, however, there were n+1 ways to do things. Each process that involved operations systems now had another branch. This meant audits, security controls, monitoring, backups, and provisioning now have another branch in the process – another if statement. Each “if” statement adds complexity. There are two paths to verify. Over time, you realize you’re creating drag on the organization, and with a new language that’s more or less in perpetuity.

This created huge costs – not just in money spent, but also in huge amounts of time and energy wasted – and opened up a huge window for other problems.

Ultimately, it took nine years for that company to go from five major operating systems to two. This cemented the importance of standardization for me, because in the end, the people that made the operating systems selection for their application didn’t get to see the pain of their decision through.

Change moves faster when variation in tools, practices, or processes are reduced. For large enterprises, implementing new standards is a monumental effort that can take years. It usually means that somebody will have to give up things that matter, and it will hurt, but it also means fewer things to evolve and move forward as change happens. 

Hard choices always happen here, but there are no shortcuts. If they don’t, a variability drag will follow the project in perpetuity, throwing up roadblocks in the worst places. Standards need to be about global optimization, and everybody needs to understand that at times a global optimization is a local suboptimization. That doesn’t mean it’s wrong.

Standards act as a tool to reduce variation. Less variation needs fewer adaptations, fewer true-ups and less hassle, because there are fewer “if” statements.

No willingness to change

I’ve seen this one a lot. I’ve worked with so many companies that want to be better but are unwilling to change anything.

Once, I was in a meeting with several executives from a large bank one time, discussing engineering strategies and I kept hearing people say, “They won’t let us do that.” I heard that a few times and then finally asked, “Who are they? I thought you were they!”

There’s no rate limit on how fast an organization can move, only on how willing they are to upend the norm. To be fair, that’s not easy – people don’t like to upend their work. They know the tools and strategies that help them succeed, and generally are averse to changing that. Transformative change, however, usually requires that they do.

Change is a constant, and leaders need to both understand it and always be aware of it.

Conclusion

When I see a stalled project, I start by looking for one of these three flaws and dig in to see how it can be fixed. I also try to amplify successes to show the rollout is merely stalled and isn’t being given up on. Every project hits rough patches and if a team sees how they can move forward, however so slightly, they’ll get some inspiration from that.

Lastly – and very importantly – note that, in nearly all cases, everything I’ve talked about is more cultural than technical.

In any technical organization, a manager’s main job will be to manage their team’s motivation and morale. It’s not always second nature for technical minds to think strategically about how to tug on people’s intrinsic motivations, but it’s an essential skill to learn.

Change is never easy, and not getting buy in from teams, failing to standardize, and uneasiness with change are the most common roadblocks that keep it from happening that I see. If companies put in the necessary time, energy and willpower it takes to overcome them, it will always pay off in the end.