EMC ruled the world of data storage for decades, but when cloud computing emerged, it couldn’t keep up.
In 2012, EMC became the top provider of external disk storage systems for the 15th year in a row; in 2015, Dell acquired EMC for $67 billion – the largest pure tech deal in history – and Dell took on close to $50 billion in debt to do so while EMC sold off its most successful parts, including VMware and Pivotal Labs.
It’s a pattern we’ve seen many times, but the persistence of the pattern points to an upstream problem. Recognizing the need to change is hard, but actually driving engineering excellence is even harder. EMC acquired VMware all the way back in 2004, for example – they knew the future wasn’t all about on-prem, hard disk storage.
Why, even with good intent informed by industry headwinds, do so many engineering leaders fail to transform their organizations?
The path to engineering excellence is ultimately much more complex than people think it is, and change at scale is frequently waylaid by narratives and frameworks that make it appear straightforward.
Here are the three we see most at Uplevel:
1. Measurement leads to engineering excellence on its own
Many leaders believe deeply in the raw talent of their teams – often rightly so. But that confidence can lead them to accept a common myth: that measurement alone creates change. Once you accept that, it’s easy to think that if change hasn’t happened, you just need to introduce metrics people can measure and progress toward.
Think about developer productivity. It’s a contentious topic, especially among developers, but it doesn’t always come from a punitive place. Often, leaders have goals that overlap with developers, such as increasing focus time and decreasing useless meetings.
Take developer surveys, for example. At first glance, developer surveys are a good compromise because leaders can measure some metrics over time, and developers don’t have to worry about anyone counting how many lines of code they wrote in a given week. 
Developer surveys are prone to bias, however, including hindsight bias, recency bias, and confirmation bias. An honest, well-intentioned developer could remember the month being full of meetings when only the last week was, for example, or they overemphasize distracting Slack messages when there are bigger distractions they’re unaware of.
As a result, leaders could deploy surveys, developers could take them, and the results could lead only toward a faux-visibility. Worse, a seeming consensus across anonymous survey results does not necessarily become an agreement for change. Everyone could agree meetings should be reduced, for example, but no one might agree on which meetings.
Measurement is ultimately necessary but not sufficient for transformation. You will likely need metrics to track organizational change, but metrics alone cannot initiate change, sustain consensus around change, or hand you a strategy that shows you which changes to make.
2. Culture change can be prescribed
When we think of leaders encouraging and heading large-scale change, we tend to think of legendary leaders in the industry, such as Steve Jobs, Jensen Huang, and Jeff Bezos. We might even think of a particular concept, like Bezos’s two-pizza teams theory, and imagine him announcing the change and reshaping each team by hand.
But the stories here, when only understood from a high level, support a myth – the idea that truly great leaders can just prescribe engineering excellence and expect the organization to follow. Change can start to feel like the result of top-down edicts, big speeches, and grand visions.
When leaders assume a grand vision and a big announcement is all they need, the underlying assumption is that organizational problems are essentially incentive problems. “If only people knew what the issues were and what the shared direction is,” the thinking goes, “then the whole organization would realign with the change overnight.”
As Will Larson, CTO at Carta, writes, however, many leaders’ “Strategy for changing culture is to announce a new culture. Unfortunately, they soon recognize that announcing culture doesn’t work. You have to change the culture first, then you can further cement that change with an announcement.”
Larson illustrates this through a hypothetical company trying to move with more urgency. In this case, the founder reviews all external-facing work – just like they did when the company was tiny. “This works extremely well at a small scale but becomes a bottleneck as they grow,” Larson explains. This could be obvious to new employees but invisible to the founder. “Employees lose a sense of urgency because they know they’ll, regardless of how quickly they do the work, get stuck in the approval process,” Larson writes.
Eventually, the founder could end up frustrated that the edict they prescribed – Move with urgency! Be high agency! Move fast and break things! – is ignored. But their employees didn’t ignore the vision; they tried, hit a bottleneck, and the nature of an inefficient process drained employees of the motivation to remain urgent.
It’s not always the founder’s fault, of course. Everyone involved in following through on a change could be unaware of the accumulated inefficiencies that come from red tape or the tradeoffs that might be working against them.
For example, Jason Cohen, founder of WP Engine, had over 100,000 customers when the company wanted to build out support for the then-new nonprofit LetsEncrypt. “We knew nearly all of our customers would want it,” Cohen writes, but “it had to be scalable before we released it.” It took months of preparation.
In this case, Cohen couldn’t have just prescribed organizational and culture change to make developments like these move faster. If organizations want to make significant process changes, they need to take account of their limitations and work from the knowledge that simply wanting, announcing, and prescribing change isn’t enough.
And for large organizations, that mentality is a competitive disadvantage. Where startups have the privilege of not yet having scale and not yet having to balance innovation against stability, enterprises need to be proactive and iterative in their approach to transformation simply because it will take time and effort.
“A startup can launch something in a few weeks and iterate,” Cohen writes. “We had to be heads-down for most of a year. And so another startup opportunity emerges.”
3. People change is someone else’s problem
In many cases, leaders know change is necessary but disagree on how to enact it. For engineering leaders, in particular, there’s a tendency to assume that people change is someone else’s problem.
Engineering leaders often reach leadership positions because of their ability to solve technical problems, manage small teams, and direct projects and processes. Once they reach a leadership role, however, the nature of the problems they face shifts.
Engineering leaders who do realize people change is within their remit, however, can shift from one myth to another if they assume organizational change is essentially the same as technical change.
In programming, identifying and articulating the problem is often the hardest part (think of the Charles Kettering quote, “A problem well-stated is half-solved”; writing out the code can often be the easiest part). With organizational change, however, high-level changes can often be relatively easy to identify – fewer bugs, faster feature development, more stability, etc. It's the implementation that's hard.
Part of engineering leadership means embracing becoming political – even if it means facing down the term’s worst associations like being scheming or manipulative.
As an example, Gergely Orosz, former engineering manager at Uber, writes about a hypothetical company choosing between a monolithic approach vs. a microservices approach. The reasons behind each side might be technical, but building consensus is political, and carrying the change through is sociotechnical.
Orosz concludes, “Politics in some form is unavoidable and happens wherever there are groups of people and decisions which need to be made.” As a leader, your primary role is making and leading the decision-making process, which makes politics a necessary part of your work.
This often requires dealing with consternation. Engineering leaders often want to treat political problems as technical ones because technically correct solutions can’t be disagreed with (in theory). But often, as in the example above, developers disagree about the technical merits, too.
Engineering leaders often have to account for a pervasively unsettled feeling among developers and triangulate among many different complaints. Even the most well-informed changes might be decried as “business theater.” And yet, the need to be political remains.
An engineering leader who says “I just want to solve technical problems” is abdicating their biggest responsibility.
Mythbusting before problem-solving
The image of the foolish, headstrong leader who ignores the tides of change is a comforting one because it allows other leaders to think, “Well, I wouldn't do that.”
In reality, most leaders are not so blinkered – even the ones helming companies or teams that failed. Many recognized the need to change even though they failed to follow through, and many likely put a lot of effort into achieving engineering excellence despite the eventual failure.
The myths that make organizational change seem simple to accomplish only make it harder. Working from the wrong framework can result in spinning your wheels without ever leaving the starting line. Busting these myths is your step zero; only after can you start progressing toward true transformation.
Engineering transformation starts with the Uplevel Method.
Learn how Uplevel turns engineering metrics into meaningful change with our proven methodology.
