Satir Change Model

The Family Therapist Who Explained Your Sprint

I was facilitating a retro about three years ago when a developer - mid-vent about a process change nobody had asked for - said something that stuck with me: “I was fine. Everything was fine. And then someone decided to fix it.”

That’s the Satir Change Model in one sentence. Not the academic version. The version people actually live.

Virginia Satir was a family therapist. Not a management consultant, not an organizational psychologist, not an agile thought leader. She spent decades working with families in crisis - watching how real humans respond when something disrupts the patterns they depend on. And what she discovered applies to software teams with an accuracy that is, frankly, a little unsettling.

Satir published her most accessible work, The New Peoplemaking, in 1988. But it was Gerald Weinberg - author of The Psychology of Computer Programming and Quality Software Management - who connected Satir’s family systems work to technology teams in the early 1990s. Weinberg had studied under Satir directly and recognized that the dynamics she described in families played out identically in development organizations. Steven M. Smith later extended this bridge, writing extensively about applying the Satir Change Model to software process improvement.

Here’s the thing about the Satir model: it doesn’t describe how change should work. It describes how change does work. And the gap between those two things is where most agile transformations go sideways.

The Five Stages of Actually Changing

The model traces a path through five stages. The path is not optional, not skippable, and not as clean as the diagram suggests. But the sequence is remarkably consistent across contexts - families, teams, organizations, individuals learning a new IDE. (Yes, I’ve seen someone go through all five stages over a keyboard shortcut change. It was both tragic and hilarious.)

Late Status Quo

Every change story starts here. The system - whether it’s a family, a team, or a department - has settled into familiar patterns. Performance is stable. Relationships are predictable. Coping mechanisms are in place.

The key word is “coping.” Status quo doesn’t mean everything is great. It means everyone has figured out how to get by. The team has workarounds for the broken build pipeline. The developer has accepted that the codebase is a mess and stopped expecting it to change.

Satir called these coping stances. People adopt predictable roles - blaming, placating, being super-reasonable, or being irrelevant - to manage the stress they’ve learned to live with. The patterns keep the system running. They also cap the system’s potential.

This is the stage most leaders misread. They look at a stable team and see a team that’s fine. But “stable” and “fine” are different things. A team in Late Status Quo might be delivering predictably while quietly accumulating technical debt and losing their best people. The numbers look okay. The humans are slowly suffocating.

The Foreign Element

This isn’t a stage so much as a catalyst - the thing that disrupts the status quo. Satir used the term “foreign element” deliberately. It’s something the system doesn’t have a pre-existing pattern for handling.

A new Scrum Master who actually expects the team to self-organize. A mandate from leadership to adopt SAFe by Q3. A pandemic that moves everyone remote overnight. A new CTO who asks “why are we doing it this way?” and actually expects an answer.

The foreign element doesn’t have to be big. Sometimes it’s a single retrospective question that nobody’s asked before. The size of the disruption matters less than its novelty - it must be something the system’s existing coping patterns can’t absorb.

Here’s the coaching insight that pays for itself: the foreign element is almost never the problem. The resistance to it is.

Resistance

When the foreign element arrives, the system’s first response is to reject it. This is not a character flaw. This is biology. Existing patterns are neurologically efficient - the brain has optimized for them. New patterns require conscious effort, tolerance for ambiguity, and a willingness to be temporarily incompetent. None of those things feel good.

Resistance shows up in predictable ways. Passive resistance looks like “sure, we’ll try it” followed by doing exactly what they did before. Active resistance looks like arguments and detailed explanations of why the new thing won’t work here. Sophisticated resistance looks like intellectual engagement - asking lots of questions, forming a committee to study the proposal - while never actually committing to trying it.

(That last one is my personal favorite. It looks like buy-in. It functions as a stall.)

In agile contexts, resistance is often misread as a people problem. “The team is resistant to change.” But Satir reframes this: the team is doing exactly what healthy systems do when confronted with something unfamiliar. They’re protecting their existing patterns because those patterns, however imperfect, are known.

The coaching mistake here is trying to overcome resistance with logic - data about why agile works, case studies, slide decks full of benchmarks. All of this assumes the resistance is rational. It’s not. It’s emotional. The team isn’t saying “your data is wrong.” They’re saying “I don’t know who I am in this new system, and that terrifies me.”

