Introduction & Summary

Most change efforts fail, even when experienced people are involved, and even when the environment is relatively trusting and safe. We should approach improvement like we approach product—using thoughtful experiments and disciplined, intentional learning.

Our goal: better experiments, better outcomes, and a happier (and engaged) team.

In this post I am going to explain the idea of enabling constraints, and then talk about how to put them in motion using POPCORN Flow.

I will discuss a key concept: enabling constraints. I’ll provide some examples of enabling constraints. Then we will cover the difference between a good and bad enabling constraint, and how to support enabling constraints. We’ll then consider the temporary nature of enabling constraints, and why they require scaffolding.

With these ideas in our head, we will cover POPCORN Flow, a framework for thinking about improvement experiments. Before trying POPCORN Flow, it is important to think about WHO should be involved, and how you might scale things that work.

Enjoy!

Enabling Constraints

The central idea here is the idea of enabling constraints.

Enabling constraints. “Enabling constraints are context sensitive. Enabling constraints force alignment of the agents which leads to resonance and this creates a higher order system. The higher order system provides feedback to the agents which constrains their behavior and stabilizes the higher order system.”(source)

Designing effective enabling constraints is an art. Many things feel intuitively correct, but have potentially harmful consequences. For example:

In an effort to increase certainty about plans and commitments, the team undertakes a comprehensive annual planning effort. This feels good on the surface, but it forces premature convergence, encourages over-utilization of shared resources, and encourages big, inflexible projects.
In an effort to centralize communication, the team adopts a single tool for documentation (a theoretically enabling constraint). This feels good on the surface—having documentation everywhere is painful—but since a large % of communication with external teams happens outside the central tool, you find a two or three (or more) tiered system of communication (e.g. executive communication happens in slides, not in the tool).

The trick, then, is designing effective enabling constraints. An additional layer to consider is the layer of trust, respect, empowerment, and psychological safety. Example: deadlines. In theory, deadlines can be enabling constraints. However, without empowerment and trust, deadlines become disabling. Teams cut the wrong corners, and optimize for low trust.

These two points—the counterintuitive nature of constraints, and the trust/safety element—explain why most change efforts fail. High trust environments can easily pick the wrong constraints. Or they try too much at once, and put people in a state of change overload.

AND, low trust environments can render all good intentions null and void.

We have to pick the right enabling constraints, deploy them correctly and safely, sense what is working/ not helping, and adapt accordingly.

Examples of Enabling Constraints

At this point, it might be helpful to explore some examples of enabling constraints. I will briefly describe ten examples. The goal here isn’t depth, but rather to give people a sense of what constitutes an enabling constraint.

Work in Progress Limits

The basic idea with work in progress limits is that you focus on finishing, not starting. Teams/individuals limit the number of things they are working on in parallel. When blocked, instead of spinning up new work, people focus on unblocking the work—even if it means swarming, and stepping outside of their normal role boundaries.

Planning Inventory Limits

There’s something about a calendar of projects that is very comforting—especially when your team is responsible for “servicing” lots of projects. “Now we have a plan!” “Now I know what I’m going to be working on in 2022!” “Now I can make my budget ask!” The trouble with accumulating a lot of planning inventory (especially if the work is seen as promised/committed) is that it 1) forces premature convergence, 2) it encourages high utilization and high work in progress, 3) it decreases adaptability/agility, 4) it encourages feature/project bloat, and 5) it discourages people from proposing new ideas, even when conditions change.

To counteract these things, we might limit our planning inventories. For example, only ten efforts are allowed in the “up next” column. Nothing else is committed. We can visualize ideas for the future, but only items in the up next column are definitely going to be worked on.

Cross-functional Collaboration with Subject Matter Experts

Siloed subject matter expertise is a big problem. Our instinct is to treat SMEs as a “shared service”, and to line up all the people asking for help. The trouble is that people adapt their plans to avoid the bottleneck. An interesting option for an enabling constraint might be to encourage pairing between SMEs and non-SMEs for a set period of time (e.g. 6 weeks). Yes, it is more effort to collaborate. But by closely collaborating we increase the expertise of everyone on the team. (Alternate idea: buddy system during first quarter of work).

Limiting Asks for the Constraint

A team might be fielding requests from across the organization. They have no real way to prioritize those requests, or to say no. To understand requests, they ask for detailed plans, which forces premature convergence and scope creep. They get overwhelmed, people lose trust, which forces even more reactivity (a desire to please), and things slip. An example of an enabling constraint here might be limiting the queue for a shared team (e.g. “you can only have five things in your to-do list, and we replenish the list monthly) OR to limit the number of asks any particular team can make on the shared team (e.g. “Team X can make only one request on Team Y each month”)

