Watching technology spread throughout almost every industry has been one of the most fascinating things I’ve seen over the course of my career. Companies who 15 years ago thought setting up internal storage, firewalls and VPNs was 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 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. 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.
1. 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 that 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.
Sponsor Note
KubeCon + CloudNativeCon conferences gather adopters and technologists to further the education and advancement of cloud native computing. The vendor-neutral events feature domain experts and key maintainers behind popular projects like Kubernetes, Prometheus, gRPC, Envoy, OpenTracing and more.
Part of owning or running large projects is knowing what motivates the people delivering on that project. I’ve seen a few instances 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, if I’m an employee and I don’t have a ton of stock, that doesn’t matter to me — so how does that make me fired up to get this done? Think of simple ways to incentivise great work. Maybe the team that has the best results gets a vacation, or more budget for another project.
2. Companies Fail to Standardize
I once worked at a place that used five different operating systems in distributed environments. It didn’t start out that way, but the culture was such that if a group of people decided 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, because they had one standard way of running their 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 selection of the operating system for their application didn’t get to see the pain of their decision through.
Sponsor Note
CircleCI is the leading continuous integration and delivery platform for software innovation at scale. With intelligent automation and delivery tools, CircleCI is used by the world’s best engineering teams to radically reduce the time from idea to execution.
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 give up some things, 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.
#cloud native #devops #contributed #sponsored
