The Myth of the Quick Fix: Why Real Change in Engineering Takes Time ⏳

I've found transformation and change to be hard; here are some of the challenges I've encountered and the insights I've gained.

The Myth of the Quick Fix: Why Real Change in Engineering Takes Time ⏳

Issue No. 27

📰
This is a project by Jeremy Brown. I'm a journeyman sharing insights on leading product & engineering teams, building products, and exploring technology.
I will also share occasional updates on my overall project as I build this newsletter and "The Retrospective" (a live show and podcast) in the open.

I've made a slight change to the format of this newsletter. I moved personal updates and other preambles to the start of the email that subscribers get.

This means that the web version of this essay is just the essay, and you need to be a subscriber to get more personal updates.

💬 In this issue, I cover:

  • The Myth of the Quick Fix: Why Real Change in Engineering Takes Time ⏳
    • 🔄 My Obsession With Change
    • 🔍 I've Not Found a Quick Fix Yet, But I Think There Are Some Promising Approaches
    • ❓ Change What?
    • 🧩 What Is Culture?
    • 🍽️ Culture Eats Strategy for Breakfast
    • 🐢 So why does it take so long to change how we execute?
    • 💡 So what does work?
  • 🔦 Highlight of the Week - Measure Cycle Time, Not Velocity

The Myth of the Quick Fix: Why Real Change in Engineering Takes Time ⏳

🔄 My Obsession With Change

Over the years, one of the biggest categories of articles and quotes I've collected in my Readwise account is "Change", a term I prefer over the more commonly used term "transformation".

It's a subject that has fascinated me ever since I worked at several software vendors that were helping large organisations (enterprises) change and go through a "Digital Transformation" - first by assisting them to choose our software to be part of their new stack, whether it was Java Middleware, the early versions of PaaS or API management.

Then I worked with a whole crew of folks who were obsessed with change when I helped build and launch Red Hat's Open Innovation Labs, a consulting service built to spark and accelerate change for people and processes on top of Red Hat's technology (their Kubernetes distro/platform OpenShift).

Since then, I've been in tech leadership positions where I was hired to bring change, whether that was to try to save and transform an organisation, get it out of its early messy phase, stabilise and prepare it for scale or help a much larger team move out of a disjoined mess and organise for the fast flow of outcomes.

🔍 I've Not Found a Quick Fix Yet, But I Think There Are Some Promising Approaches

In all this, I've not found a quick fix, a ninja move that allows you to turn things around overnight. I've been following some folks who claim it is possible - notably Niels Pflaeging and Open Space Beta, derived from Open Space Agility. Both of these are based on Open Space Technology, which I've written about using in the past, "Open Space Technology: A Change Mechanism for Teams of All Sizes".

While I certainly believe in the power of Open Space Technology to accelerate change, I don't think it is as straightforward or as fast as Open Space Beta claims: "In OpenSpace Beta, that takes 90 days. And then it's done.".

That said, Niels is not proposing snake oil; if an organisation embraces learning, a cell-based structure, relative targets and uses an Open Space every 90 days, it will be a radically different organisation. I'm a big fan of Niels and his work, and I wish every organisation fully embraced the ideas he espouses.

❓ Change What?

Exactly, good question! What are we trying to change?

Whether we are preparing to scale or striving to enhance efficiency, at the root of it lies a need to change the organisation's organisation's culture.

What does it mean if we are trying to change the culture? What is culture anyway?

🧩 What Is Culture?

At its simplest, culture is people's actions; it is 'the way we do things around here'.

Culture is like a shadow. It simply reflects how a group works together.

Culture is like a shadow, from one of my old Red Hat Open Innovation Labs presentations.

I've mentioned Westrum's organisational typologies before. It's a way to categorise different types of behaviour or culture.

A slide I've been using on Westrum's Organisational Typologies for quite a few years

These two quotes have resonated with me since we started using them in presentations for Red Hat's Open Innovation Labs.

'The way to change culture is not to first change how people think, but instead start by changing how people behave what they do.'

- John Shook, Lean Enterprise Institute
At the end of the day, when we talk about technology change — whether it's the Internet of Everything, big data, or machine learning - it's really about people and organisational cultures, first and foremost.

Then it's about how those people get stuff done together...

- Dr. David Bray, Exec Director, People-Centered Internet

🍽️ Culture Eats Strategy for Breakfast

Peter Drucker, often called the "father of modern management," emphasised the importance of management practices that respect and motivate employees. One of his most famous concepts is that "culture eats strategy for breakfast," suggesting that organisational culture is a more powerful influence on success than strategic planning.

I favour the phrase "culture eats strategy for breakfast" because it supports the Theory Y view that organisational culture is crucial for enabling employees to perform at their best.

Execution and culture, to me, are synonymous. When we look to implement changes within an organisation, it often concerns how we execute.

High-performing teams are the product of the context in which they operate. This context is shaped by the organisation's culture, which influences how teams collaborate, communicate, and make decisions. A culture that values and supports high performance can foster the conditions for teams to excel, contributing to the organisation's overall success.

I remain dedicated to creating the context for high performance, particularly because, as a leader, I believe that leadership establishes the context. Leadership plays a crucial role in setting the tone, values, and expectations that shape an organisation's culture, making it a key driver of change.

Management's role is to create conditions that align the employees' aspirations to achieve their best and the organisation's objectives.

🐢 So Why Does It Take So Long to Change How We Execute?

Here are some factors I've observed that hinder change efforts. Recognising and addressing these factors can help overcome these obstacles and drive effective change. If you are hyper-aware of these, you can smoothen and speed up change, but it will be slower than most stakeholders want.

