Pull-Based Change Management: Invite, Don't Push

Most change programs fail in a familiar way. A pilot works, leaders get excited, and the next question is “how long until everyone does this?” That is exactly where many agile transformations stop being agile. The organization uses waterfall logic to roll out agile, and then wonders why the result feels like compliance rather than ownership.

My answer has been pull-based change: mandate the direction when leadership needs to be clear, but invite the timing, participation, and detailed practices as much as possible. Treat the organization as a market for change. Package the change like a product. Find the people with real pain and a reason to try, help them create evidence, then let that evidence pull in the next group.

In my Lean Kanban UK 2013 talk, I described a pattern I had already seen too many times. A team or a product group tries Scrum, Kanban, or some other agile approach. It helps. People like it. Then the enterprise gets interested, and the response is to take the thing that worked locally and roll it out everywhere at once.

That is the trap. You start with a change that depends on ownership, learning, and context. Then you scale it with a plan that removes ownership, compresses learning, and ignores context. Every group gets told to start at the same time. Change agents do not have enough capacity to help properly, so the guidance becomes more prescriptive. People who were not part of the original pull now experience the change as something being done to them.

The predictable reactions show up quickly. Some groups say, “we’re different.” Some go through the motions. Some hide under the radar. Some discover that because the change was created by someone else, any implementation problem can be handed back to the change team. That is one of the reasons I dislike mandate-first rollout. It does not only create resistance. It also creates the wrong ownership model for the problems that inevitably appear. There is a better way, but it requires a different stance from leaders and change agents: stop asking “how do we get everyone onto the new process by Q3?” and start asking “where is there enough real pain, leadership energy, and local appetite to make the next change useful?”

One of the core ideas in my pull-based change work is simple: your organization is a market for the change. The groups inside it are not anonymous recipients of a rollout. They are internal customers and users. Some are innovators. Some are early adopters. Some are pragmatists who need social proof. Some will not move until the new way of working feels normal enough to be safe. That is why I connected enterprise change to Geoffrey Moore’s Crossing the Chasm in the LKUK13 talk and the related Prezi on Kanban as a sane way towards enterprise agility. The adoption curve exists inside the company too. Innovators may try a new way because it is interesting. Early adopters need a business case and enough room to experiment. Pragmatists need examples that look like their own world, clearer guidance, and a stronger reason to believe the risk is worth it.

So the work of the change team becomes closer to product, marketing, enablement, and customer success than to rollout control. You make the problem visible. You explain the value proposition in language the internal customer recognizes. You create case studies from early adopters. You show what is in it for the next group. You make it easy to start. Then you listen carefully to where the product is not good enough yet.

This is also where Kanban thinking helps. The change initiative itself has flow. It has demand. It has capacity. If the internal market starts pulling faster than the change team can help, you need to manage that work in process too. Otherwise you spread the coaching energy thin, damage the early adopters, and turn a promising change into another overloaded program.

The more I work with leaders on change, the more useful the “change as a product” lens becomes. A product has customers, adoption paths, positioning, options, feedback loops, usage signals, support needs, and a roadmap. A serious organizational change has all of those too, even if we rarely talk about it that way.

When you treat change as a product, you stop assuming that being right is enough. You ask who the change is for first, what painful job it helps them do, what risk they are taking by trying it, and what proof they need before they will recommend it to someone else. You also ask what version of the change is appropriate for their context. Sometimes the right offer is revolutionary. Sometimes it is evolutionary. Sometimes it is a full-service implementation. Sometimes it is a do-it-with-you path, or a small experiment, or a menu of practices with a few non-negotiable guardrails.

That is the point behind The Pricing Page for Your Change Product. Options create choice. Choice gives people back some control. And control lowers resistance. This does not mean “anything goes.” It means you design the change so people can make meaningful choices inside a clear strategic direction. The product lens also connects to my older Lean Startup for Change thinking. If the change has uncertainty, do not pretend you can solve it with a big plan. Name the risky assumptions. Test the smallest useful version of the change. Watch behavior, not just sentiment. Tune the growth engine before scaling. In earlier language I called this the Minimum Viable Change. Today I would still use that idea: start with the smallest change that can teach you whether the approach fits the organization.

Pull-based change is sometimes misunderstood as “let people do whatever they want.” That is not what I mean. Leadership still has a job. Sometimes leaders need to mandate the direction. They need to say, clearly, why the current system is not good enough and what outcome the organization is aiming for.