Resistance is temporary - if the foreign element is sustained. If leadership backs off every time a team pushes back, the system learns a new coping pattern: “If we resist long enough, they’ll stop trying to change us.” That lesson, once learned, is very hard to unlearn.

Chaos

Welcome to the messy middle. This is the stage that makes executives nervous, Scrum Masters question their career choices, and HR departments draft concerned emails.

In Chaos, the old patterns have broken down but new patterns haven’t formed yet. Performance drops - sometimes dramatically. People feel incompetent at things they used to do automatically. Emotions run high. Confusion is the default state. The team can’t go back to the old way (the foreign element has disrupted it) and can’t yet see the new way forward.

Satir was very clear about something that most change management frameworks gloss over: Chaos is not a failure of the change process. Chaos is the change process. It’s where the actual transformation happens. The discomfort is the mechanism, not the side effect.

Think about learning to drive a manual transmission. (If you’re under thirty, ask a Gen-Xer. We all have stories.) There’s a period where you’re simultaneously too much clutch, too little gas, stalling at green lights, rolling backward on hills, and seriously considering whether walking everywhere is a viable life strategy. That’s Chaos. And the only way to get to smooth shifting is to live through the terrible shifting first.

For teams in agile transformation, Chaos looks like sprints where nothing gets finished. Standups that feel pointless. Retros full of complaints. People saying “this is worse than before” and “can we just go back to waterfall?”

They’re not wrong that it’s worse. Temporarily, it is.

The coaching move during Chaos is not to fix it. It’s to normalize it and contain it. Tell the team: this is a known stage of change. It has a name. It is temporary. And - this is critical - you are not failing. You are learning. The discomfort is evidence that old patterns are breaking down, which is the prerequisite for new patterns forming.

You also need to provide safety. Chaos without psychological safety becomes trauma. Chaos with psychological safety becomes growth. The difference is whether people feel they can be temporarily bad at their jobs without being punished for it.

Integration

Integration is the moment when a new understanding clicks into place. Satir called this the “transforming idea” - an insight that shows the person or team how to incorporate the foreign element into a new way of operating.

The transforming idea is rarely dramatic. It’s usually quiet. A developer who’s been struggling with test-driven development suddenly writes a test that catches a bug before it ships and thinks “oh - that’s why.” A Scrum Master who’s been fighting the urge to assign tasks watches the team self-organize around a problem and realizes the team is smarter than any assignment she could have made.

Integration doesn’t happen all at once. It’s more like a series of small clicks, each one building confidence that the new way can work. Performance starts climbing. People begin to see how the new patterns serve them better than the old ones. The emotional tone shifts from anxiety to curiosity.

This is where coaches often make a second mistake - they celebrate too early. The team has a good sprint and everyone declares the transformation complete. But Integration is fragile. A setback, a leadership change, or even a particularly bad sprint can push the team back into Chaos or Resistance. The new patterns haven’t been practiced enough to be durable.

Hold your applause until the patterns are habitual, not just visible. One good retro is encouraging. Ten good retros in a row is integration.

New Status Quo

The new patterns have stabilized. Performance has returned to the previous level - and in successful transformations, exceeded it. The practices that felt foreign three months ago now feel natural. The team has developed new coping mechanisms that are more functional than the old ones.

New Status Quo is not identical to the old one with a new process bolted on. It’s a genuinely different system. The team’s relationships have changed. Their capacity for handling the next change has grown because they’ve survived this one.

And here’s the part that keeps coaches employed: eventually, the new status quo becomes the late status quo. New foreign elements arrive. The cycle begins again. Change is not an event with a start and end date. It’s a recurring pattern. Teams that understand this are fundamentally more resilient than teams that treat every disruption as a crisis.

What This Changes About Your Coaching

Naming the Stage Changes Everything

The single most powerful move you can make with the Satir model is to name the stage the team is in. Out loud. In the room.

“What you’re experiencing right now is Chaos. It’s a known stage of change. It’s temporary. And the fact that you’re in it means the old patterns have broken down, which is the prerequisite for better ones forming.”

I’ve watched that single statement change the energy in a room. People who were panicking start breathing. People who were angry start getting curious. The model gives teams a way to understand their own experience without pathologizing it.

This is different from telling people to be patient. “Be patient” is advice that dismisses the discomfort. “You’re in Chaos, and here’s what that means” is information that dignifies it.

