From predicting to anticipating: Adding the multi-level perspective to enabling constraints in platform engineering

In my previous article on enabling constraints we discussed the term “constraint” as not being barriers and limitations or restrictions but as powerful catalysts. Enabling constraints, paired with closed feedback loops channel creativity and guide consumers in achieving positive business outcomes. Feedback loops in this case allow for continuous improvement of the enabling constraints to make sure they allow the consumers to be as effective as possible.

At the start of the previous article I mentioned Frank Geels’s Multi-Level Perspective (MLP)[1], lets review the enabling constraints topic but now through the lens of MLP and see what insights we get.

MLP: A framework for understanding change

Let me start by saying that I’m in no way an expert in the topic of Multi-Level Perspective. I was introduced to the topic in a workshop on anticipatory awareness many moons ago and have been expanding on applying it to my day-to-day job internally and with customers ever since.?

MLP is a valuable framework in my opinion for understanding the different levels of societal systems, let's look at how MLP considers change as occurring within three interconnected levels:

• Niche innovations (Micro): Where radical new ideas are born and tested, often shielded from mainstream market pressures.
• Socio-technical regimes (Meso): The dominant practices and configurations around which industry standards revolve.
• Socio-technical landscape (Macro): The broader context that includes cultural, political, and environmental trends influencing other levels.

In my posts I mostly talk about enabling constraints in the context of platform engineering. This post is not different and I want to discuss how MLP would apply to that specific context.

Platform engineering and multi-level perspective

Enabling constraints with closed feedback loops in platform engineering serve as mechanisms that facilitate transitions.

Applying the three levels of MLP to this:

• At the niche innovation level constraints can foster innovation which leads to emergence of new solutions.
• In the regime we ensure that new solutions align with the existing structures but also make sure that they are easily adaptable by consumers.
• The landscape is where feedback loops sit providing information to stakeholders needed to effectively adapt strategies in response to trends.

Enabling constraints are catalysts for innovation by providing a pathway for organisations utilising the broader trends and achieving positive business outcomes.

By applying MLP, you can probably see that enabling constraints are not just a tool, a practice but in fact can be instrumental, being integral elements that interact dynamically with larger systems both influencing and being influenced.

Theory → Practice

There is a lot more to MLP then we will cover here including the Change Types covering frequency, amplitude, speed and scope of the change as well as Transition Pathways covering different transitions and how impactful the landscape change is as well as the effect of the niche on the regime.

Taking MLP in the context of enabling constraints from theory to practice the following (open) practice can be adopted (I’m unsure about the official name of this practice, maybe you know?). Let’s walk through the 6 steps of the Story exercise, you will see many of this is purposely done from back to front:

1. Characters: Who is in the story?

The stakeholders involved in your platform engineering endeavors. You want to understand how the enabling constraints guide the actions of each of them. Also with alignment with strategic objectives and efficient collaboration in mind.

2. Ending: What outcome is the scariest one you can see? What happens to your characters?

Everybody can probably imagine what can go wrong and what would be scary. Think for example about system breakdowns, security breaches, technical debt accumulation (technical debt is a fact of life but accumulating, poh ??). But of course also inefficient and therefore ineffective platforms looking at achieving business outcomes. Jumping ahead, regarding the enabling constraints we will want to design them in a way they avoid these undesired results.

3. Middle: What happened to make the outcome possible? What did your characters do?

Steps were taken to get to the mess you are in. In this step you would go into that. With Platform Engineering the enabling constraints would help steer teams away from for example risky practices that would lead to these issues. Not only would they steer you away but what is provided promotes efficiency, collaboration and adherence to various guidelines, eg. architectural.

4. Beginning: How did this story become possible? How did it all begin?

This exercise can be applied (and maybe you should) to your existing current state. What were the initial conditions that gave rise to the current state of your platform? This will mean you need to consider looking at legacy systems, architectural decisions, existing “enabling” constraints but also incidents that happened. Understanding the past allows you to build a path for the future and come up with enabling constraints that are a better fit for what you want to achieve.

5. Triggers: What signals would tell you the story has begun? What “sensors” would you need to monitor?

We are now getting very close. This is the stuff you will need to monitor for. What will be the early indicators that your story is unfolding? In the world of platform engineering you can think of resource (over) utilization, deployment frequency, response times or for example general system health. Maybe it’s actually developer NPS dropping or some coffee machine feedback ??. Your enabling constraints should have clearly defined monitoring points providing you with information about potential risks but also about successes early.?

6. Story Title:? A nice title for your story ??

Coming up with a nice, enticing title for your story should be too hard. I will share two relevant quotes, which can be used to inspire a title, by two people I hold dear.?

“Your code has no value unless it’s deployed” - Burr Sutter

“Happy Engineers produce Happy Code” - Jim Wittermans

Above you will find an image of how you could visualize the responses in Miro as an example. Facilitation in a tool like Miro will allow you to work async as well as time-box the different steps allowing you to get to results efficiently and effectively.

In my opinion a basic understanding of MLP and platform engineering and this practice gives you a great start to incorporating enabling constraints in a way that aligns with strategic business goals while allowing the flexibility needed for continuous improvement.

Want to get going yourself?

A quick start to put the above into practice and as a part of the bigger process:

1. Identify the stakeholders of your platform ecosystem → What are their needs and challenges so you can shape enabling constraints aligning with strategic goals.
2. Analyse the existing “enabling” constraints → What does the current platform engineering implementation look like regarding practices and existing constraints. What works and what doesn’t work, so what empowers innovation and collaboration and what hinders your productivity.
3. Map the MLP levels to your implementation → In your setup what maps to landscape, regime and niche? With desired transitions (eg. using change type, transition pathways) in mind what constraints should be (put) in place to reinforce this transition?
4. Apply the storytelling exercise → Check out the practice as described before and envision possible futures including what will help you steer towards desirable outcomes and away from negative outcomes. (You should be able to reuse responses to earlier steps of the quick start.)
5. Implement and monitor → With all these new learnings we can move to implementing our revised enabling constraints. We want to provide the right balance between freedom, flexibility and security, reliability, compliance. Make sure to monitor the implementation and its impact and refine where needed.
6. Continuous improvement → Keep anticipating and adapt the constraints when needed. This will make sure you both stay efficient and effective in supporting your business.

Conclusion

Multi-Level Perspective (MLP) is an incredibly powerful framework for understanding the different levels of societal change. Enabling constraints with closed feedback loops are the catalyst for innovation and allow consumers/businesses to focus on what makes most sense. Linking the two together we can see how interconnected levels of influence shape the platform’s evolution: The niche level fosters innovation, the regime ensures stability, and the landscape dictates broader trends.

The discussed storytelling exercise including the quick start guide allows for bringing MLP to the world of platform engineering and enabling constraints and supports you in coming up with the next step of your?journey.?It will allow you to move from predicting to anticipating!

I am very much looking forward to hearing from you in the comments regarding any experience you might have with MLP but definitely also with regards to figuring out enabling constraints for your platforms. Please leave your thoughts in the comments.

[1] Example of MLP in action: Frameworks for understanding transformations to sustainability – the ‘Multi-Level Perspective’ in socio-technical transitions research