Understanding and changing your constraints

As I'm teaching today*, I was reminded of a way I used to describe system constraints back when I taught a lot of kanban classes and helped design kanban systems. This quick post captures them for reference and to seed a discussion. 

This post was originally created in 2020, and was recently refreshed with updated language as needed. “Today” was a long time ago.

What do I mean by constraint? Why do I care?

“We need to always remember that the organization is perfectly tuned to deliver the behavior we see, and people’s behaviors are the perfect result of the organization’s design. As individuals, we should embrace our responsibility for being the best we can be within the design of the organization. But as leaders, our responsibility is to design the organization so that individuals can be the best versions of themselves." - L. David Marquet, Leadership is Language, p35.

When I look at a system, I'm often looking with an eye of "what can be changed?" and "what can't be changed, and why?" This is one of my biggest tools for helping me see possibilities and opportunities for how a system or organization can flex and evolve to better deliver what its customers value and desire. In asking the second question, I find answers that generally fall into three categories of constraints, and I found it useful to label those categories to simplify discussions and make it easier to teach others how to see the system differently. In practice, a constraint usually represents a decision or policy, along with the results of having had that decision or policy in effect.

As an example, a constraint might be "We have 30 people", which represents the result of a budget decision and a set of hiring decisions. Others might be "We can't deploy to production until security signs off" or "We won't start new large-scale work without a fully engaged business owner."

Usually, I'm not trying to create an exhaustive list of constraints. Instead, I'm usually looking at a behavioral symptom and a set of potential root causes, and then looking for the constraints that have led to those behaviors. I then use lean/agile principles and mindsets to explore how changing those constraints will lead to the organization behaving differently.

Three types of constraints

There are three categories I lump constraints into, regardless of what gives rise to them. I selected this lens because I'm really sorting them into the categories of "this group can change it", "the company can change it, but not inside this group", or "there's no meaningful path to changing it with reasonable cost." Simplifying it down to this set of three avoids a lot of swirl with groups that would otherwise try to be overly precise in their categories.

Inherent - These constraints are essentially a part of physical reality driven by the existing context. With investment, they can be mitigated or the boundaries can be shifted, but generally they exist by virtue of the context… the speed of light, servers costing money, the cost of debt financing, the market’s response to company news, etc.

Imposed - These constraints are ones that have been selected elsewhere in the organization, either as a broad cross-cutting policy or as an executive decision. Examples include corporate compliance requirements, HR policies, strategic budget allocation, and architectural roadmap plans. The key point of this category is that the constraint can be changed, but not from inside the current scope of conversation. I often find that when "they" starts showing up in a conversation, we're looking at an imposed constraint, and we should bring the "they" into the room if we want to change it.

Elected - These are constraints that originate from inside the group having the discussion. They chose the constraint or made a decision that gave rise to the constraint. They can choose to remove it, or invest to reverse the impact of the previous decision. The key distinction is that the group is in control. Ideally, these are things that a group chooses in order to create focus and drive speed. Sometimes, however, the experiment fails, or the constraint stops serving the original intent, and that's when they become zombie constraints. At this point, they need to be removed, and the team can do so.

What do I do with these?

In general, these become really important during retrospective activities at various levels. My general guidance in these cases is to seek to understand the constraints that are influencing the situation, sort them into these categories and then process as follows:

• Note the inherent constraints, and then set them aside. You can't meaningfully do anything about them, so continuing to spend calories and emotion on them doesn't really help.
• Act on the elected constraints, making the changes you can immediately and starting the work required to mitigate the impact of previous decisions. It's remiss and marginally disrespectful to ask other groups to change before demonstrating your own investment to start improving the situation. Also, I find that fixing the local constraints first often changes the system in a way that leads to easier, more elegant solutions to the imposed constraints.
• Engage the imposed constraints with the broader group required to change them. Don't assume they can change in the way the local group wants, and don't assume the local group has an accurate understanding of the intent of the constraint. Engage with curiosity and seek empathy, and then jointly determine using the new, expanded "us" to improve the system by evolving the constraint. Most importantly, don't tell the other group what they should do. "Tell" and "should" damage relationships and hinder the ability to get to a meaningful improvement.

Summary

Fix what you can: the elected constraints.

Fix imposed constraints by working collaboratively in the bigger box.

Choose good elected constraints by asking/inspecting the smaller boxes.

Don't fight the inherent constraints.