Separating the Foreign Element from the Resistance

New coaches often spend enormous energy defending the foreign element. They argue for Scrum. They make the case for continuous integration. They present data about pair programming.

The Satir model suggests a different approach: stop defending the change and start addressing the resistance. The resistance isn’t about the merits of the new practice. It’s about the loss of the old identity. The senior developer who objects to mob programming isn’t saying “mob programming is bad.” They’re saying “my value on this team has always been my individual expertise, and I don’t know what my value is in a world where everyone works together.”

Hear that. Name that. Address that. The technical arguments will resolve themselves once the identity threat is addressed.

Protecting the Chaos

This is the hardest sell in coaching, and the most important one.

When a team enters Chaos, every instinct in the organization screams “fix it.” Leadership wants to intervene. The PMO wants to adjust the plan. Well-meaning managers want to pull people off the team or bring in reinforcements. The team itself wants someone to make the discomfort stop.

Your job as a coach is to protect the Chaos. Not to prolong it - nobody wants that. But to ensure the team has the space to work through it without being rescued from it. A team that’s rescued from Chaos doesn’t learn to navigate change. They learn to wait for rescue.

This means having difficult conversations with leadership. “The team’s velocity has dropped, and that’s expected. Here’s why. Here’s how long it typically lasts. Here’s what I need from you: patience and air cover.”

If you can’t have that conversation, the transformation will fail - not because the team can’t handle Chaos, but because the organization can’t.

Reading Satir Through Tuckman (and Vice Versa)

If you’ve already got the Tuckman model in your toolkit, here’s a useful overlay. Satir’s Resistance maps closely to Tuckman’s Storming. Satir’s Chaos extends beyond Storming into the messy territory between Storming and Norming. Satir’s Integration maps to early Norming.

But Satir adds something Tuckman doesn’t: the emotional experience of the individual within the stage. Tuckman describes team-level behavior. Satir describes what it feels like to be a person going through it. Both lenses together give you a much more complete picture - the team dynamics and the human experience inside them.

When I’m coaching, I use Tuckman to describe the team’s developmental stage and Satir to describe the individual’s emotional experience within that stage. “The team is storming, which is normal. And you personally are in Chaos, which means the old way hasn’t been replaced yet. Both of those things are temporary.”

That combination is remarkably effective.

What It Looks Like in the Room

I’d been the Scrum Master at a state Department of Motor Vehicles for about two years when this story happened. If you’ve never worked inside a government agency, let me paint the picture: badge access, fluorescent lighting, and a change approval process that made waterfall look agile. I’d come in from the private sector - I’d spent the previous few years coaching teams at a tech startup that grew from 25 to over 200 people, so I thought I understood organizational complexity. Government taught me I had no idea.

My team was six developers, a business analyst named Carmen, and a product owner who’d been a DMV branch manager for fifteen years. They’d been doing what the department called “agile.” They had standups. They had a board. They had two-week iterations. What they didn’t have was any of the underlying practices. Stories were assigned by the tech lead. Retros happened monthly and produced action items that nobody tracked. Releases shipped quarterly after a three-week manual testing phase that everyone dreaded.

Late Status Quo. The system worked in the sense that software shipped. It didn’t work in the sense that every release was a white-knuckle event and Carmen spent most of her time translating between a product owner who thought in forms and a development team that thought in APIs. People had figured out how to get by. That’s the key phrase. Not thriving - getting by.

The foreign element arrived in January: a new deputy CIO from the private sector. She’d done a listening tour her first month (which already made her unusual for that building), and then she asked me to lead three incremental changes. The team would write their own stories instead of receiving them from the tech lead. We’d implement a basic CI pipeline. And retros would happen every sprint instead of monthly.

Three things. That’s it. And the team lost its mind.

Resistance was immediate and, honestly, creative. The tech lead - a twenty-year veteran named Charles - interpreted “the team writes their own stories” as a direct challenge to his role. So he started rewriting stories after the team had written them. Technically complying, completely undermining. It was masterful in a way I almost had to respect. Carmen worried her job was being eliminated. The product owner, who had never been asked to prioritize a backlog before, just froze. (If you’ve ever watched someone stare at a Jira board like it personally insulted them, you know the look.)