“One big cross-functional project at any given time + weekly project meeting with everyone”

Large cross-functional efforts require maximum attention. While it may be inconvenient to admit, a team of teams might be able to absorb only one of these at any given time. A promising enabling constraint would be to limit the number of these efforts that can happen at once. And to require that the big effort has a weekly sync with EVERYONE attending. The net effect would be to increase visibility, limit WIP, increase support levels, and focus. By asking everyone to attend the meeting, we enable ourselves to reflect on who is actually involved.

Monthly public pitch session for larger, cross-functional efforts

We want good ideas! But it is easy to get overwhelmed by a constant flow of reasonably good ideas. It gets confusing. What is committed? What isn’t? What do I do if I want the help of other people? Which good ideas can I “just do”? An enabling constraint here might be a monthly pitch session. Everyone is invited, but you can be guaranteed that senior managers will be there. The output of the session might be re-shuffling ideas in an options list.

Run cross-functional optimization team cycle with 6w timebox

It is easy to talk about the importance of cross-functional teams, but assembling one and giving them the space/support to operate (without having to do their “day job”) is difficult. A viable enabling constraint might be to “force” ourselves to ALWAYS have one, highly cross-functional team working in a focused way. Nothing else on their plate.

Required product learning experience quarterly (or extended customer collaboration)

Our work requires lots of subject matter expertise. In the hustle and bustle of “business as usual” it can be easy to skimp on learning about the domain and/or interacting with customers. An enabling constraint to remedy this might include every team member attending a 4hr+ learning experience quarterly. A learning experience might be a conference, a course, etc. If customer collaboration is the problem, we could arrange extended opportunities to collaborate directly with customers.

Learning reviews

It is important to close the learning loop. What happened to the initiative/bet after it shipped? Enabling constraint: a biweekly learning review. Attendance is required for certain senior managers, but optional for the rest of the team.

Batch size limit (linked to need for one-pager)

Lots of work that happens is “just happening”. It is on auto-pilot. It isn’t really documented, and there’s no “forcing function” to reassess the work. Enabling constraint: a one-pager for every “chunk” of work with a maximum length of one quarter. For example, if you have an ongoing effort, you would chunk it up into quarter-length one-pagers.

Other examples might include:

Meeting cadences
Quarterly roadmap refreshes
Visualizing team dependencies (forces an acceptance of dependencies)
A one week “small things’ sprint for everyone on the team quarterly
Etc.

With some examples out of the way, let's move on to the characteristics of a good enabling constraint.

What Makes For A “Good” Enabling Constraint?

No enabling constraint is guaranteed to work, but some are better than others. What should someone designing an enabling constraint look out for?

It is easy to know if you are doing it or not. For example, asking everyone to use a single document repository is a bit vague. People WILL need to use other systems to document things. Do those count? What goes in it? What doesn’t? An alternative might be to run an experiment where the team commits to putting ONE document type in the centralized repository or tool. Put another way, it is within reach and achievable.
It has an expiration date and is treated as an experiment. The best enabling constraints are treated as an experiment. The team commits to give it an honest try for a period of time. The team is promised an opportunity to weigh in on the experiment, before agreeing to extend it.
It helps people go through the motions. If you have a future state in mind, it helps to help people go through the motions a bit and try things out. In a safe way.
The world doesn’t end if it “fails”. Sometimes things don’t go as planned. That’s normal. The best enabling constraints fail gracefully. They are safe-to-fail probes.
Fast feedback potential. The best enabling constraints will provide fast feedback. Experiments that last forever, with no sense if they are helping/hurting, are dangerous (or at a minimum draining, and encourage people to just work around them).

Look for the things on the left, and watch out for things on the right:

Supporting Enabling Constraint Experiments

Selecting the right enabling constraint is only part of the challenge. The surrounding environment and situation plays a huge role in the success of an enabling constraint.

Create a supportive environment by:

Limit the number of enabling constraint experiments you try at once. Too much change at once can be very difficult to manage. Limit your CIP (change in progress).
Ensure that the team has time/energy to attempt the enabling constraint
Respect that new habits can be difficult, and may require “unlearning”
Give the experiment an expiration date
Be realistic about whether it needs to be attempted on a global or local scale. Some experiments are best attempted locally. But other experiments NEED to be attempted globally.
Be extremely clear about the goals of the enabling constraint. Detail what you might expect to see if things are working, and not working. And empower everyone to call things out if they see things going wrong.
Encourage people to “co design” the experiments. When people are involved in designing experiments, they become more vested in giving things an honest try.

