This is great points! I like the notion of „enabling constraint“ especially well because it is a fantastic metaphor for the solution to alignment-capability I offer in my recent book: https://www.ripeframework.com/book
That third tension (relatedness) can be treated as a mediator that helps to determine the optimal balance between "Autonomy" AND "Alignment". Visualize it as the junction point of a mobius loop - neither the beginning or the end - but somehow both the output and the input.
Let me explain in practical terms...
Take a team of teams that are all working within a modular monolith situation. They are "separate but equal". There is the best separation of concerns. The "relatedness" is more abstract than real because (by design) there is no tight coupling.
We observe the type of work and realize that some teams are rewriting an existing legacy system which has its own challenges when the overall motivation is "modernization", while a few teams have a wider gap to fill because it is the greenest of "green field" projects.
At a glance, the teams look very comparable but the fundamental dynamics and challenges they face diverge sharply. One kind of team is operating within simple or "merely complicated" questions. The other kind of team is much more exploratory because the unknown unknowns can't be accounted for and planned for in advance - no matter how much "planning" and "risk assessment" is done.
So, if you are a Portfolio leader, you basic instincts suggest that "consistency" (often treated as a synonym for "alignment") is where efficiencies can be easily gained. So, they go about imposing "best practice" processes - almost always modeled from "what we know" (which turns out to be more or less OK for some teams while extremely unwise for other teams...)
The point of this is that these tensions operate within different contexts. Teams develop their own personality of sorts because of the dynamics and forces acting on them. It is behavioral.
One definition of agility (Highsmith) is the ability to respond to change while balancing "flexibility" AND "stability". This is the same thing as "autonomy" AND "alignment" simply framed slightly differently. In fact, you recognize and name "alignment" as an "enabling constraint" (structure intended to bring stability...)
Agility is contextualized balance. If one wins of the other bad things happen (predictably). If we do not tend to the tensions/dilemmas/paradoxes in ways that maintain balance, if we treat them as "problems to solve" instead of "tensions to manage" then our thinking will be flawed and our approaches will not help (ever).
Thanks for your thoughtful comment, one thing I have a different perspective on: (Enabling) Constarints are NOT about stability.
Constraints are about managing the search space.
Too many constraints = search space too small -> settle for one of the few and obvious solutions
Too few constraints = search space too big -> settle for one of the many obvious solutions
The right amount of constraints = search space becomes managable and there are non-obvious and surprising solutions -> this is where (disruptive) innovation happens.
Exactly. That's why "flat organizations" are the new "fake agile" - yet another extreme and buzzword that is treated as "the answer", but like all simplistic models, doesn't work in the real world.
Leaders need to define strategies (with input from below), and empower, but observe and question - and sometimes intervene in a constructive way.
Just getting rid of more managers is JUST LIKE the Agile community's mistake that had the same narrative: bad managers are a problem so get rid of managers.
It's a child's reaction, not a solution.
Alignment is absolutely necessary for rapid progress - alignment with a high degree of empowerment, and inclusive ideation.
Heck, that's why we named our product "StreamAlign", because alignment is so critical.
Good article and I completely agree that lack of alignment between teams can lead to silos being formed. I was thinking about that when I started reading your article and contemplating Hendrik's matrix. Some good thoughts. Thanks for sharing.
This is great points! I like the notion of „enabling constraint“ especially well because it is a fantastic metaphor for the solution to alignment-capability I offer in my recent book: https://www.ripeframework.com/book
You won't be surprised to learn I love the article and fully agree with your message.
Nice to hear from you Willem-Jan! I hope you're doing well, it's been a while! :)
I'm doing great. And you?
That third tension (relatedness) can be treated as a mediator that helps to determine the optimal balance between "Autonomy" AND "Alignment". Visualize it as the junction point of a mobius loop - neither the beginning or the end - but somehow both the output and the input.
Let me explain in practical terms...
Take a team of teams that are all working within a modular monolith situation. They are "separate but equal". There is the best separation of concerns. The "relatedness" is more abstract than real because (by design) there is no tight coupling.
We observe the type of work and realize that some teams are rewriting an existing legacy system which has its own challenges when the overall motivation is "modernization", while a few teams have a wider gap to fill because it is the greenest of "green field" projects.
At a glance, the teams look very comparable but the fundamental dynamics and challenges they face diverge sharply. One kind of team is operating within simple or "merely complicated" questions. The other kind of team is much more exploratory because the unknown unknowns can't be accounted for and planned for in advance - no matter how much "planning" and "risk assessment" is done.
So, if you are a Portfolio leader, you basic instincts suggest that "consistency" (often treated as a synonym for "alignment") is where efficiencies can be easily gained. So, they go about imposing "best practice" processes - almost always modeled from "what we know" (which turns out to be more or less OK for some teams while extremely unwise for other teams...)
The point of this is that these tensions operate within different contexts. Teams develop their own personality of sorts because of the dynamics and forces acting on them. It is behavioral.
One definition of agility (Highsmith) is the ability to respond to change while balancing "flexibility" AND "stability". This is the same thing as "autonomy" AND "alignment" simply framed slightly differently. In fact, you recognize and name "alignment" as an "enabling constraint" (structure intended to bring stability...)
Agility is contextualized balance. If one wins of the other bad things happen (predictably). If we do not tend to the tensions/dilemmas/paradoxes in ways that maintain balance, if we treat them as "problems to solve" instead of "tensions to manage" then our thinking will be flawed and our approaches will not help (ever).
Thanks for your thoughtful comment, one thing I have a different perspective on: (Enabling) Constarints are NOT about stability.
Constraints are about managing the search space.
Too many constraints = search space too small -> settle for one of the few and obvious solutions
Too few constraints = search space too big -> settle for one of the many obvious solutions
The right amount of constraints = search space becomes managable and there are non-obvious and surprising solutions -> this is where (disruptive) innovation happens.
Exactly. That's why "flat organizations" are the new "fake agile" - yet another extreme and buzzword that is treated as "the answer", but like all simplistic models, doesn't work in the real world.
Leaders need to define strategies (with input from below), and empower, but observe and question - and sometimes intervene in a constructive way.
Just getting rid of more managers is JUST LIKE the Agile community's mistake that had the same narrative: bad managers are a problem so get rid of managers.
It's a child's reaction, not a solution.
Alignment is absolutely necessary for rapid progress - alignment with a high degree of empowerment, and inclusive ideation.
Heck, that's why we named our product "StreamAlign", because alignment is so critical.
Good article and I completely agree that lack of alignment between teams can lead to silos being formed. I was thinking about that when I started reading your article and contemplating Hendrik's matrix. Some good thoughts. Thanks for sharing.