Now, earlier in my career I would have made the rookie coach mistake here. I would have started defending the changes - pulling up data, citing case studies, maybe even making a slide deck. I’d taught enough Scrum classes by then to know that logical arguments don’t touch emotional resistance. So instead of arguing, I started asking questions.

I asked Charles what he was afraid of losing. Not in those exact words - you can’t lead with “what are you afraid of” to a twenty-year government tech lead without getting a door closed in your face. I bought him coffee. We talked about the system architecture. I asked him how he’d gotten to the point where he was the only person who understood the legacy modules. Forty minutes of defensive posturing later, he finally said it: “I’ve spent twenty years becoming the person who knows how this system works. If the team doesn’t need me to translate requirements, what am I?”

There it is. That’s never about the process change. It’s about identity.

But Chaos came anyway. It always does. (My MBA program did not prepare me for this part. My MFA in film probably did - every good story needs a second act that falls apart.)

The first sprint where the team wrote their own stories was, charitably, a disaster. Acceptance criteria were vague or missing entirely. Two developers wrote stories for the same feature without realizing it. The CI pipeline broke the build fourteen times in the first week because nobody had written tests for the legacy modules. Fourteen times. I was keeping a tally on a sticky note like a very sad scorekeeper.

Sprint velocity - which had been a steady, predictable, and largely fictional 42 points - dropped to 18. Charles sent an email to his manager suggesting the experiment had failed. He cc’d the deputy CIO for good measure.

I called a special retro. I drew the Satir Change Model on the whiteboard and put a big arrow pointing to the Chaos stage. I told the team: “We are here. This is a known stage of change. It has a name. It is temporary. And the drop in velocity is not evidence that we’re failing. It’s evidence that we’re no longer pretending.”

That last line landed harder than I expected. The product owner - the former branch manager who’d been the quietest person in every meeting for two years - looked up from her notebook and said: “He’s right. Our old velocity was a lie. We all knew it. At least now we’re counting real things.”

I have been in a lot of rooms. That was one of the best moments I’ve ever had in one.

Over the next three sprints, Integration happened the way it usually does - in small, quiet pieces. Charles discovered that his deep system knowledge made him the best person to review stories, not write them. His expertise was preserved. The ownership was distributed. He went from gatekeeper to mentor, and I don’t think he even noticed the shift until it was already done. Carmen started running informal “story clinic” sessions during lunch, teaching developers how to write acceptance criteria that actually meant something. The CI pipeline stabilized as the team wrote tests for the failing modules, and production bugs dropped by a third.

By sprint eight, the team had settled into a New Status Quo. Velocity had climbed to 35 - lower than the fictional 42, but every single point represented working, tested software. Charles had stopped rewriting stories and started conducting architecture reviews that the team genuinely valued. The product owner was prioritizing the backlog on her own and had started asking the kind of questions that made the developers stop and think.

At the quarterly review, the deputy CIO asked me what had made the difference. I said: “I stopped trying to make the change painless and started helping the team understand that the pain was part of the process.”

That’s the Satir model in practice. It doesn’t promise comfortable change. It promises honest change. And honest change, in my experience coaching teams across startups and government agencies and everything in between, is the only kind that actually sticks.

Go Deeper

• Satir, V. (1988). The New Peoplemaking. Science and Behavior Books. Satir’s most accessible work on family systems and personal growth. The change model is woven throughout, though not formalized into the five stages in this text. Start here for Satir’s voice and philosophy.

• Weinberg, G.M. (1997). Quality Software Management, Vol. 4: Anticipating Change. Dorset House. Weinberg explicitly applies the Satir Change Model to software organizations. This is the bridge between family therapy and technology teams. Essential reading for any coach working in software.

• Smith, S.M. (various). Steven M. Smith’s writings on the Satir Change Model and software process improvement are available at stevenmsmith.com. His essays on applying Satir to technology teams are some of the most practical translations of the model into workplace contexts.

• Satir, V., Banmen, J., Gerber, J., & Gomori, M. (1991). The Satir Model: Family Therapy and Beyond. Science and Behavior Books. The comprehensive reference for Satir’s therapeutic framework, including congruence, communication stances, and the change model.

• Weinberg, G.M. (1971/1998). The Psychology of Computer Programming. Dorset House. Predates the formal Satir application, but Weinberg’s foundational work on human factors in software laid the groundwork for everything that followed.