Virginia Satir was a family therapist in the 1960s who studied how families cope with disruption — divorce, illness, a new member joining. She noticed a consistent pattern: things always got worse before they got better, and the shape of that journey was predictable. Decades later, software practitioners discovered her model maps almost perfectly onto how engineering teams respond to technical change.
The 5 Stages
1. Late Status Quo
Everything is familiar. Performance is stable. The team is comfortable — even if the underlying technology is objectively bad. A team running a 10-year-old monolith on bare metal servers is in Late Status Quo. They know every quirk. They have workarounds for every bug. Productivity is predictable.
2. The Foreign Element
A change is introduced from outside the team's current reality. This could be an announcement ("We are migrating to Kubernetes"), a new constraint ("AWS is ending support for this instance type"), or a new hire who challenges existing assumptions. The Foreign Element disrupts the equilibrium.
3. Chaos
This is the most critical and most misunderstood stage. Performance drops. People are confused, afraid, and sometimes angry. Things actually get measurably worse than they were before the change was introduced. Engineers who were productive are now slow. Deployments that used to take 10 minutes now take an hour because the new pipeline is unfamiliar.
The most common and most damaging mistake a leader can make is to panic here and revert the change because "it's hurting productivity." This is exactly the wrong response. The Chaos stage is not a sign that the change was wrong — it is a sign that real change is happening. Reverting at this point teaches the organization that resistance works, making every future change harder.
4. Practice and Integration
The team starts to figure it out. They find the right documentation. They pair with someone who knows the new tool. They make mistakes and learn from them. Performance slowly climbs as new skills are built. The new way starts to feel less foreign.
5. New Status Quo
The change is normalized. The new approach is "just how we do things." Performance is higher than it was at the start — not just because the new tool is better, but because the team went through the learning process together and built new shared knowledge.
Why This Model Matters in Practice
The Satir model gives you two concrete tools. First, it lets you predict the dip so you can warn stakeholders in advance: "Expect deployment frequency to drop for the first three sprints. That is normal and expected." Second, it lets you measure where you are. If you are in Chaos, you know you need to focus on support, training, and patience — not acceleration.
A common interview question for Staff+ roles is: "Tell me about a time a technical initiative you led failed or struggled." The Satir model gives you a precise vocabulary to answer this. You can say: "We underestimated the Chaos stage. We introduced the Foreign Element — the new CI system — without enough support structures, and when productivity dropped, leadership interpreted it as the wrong decision rather than a normal transition phase. I learned to set explicit expectations about the dip before starting any migration." This demonstrates systems thinking, not just technical skill.
Key Point: The emotional dip is not a sign of failure — it is a sign that real change is happening. Your job as a leader is to shorten the Chaos stage and deepen the New Status Quo, not to eliminate the dip entirely.