Here’s a handy tool for thinking about experiments. It doesn’t mean that items more to the right are “bad”, rather that they need to be thought through a bit more carefully:

It isn’t just about picking the right constraints. You have to nurture them.

And know when to dismantle them….

Temporary Constraints And Scaffolds

Imagine for a moment a team-of-teams situation where there are tons of dependencies, overlaps, mixed messages, unclear incentives, and a lot of confusion. We know things aren’t working, but we don’t know how to unravel the mess. It is almost impossible to even visualize the problem. Whenever we think we know what is going on, something pops up to remind us we don’t.

The reality is that we have one big mess. One big team. We may WANT to believe we have individual departments, groups, teams, etc.—and we probably do, to some extent—but we also have this big mess to contend with.

The inertia in situations like this is incredibly strong. Good ideas and experiments don’t last long because the system “bites back” very quickly. So what can you do?

The central challenge here is that we need to:

Stabilize the mess, which requires using temporary structures (scaffolding) to understand what is going, AND…

Gradually encourage new structures and ways of working to emerge that are in better alignment with the goals of the system/company, etc. Gradually remove the scaffolding.

Removing the scaffolding is hugely important. Many companies install scaffolding to stabilize a situation, but never remove it! The heavyweight processes they install become the status quo. We don’t want this.

An example might help here. Here is a story (I shared on Twitter) about a CTO who successfully pulled his team out of a bad place.

I met a CTO recently who did the right (but hard) thing. He walked into work and sent out an email:
“Today, we are deleting all jira tickets. Stop working. Please use this time for personal education. You have my full support”
Why? The org was struggling under a massive amount of invisible work. Side channels. High work in progress. Overwhelmed shared teams. WIP was super high. Utilization rates were super high. Nothing could stop the inertia. So he put in the most extreme WIP limit … 0. And then started slowly re-establishing flow. There was a one hour meeting each morning to address any issues. Meanwhile if people couldn’t work, that was ok. Hang tight. If they could chip in. They did.
This continued day after day. In short order, a high value thing was unblocked and moving. Yes, there were lots of idle people. But everyone was surprised by the progress. He kept inching things forward. Very quickly one team was maxed out ! Woah. This was crazy. If this one team was under water with utilization at 20% … what were they thinking before at 100%??
He bolstered that team and asked for volunteers to join and help. This continued. After three or four months they were exceeding their old flow of work. In six months … almost tripling it. People were not underwater. They stopped losing key contributors every month.
Sometimes you need to stabilize things. Take a breath, and slowly re-establish. Bold moves when they come from a good place, or well thought out, and have full support from a formal leader can go a very long way.

The story brings to life a couple key points.

The initial “enabling constraint” was very disruptive. But the leader gave full air-cover, and took full responsibility for the ramifications. Instead of layering on the new process ON TOP of other things, he intentionally made room. The one hour morning meeting was another enabling constraint that encouraged visibility and added tempo. Quickly they identified the constraint—the shared team—and set up helping. There were immediate benefits (people not being underwater, and people not leaving).

Here’s a less over-the-top example.

A team in a similar situation agreed to visualize all of its work, and to hold a daily “board review” to talk over any blockers or impediments (and to stem the tide of new ideas cropping up). Slowly, they adapted their approach to encourage more cross-functional “pods”, and to lessen the need for the daily board review. They shifted it to weekly. And then to monthly. And finally they got rid of it.

The key lesson is that often we need to create “scaffolding” involving temporary processes. In a sense, this scaffolding is an enabling constraint. It WILL create short-term extra work, and may be a bit uncomfortable, but as we make progress we’ll slowly remove it.

Putting This All Into Action With Popcorn Flow

Hopefully the idea of enabling constraints is making some sense. But how do you put this all into action?

You have to limit your change experiments in progress
You have to focus your experiments on what matters now. This doesn’t mean you need to identify a “root cause”, but you do need to focus experiments where they have the best chance of surfacing information and learning
You have to do your best to prioritize reasonable “enabling constraints”. There’s no way to predict the perfect experiment, but there are obviously bad ideas.
There needs to be a structure in place to deploy experiments, assess experiments, and decide on what to do next. Maybe it is time to retire an enabling constraint. Maybe it is time to scale it! What did we learn?

Overview

A great tool for this is called POPCORN Flow invented by Claudio Perrone. What does POPCORN Flow help you do? It is a lightweight structure and process for continuous improvement. It helps you limit change in progress. It inspires time-bound and specific experiments, after making sure you consider your diverse options. And it asks teams to inspect and adapt based on their experiments.

