Refactor Management - Return to homepage

Move Fast and (Don't) Break People - Part 1

• By Peat Bakke • 9 min read

This is the first of a two part series about the human factors behind change management. In this post we’ll deconstruct what change is, how people navigate change, and what our levers are for improving outcomes. Next week we’ll get into strategies for applying our tools and understanding — join the mailing list or follow on LinkedIn so you don’t miss out!

“Everything, everywhere, all at once” is a terrible approach to management, and a surefire way to create the Everything Bagel of nihilism and despair that wreaks havoc on your productivity and culture. When it comes to organizational change, this approach is a recipe for disaster.

Massive change is a strong, intuitive reflex for people who are sick of dealing with the same problems over and over — I mean, how many times have you thought about rewriting that legacy service that infuriates everyone who tries to work on it?

That “this is really frustrating, we need to change this NOW” thought pattern doesn’t just occur with engineers working in legacy code. It happens to everyone: product managers, middle managers, executives, board members, investors. Everyone and everywhere.

The symptoms are obvious.

  • Team reshuffling every six months.
  • Roadmap and prioritization thrashing.
  • Half implemented “critical” initiatives.
  • A pervasive feeling of dread about an uncertain future.
  • Spicy back channel conversations about the latest and greatest all-hands announcements.

You get it. These are all the results of bad change management: it’s corrosive to productivity, morale, and especially retention of your top performers.

If you’ve experienced enough bad change management, you’ve probably developed a deep rooted cynicism about change, an expectation of failure, and a begrudging acceptance for the status quo.

When change management fails, everything falls apart.

Deconstructing Change

To understand why something fails, you have to understand how it works.

If you’re debugging an unreliable service, you have to have a reasonable understanding of how it was built and the environment it exists in, right? Otherwise, you’re just playing whack-a-mole and hoping something works — and likely introducing new bugs, unnecessary overhead, and complications for your colleagues.

The same principle holds true for human behavior.

Change management is fundamentally about how we work together as humans, and the biggest failures are the result of ignoring human factors.

To fix broken change management, we need to understand the psychology behind how people work together. Several fields contribute to this understanding — organizational development, social psychology, and industrial-organizational psychology among them.

What I love about these research-based approaches is that they’re literally the opposite of hot takes on LinkedIn and celebrity management anecdotes. They have to withstand academic rigor, and they’re a goldmine for understanding why change fails.

A Simple Example

Let me illustrate with something trivial: You stop at a coffee shop every day on your way to work, and one morning you discover the shop has gone out of business. So, you find a different coffee shop a couple of blocks away, and change your morning routine to go there instead.

Even this simple change follows a predictable pattern:

  • You’re disappointed and have to let go of your familiar routine
  • You commit to finding a new coffee source
  • You try different options and figure out what works
  • You settle into a new routine
  • Eventually, it becomes automatic

This pattern — from disruption through adaptation to new normal — happens with every change, whether it’s switching coffee shops or restructuring an entire engineering organization. The difference is scale and complexity.

Forming, Storming, Norming, and Performing

One particularly useful framework for understanding this pattern comes from Bruce Tuckman’s research on small team development. While his model specifically describes how teams mature, I’ve found it offers valuable insights for understanding how people navigate change more broadly — team changes are a crucible of shifting relationships, goals, responsibilities, and practices.

Of all the frameworks I’ve encountered, this one stands out for its practical application to change management. The Tuckman Model has been battle-tested by psychologists for sixty years, yet the number of new engineering team leads and managers I’ve encountered who are familiar with it is exactly zero. I don’t think it’s a stretch to assert that leadership struggles often stem from ignorance of basic psychology.

The Tuckman model asserts that teams go through several different behavioral stages during their development. It’s not always linear, and not every stage is always hit — but generally speaking the model offers a solid mental framework for understanding how groups process change.

Forming is when people recognize a change and commit to adjusting their relationships, priorities, behaviors, and responsibilities to adapt to a new way of doing things.

Storming is when people are engaged with learning and adapting to the change, which often requires negotiating conflicts, reconciling missing information, and correcting mismatched expectations about how things work.

Norming is when the change becomes the new normal, and the work becomes practice.

Performing is when people have fully adapted. Trust, cohesion, and confidence kick in: the new way of doing things is working.

Looking back at our coffee shop example:

  • You commit to changing; after all, you need a new source of coffee (forming)
  • You try a couple of coffee shops and consider making your own at home (storming)
  • You start going to the new coffee shop each morning (norming)
  • You stop thinking about the change as it becomes routine (performing)

It’s worth noting that even a trivial example can take days. My heuristic for the shortest timespan for change is one week. Remember: it’s not just the decision about the new coffee shop, or just the research into your options, or just becoming accustomed to a new route to work.

Accounting for change is a complex process, just like software development. The skepticism and analytical reflex that kicks in when a non-technical colleague asserts “it’s just a simple feature” will serve you well when someone says “it’s just a simple change.”

(“just” and “simple” are my favorite red flag words)

All of these stages require time, emotional energy, and learning — and in my experience, the time it takes to get from forming to performing depends heavily on two factors: the scale of the change, and the desire for the change.

How Scale and Desire Affect Change

Research on change readiness demonstrates that the size of the change and people’s psychological readiness significantly impact the quality and timeline for the change.

Think of it this way:

  • Small changes nobody wants? They’ll drag on forever (if they happen at all).
  • Big changes everyone’s excited about? They can happen surprisingly fast.
  • Big changes nobody wants? Expect a long, painful slog.
  • Small changes people want? Quick wins.

So, how do we measure scale? I look at the number of people involved (starting from one — there’s always at least one person dealing with any change), and how much of their daily work needs to be changed. Is the impact one person changing a five-minute task, or an entire engineering organization adapting to a new transformative technology?

Our coffee shop example represents the smallest scale: one person changing a small part of their day. The scale is minimal and the motivation is high (you need that coffee), so the time to move through the stages is short.

Here’s the most important thing to understand about the relationship between scale and desire: without desire it is very hard to effectively implement any change, regardless of scale — and with desire, accomplishing changes of any scale builds morale, confidence, and ambition.

The prophetic phrase “culture eats strategy for breakfast” reflects this truth. You’re setting yourself up for a painful, prolonged process if the desires and needs of the people in your organization aren’t aligned with the changes you’re trying to implement.

Change takes time, even if it’s trivial — and a lot more time if the people involved aren’t motivated to do the work.

Work (Change) in Progress

Which brings us to an important point: change is work. It takes time and attention! And just like with software development, trying to do too much at once slows everything down.

The principle of minimizing work in progress holds for change management as well: to realize the most value from changes over time, the work should be done serially, not in parallel.

(Haven’t read Do Less to Do More? Go do that.)

This aligns with research on change overload and the limits of organizational attention. When we try to process too many changes simultaneously, we exceed our cognitive capacity — focusing on one thing at a time and delivering in serial is faster and has the added benefit of accruing more value over time.

This is why significant change is typically accompanied by a temporary loss of productivity: time is shifted away from productive work and toward adapting to change.

Change, like any other form of work, must be effectively broken down, prioritized, sequenced, and supported to be effective — and if you want to minimize (or altogether eliminate) the impact to your functional work, the change must have the outcome of accelerating that work.

This is the magic of effective change management, and one of the reasons I’ve been able to manage some ridiculous organizational transformations while simultaneously increasing functional productivity. Finding alignment between the work you need to deliver and the changes your team wants to implement is straight up rocket fuel.

Your job as a leader — regardless of title — is to jump on those opportunities without burning your team out.

(How? We’ll get into that in the next post.)

Checkpoint

Alright, so where do we stand? We’ve covered a lot of ground. What’s the story here?

  • We have a framework for how humans deal with change.
  • We’ve explored how scale and desire interact to affect change velocity.
  • We’ve established that change is work, and like all work, it benefits from limiting work in progress.

We started this journey with an intuitive understanding that trying to do everything, everywhere, all at once will inevitably result in the everything bagel of collapsing morale and apathy — and now we have a handful of models for how change works, what our constraints are, and what levers we can pull.

How do we fit it all together and put it into action?

We’ll get to that in Part 2.

In the meantime, I am very curious to hear your thoughts on where we’re at so far. What hits? What misses? Where do you think this is going?