The distinction that matters is between mandating direction and mandating every practice. In SAFe Invitations - Part 1, I described this as inviting groups to pull the change rather than forcing them onto a transformation train at a centrally planned time. In Part 2, I went deeper into involving leaders and participants in deciding how the change should work locally. In Part 3, I connected the idea to OpenSpace Agility.

This is why the language of invitation matters. OpenSpace Agility and the broader Invitation-Based Change community frame invitation as a way to create engagement, self-management, and respect for the people affected by the change. The OpenSpace Agility Handbook makes the same point in a very direct way: mandates reduce engagement; invitation and opt-in participation increase it.

The same pattern shows up in Sooner Safer Happier, which uses the principle “Invite over inflict.” I like that phrase because it keeps the leadership challenge honest. You still provide outcomes, purpose, values, principles, support, and guardrails. But you avoid pretending that imposing one process on a complex adaptive organization is the same as changing how people think and work.

The strongest enterprise example I keep coming back to is Amdocs, where Keren Yahalom, Yaki Koren, and the internal change leaders used Kanban to improve delivery in a large service business group. The public LKNA14 case study described a delivery organization of about 4,000 people, serving large telecom operators, with large customer-specific programs and serious pressure around late-changing scope.

The important part is not that they chose Kanban. The important part is why and how. The organization had already lived through a major Critical Chain implementation, and leaders did not want another methodology designed in a room and pushed into projects. The first real move happened when leaders with a painful customer-scope problem pulled help. They visualized the work, broke very large change requests into smaller chunks, tested earlier, and used the board to have better conversations about flow.

After the early success, senior management naturally wanted to mandate the approach everywhere. That was the dangerous moment. The implementation team resisted because they had seen the difference between pull and push. When managers pulled the implementation, they saw challenges as their problems to solve. When the implementation was pushed, they saw problems as something the coaches should solve for them.

That distinction is the heart of pull-based change. The same board, training, or framework can either increase ownership or reduce it, depending on how it enters the system. The mechanics matter, but the ownership model matters more.

If I had to compress the whole approach into a few operating principles, I would use these:

• Mandate the strategic intent when leadership needs to be clear. Invite the path, timing, and local practice choices wherever you can.
• Start where there is real pull: a painful business constraint, a leader willing to own the risk, and a group with enough energy to try.
• Treat the organization as a market. Different adoption segments need different evidence, stories, support, and offers.
• Make the change product better. Improve the value proposition, onboarding, options, support model, and feedback loops.
• Use minimum viable changes. Test value and adoption assumptions before scaling a solution that might not fit.
• Manage the change initiative’s flow. Limit work in progress for the change team itself so early adopters get enough help.
• Use frameworks as patterns and options, not as prescriptions. The framework should serve the change, not become the change.

This is also why I do not see pull-based change as a soft alternative to serious transformation. It is often the more disciplined path. It forces you to prove value, earn adoption, and inspect what is really happening instead of reporting rollout progress as if attendance and certification were behavior change.

If you want to go deeper, I would start here:

• Kanban - a SANE way towards enterprise agility - the LKUK13 talk where I lay out the adoption-curve and internal-market argument.
• The Prezi from the LKUK13 talk - useful if you want the visual model behind the talk.
• SAFe Invitations - Part 1: Pull-based Change - how to bring invitation and pull into SAFe implementation timing.
• SAFe Invitations - Part 2: Management workshop and vote-of-confidence-driven open space - how to invite leaders and participants into practice choices.
• SAFe Invitations - Part 3: Combining Open Space Agility and SAFe - the Open Space Agility connection.
• Invitation-Based SAFe Implementation - a SAFe guidance article - the SAFe guidance article I authored and the Agility Strategy Workshop connection.
• Kanban Method - Finding the Minimally Viable Change - the minimum viable change lens.
• So what is Lean Startup for Change? - value and growth hypotheses for change programs.
• The Pricing Page for Your Change Product - how options and choice lower resistance.
• Amdocs: Moving Thousands of People to Kanban Without Another Big-Bang Change - the enterprise case study.
• How to Drive Towards Business Agility Without Falling Into Transformation Theater - a more recent conversation about business agility, strategic adaptability, and avoiding framework theater.

Relevant external resources:

• OpenSpace Agility: Invitation Based Change
• Open Leadership Network: Invitation-Based Change
• The OpenSpace Agility Handbook at Agile Alliance
• Sooner Safer Happier VOICE: invite over inflict and minimal viable guardrails

Lean Kanban UK 2013 talk

Prezi from the Lean Kanban UK 2013 talk

Interactive workshop at Lean Kanban North America 2014

Amdocs SBG case study at Lean Kanban North America 2014

If you are trying to make a serious change stick without creating another round of transformation theater, let’s talk.