On a meta-level, POPCORN Flow is itself an enabling constraint.

POPCORN stands for:

Problems & Observations
Options
Possible Experiments
Committed
Ongoing
Review
Next

We start with Problems and Observations. In the list we put observations, problems, etc. Don’t put too much pressure on the team to “find the root cause” or “clearly define the problem”. Sometimes the most valuable things are straight observations: “we’re getting tired”, “it is hard to think in the office”, “we have so much trouble sharing our wins”

Prioritize—yes prioritize. How? Focus on painkilling. Trust your instincts.

Say we prioritize: Our kickoffs are not inspiring, and don’t seem to align the team. Now, brainstorm at least three Options for how to learn more about, influence, unravel, nudge, or whatever that thing. Doing nothing is always an option! But don’t constrain yourself to one option. Our options might be: do facilitator training, shortening the kickoff, give people a one week cool-off prior the kickoff.

Next step, frame specific Possible Experiments you can run. By specific I mean the experiment has a specific Action and Duration. And some specific expectations. And an Owner. What might happen? Who will be involved in participating in the experiment? What are you on the lookout for? How might we know this is having a positive impact?

For the next three efforts we’ll add a buffer of one week before teams “finish” one thing and start the next thing, and the kickoff. We hope to see people more relaxed and able to focus.

When you’ve converged on an experiment, move it to Committed. You’ll start this soon. Of course, as with any “work”, you should limit the number of committed items. Commit at the last responsible moment.

When you start the experiment, move it to Ongoing. Give it a good, honest shot. This is “Work” not “Side Work”. Limit ongoing experiments in progress.

When the time is up, Review the experiment with a diverse group of people. Here are some good questions to cover:

What experiments did we agree to do?
What experiments did we actually do?
What did we expect to happen?
What actually happened?
What did we learn?

Based on what we learned, what are we going to do Next? What opportunity exists? Maybe it is time to try scaling this? What do we need to learn next? Why does this work? What is going on?

This video describes the approach:

If this seems similar to experiment-driven product development, you’re right! The ideas are very similar (which is a good thing, because it means you know how to do it).

Who gets involved

When people first hear about POPCORN Flow they have one of two reactions (both of which make sense):

Isn’t this the job of management anyway? I’m not sure why we need an extra process. We already do an engagement survey, solicit feedback, and then respond to that feedback.
Oh my goodness, this sounds cool!

Is this the job of management?

Depending on the organizational culture you could argue this is the job of management.

Paraphrasing a common sentiment:

Teams should be reasonable for taking care of what they can take care of. But when something is a bigger problem outside of their team, it is really the responsibility of their manager to resolve it. If they can’t, they should escalate it further. Managers should always be collecting feedback and removing blockers for their team members.

All reasonable points. But consider an alternative view. Paraphrasing again:

There’s no visibility into what management is doing. Yes, we provide feedback. Yes, they say they are going to fix certain things. But they rarely hold themselves accountable for what they are trying. Look, I don’t care whether we are actually involved in figuring out what enabling constraint experiments we will try, but at least I want to see what is happening, and be involved in providing feedback on what is tried. Also, it really bugs me when after we deliver feedback there’s no public synthesis of all the feedback. Instead, management distills the themes THEY see, and that becomes the priority.

An interesting take:

Speaking as senior management, we (I at least) would much rather you came with a proposal. Because we are probably putting out seventeen other fires you are unaware of. The people closest to the problem have the best thinking about it. I can best help my team by providing the wider context, marshaling resources from my peers, and trusting them to lead the way from there. (And then highlighting their accomplishment after!) (John Schrag, Director of Experience Design for Autodesk Media & Entertainment.)

And yet another perspective. Paraphrasing an HR team leader:

Before we started using POPCORN Flow, we would have these linear project plans for the stuff we wanted to do. We didn’t embrace experimentation. All sorts of feedback would come in, and then we’d try to respond. The team got confused about what were small experiments, and what were big things we wanted to scale. POPCORN has helped us organize our work in a more Agile way.

And finally, this survey:

It would appear that things aren’t as simple as we think. People appreciate having input and being involved in designing and deciding what experiments to try. They also look to management to provide air cover and support AND to unblock things impacting the team.

Whatever your perspective, one thing is very clear (and important). An organization cannot pretend to operate one way when it actually operates another way. Say your company takes this approach to improvement:

If something is wrong, talk to your manager in your next 1:1. Her job is to generally protect the team from distractions. Oh, and we send you an employee engagement survey once a year, do performance reviews, and give you learning opportunities.

If this is your chosen approach, it will be very difficult to suddenly open up all aspects of POPCORN Flow to the team. Why? Your organization isn’t designed for bottom-up involvement. Your organization is optimized for issues to be escalated and resolved by management. We can argue over whether this is the “right” approach, but it is what it is.

This is all to say:

Be extremely intentional about the agreements you make around POPCORN Flow. Sometimes it is a “private” tool used among managers. Sometimes it is public, but only leaders process the feedback and propose experiments. Sometimes it is public, people brainstorm problem areas, AND suggest options…and leaders decide on the experiments. All the way to a completely open approach whereby ad hoc teams form to put experiments in motion.

When thinking about ownership, consider that each step in POP has:

Soliciting ideas
Shaping those ideas
Prioritizing those ideas

Who is involved in soliciting, shaping, and prioritizing for your POP columns?

And CORN involves things like:

Participation in the experiment
Owning the experiment
Marshaling people to comply with the experiment
Gathering data to set up the review
And deciding on next steps

Who is involved in CORN for these activities?

Finally, what is the scope of the overall board? Is it for an individual, a team, a team of teams situation, a department, or the company?

The biggest failure mode for POPCORN Flow (like other experiments) is when it is unsafe, doesn’t respect current boundaries, and attempts to do too much at once. Challenging the status quo is fine, but

Scaling Things

When undertaking POPCORN Flow, people often miss an important nuance. Not all “experiments” are equal. Depending on the stage of learning, you might try very different things.

Successful change in organizations often goes through three stages:

Localized, safe to fail experiments
Experiments to see if scaling is possible and/or desirable
Full blown programs with the requisite support

A safe, local experiment is the start of the journey. We're not sure what will happen, but are willing to give something a try. If something goes wrong, no big deal. Success? Most local experiments are best left as local practices. There's no universal rule that every team should adopt what works for one team.

But say there's some traction and interest. "Scaling" a successful practice requires its own set of experiments. Is this approach net-positive? How can we entice people to give it a try? How can we support early adoption? What signals will give us confidence it is actually working (or not working)? Again, there’s no rule requiring you to scale local successes, and there’s no guarantee you will get this right on the first try (or at all).

Finally, say the groundswell is there and we want to "go big". This is where turning it into an official program, with all the bells and whistles, helps. Early adopters tend to be fine with rough edges. But most people want more explanation, structure, and support. You'll need to educate, and to clear out mental bandwidth for the change to take hold. Experimentation still happens here, but it takes on a slightly different character.

This is a deliberate progression. It takes self-awareness and humility. You might need to go back a step, reassess your approach, or stop the effort altogether. Each transition is a liminal state of sorts...the nature of the work and approach changes. There's no room for egos and people intent on owning the change narrative.

When teams/leaders/managers try to jump ahead—or work in reverse—they run intro trouble.

For example:

Company Y copies Company Z and tries a big, top-down change effort with no local proof-points and local advocates.
By the time front-line feedback has bubbled up to "the top", and formal leaders have figured out what to do, the window of opportunity has closed. There's a new problem to solve.
Scaling out a local practice without concern for differences across teams. It worked there, so it will work everywhere! Not so fast…
Rolling something out department-wide without the support of a well-structured program.
Too much change in progress. Reactivity. Lack of visibility.
"Promising experiments, but we never commit! We never have a real plan."
"We commit to things that make no sense because we're pressured to have a plan!"

Continuous improvement internally is a lot like improving a product externally. It is tempting, but dangerous, to skip steps.

Key Lesson: When thinking about enabling constraints (and POPCORN Flow) think about the potential to start smaller/safer, if it makes sense, experiment on scaling, and then finally approach larger programs with the right

In Conclusion

Enabling constraints are a powerful catalyst for improvement. But they require skill to select/design, deploy, support, and dismantle.
Change always requires thoughtfulness and attention. You need to support it. Sometimes we need more process (e.g. visibility) to address a problem. But as things improve we can release those scaffolds.
POPCORN Flow is a valuable tool for “managing” change experiments. It lets you think about improvement like a product.
You HAVE to be realistic about the boundaries for experiments like POPCORN Flow. You have to respect current boundaries, and slowly nudge them outwards.
It helps to start small. If something works locally, it doesn’t mean it needs to be tried more globally. But if you do try to scale things, then treat that as an experiment—a different kind of experiment—as well.

The Beautiful Mess

Making Things Better (With Enabling…