People need to understand why we need to change. John Kotter, a professor at Harvard Business School and a leading thinker in change management, identified the need to create a sense of urgency as the first step in his 8-step process for leading change. For change to happen, it helps if the whole company wants it. Develop a sense of urgency around the need for change. A sense of urgency may help you spark the initial motivation to get things moving.

⚠️
I have learnt from situations where this has gone wrong by observing new leaders above me who have tried to follow Kotter's playbook but have yet to create a real sense of urgency. Often, they manufacture what feels like a fake crisis. It's hard to follow a change based on a fake crisis.

For example, I just read that Google folks struggle to understand the constant layoffs when the company is having outstanding results. The way the media paints things, the staff at Google don't seem to be on board with the changes the leadership is trying to drive.

Inadequate leadership commitment can manifest in various ways, such as not having a senior enough leader behind the overall change effort, not fully understanding or supporting the change (they don't go "all in" and instead "hedge their bets"), or not allocating sufficient resources or time to the change effort. Without strong and consistent leadership to drive the change, efforts can dissipate over time, leading to a prolonged change process.

If you manage a team or a small group of teams and the rest of the organisation isn't on board, you may find yourself in a challenging position. In this scenario, the best you can hope for is to create a small bubble of change and constantly have to manage the interactions of your bubble with the rest of the organisation. This can be a delicate balancing act, requiring you to navigate differing perspectives, priorities, and ways of working.

⚠️
The role of a leader is not just to drive change but to create an environment of trust, psychological safety and empowerment of people above all else. I have written more about this and the other principles needed before you do anything else in my article about the baseline principles needed in teams.

Further, the initiative can stall if a leader driving the change leaves or changes their role.

People resist change when it represents a loss of power for them. Loss of power could be as simple as not feeling like they have the skills for what is expected of them, or the changes threaten their comfort zones, power structures, or job security, leading to a slower implementation of new cultural norms.

Understanding people's intrinsic motivations and integrating them into the narrative for the change can reduce resistance and enhance buy-in.

One of the best ways to integrate people into the process is by using the Ikea Effect in your favour by involving people in the solution (ideally in defining the problem and the why together).

Related to this, if the new culture is not aligned with the personal values and goals of the employees, it will be difficult to achieve widespread acceptance and implementation because of a misalignment of goals and values.

I've also encountered deep-rooted habits and norms often signalled through the organisation'sorganisation's language. Changing the ingrained behaviours and norms that define an organisation's culture can be slow because they are usually deeply embedded within the company's history and daily practices.

Ineffective communication about the reasons for change and the benefits it will bring can hinder buy-in from team members at all levels as well as stakeholders.

Communication is one of the most important things you can do during change. It needs to be transparent and clear; everyone needs to understand and be on board with the reasons why (see the first point).

Communication should be frequent and transparent, focusing on the long-term vision, repeating why we are making changes, and celebrating small wins. Focusing only on short-term wins that "look good" but may not have a lasting impact often results in the scorched earth tactics I've seen the worst leaders use.

Finally, a lack of immediate results can lead to scepticism and waning interest or support for the change initiatives. The truth is that cultural shifts do not yield immediate visible results; there are often loads of positive changes before end users start to experience a difference in the product or service. For example, I worked with my team to align folks better through a reorganisation using the ideas from Team Topologies, quadrupled the flow of work through the organisation while reducing work in progress, and the product team did a great job of prioritising the highest impact items for users. However, the effect was still felt by our users only five to six months later, sadly too late for the organisation, which led to some scorched earth tactics by the CEO with disappointing results.

It can be challenging in a high-pressure environment, but setting realistic expectations, explaining how the changes that are being made connect to long-term success and celebrating small wins often along the way can help.

💡 So What Does Work?

This article has expanded significantly beyond the timebox I try to set myself, so I'll write more about going about change from my perspective in a future issue.

I don't want to leave you hanging, so here are a few things you could work on:

Establish the baseline principles needed for any change:

  • Psychological Safety & Trust - A physiologically safe environment where team members can be vulnerable without fear of repercussions.
  • Healthy Conflict - The best decisions are made when team members can openly air their opinions. The team can engage in unfiltered, passionate debate about key issues rather than veiled discussions and back-channel comments.
  • Commitment - Clarity and buy-in. We have a clear direction, and team members commit to decisions.
  • Accountability - Help people get back on track when they've made their commitments. We commit to a clear plan of action and call our peers on actions and behaviours that may seem counterproductive to the team's overall good.
  • Outcomes - Focus on collective outcomes. We focus on creating results and putting the team's needs ahead of our own (ego, career development, recognition, etc.)

Put in place a change mechanism for your team or organisation - in Agile, we call this a retrospective, and there are different formats. I'm a massive fan of a quarterly Open Space meeting (and a facilitated retrospective on the first day).

Remember to use the Ikea Effect as you go about your changes.

💬 If you had some thoughts while reading this, I would love to hear them in the comments.

🔦 Highlight of the Week

This week, I'm sharing several quotes from the same article by Johanna Rothman - "Measure Cycle Time, Not Velocity" (my version with more highlights)

This article is pure gold, and it wasn't possible for me to share a single quote.

The advice in here is super actionable for any engineering leader and something I've been trying to do for some time - those of you who have worked with me might have done a Metrics Based Process Mapping exercise (which is similar to what she proposes) or been victim to my insistence that work tickets/issues/stories are super small (ideally one day) and that I hate story points and estimation but that we should instead count the tickets/issues/stories. People like Johanna often better articulate my obsession with implementing these ideas.

Johanna is an Agile and Lean expert, speaker and author, definitely someone you should follow and check out.