Should we be trying to “reduce complexity?” An executive walks into a meeting room, clearly exasperated. It's been a long day of back-to-back meetings, conflicting priorities, and a growing sense that everything is becoming unmanageable. Normally, they don't attend this meeting but need answers for the CEO.
I so agree with this distinction! I would love to do complex, challenging work, and be able to focus on that work without navigating too many dependencies and ever-changing priorities.
And from personal experience, I know that constant high cognitive load in a complex adaptive system can easily lead to burnout.
This is a great point, some things are just complex and executives should create an environment where those things can get done.
I do think if you're the person running or coordinating this work, you have a responsibility to communicate it clearly. You should know what context the executive needs to understand and make a decision. If you're doing a death march through word walls of updates you probably didn't spend enough time thinking about how to communicate your points and get the decisions you need.
some extra nuances could be helpful here. the bugaboo being `_unnecessary_ complexity`, for instance, as opposed to `inherent complexities,` which would remove the need for what i think is an overreach:
> But if product work is inherently complex and groups of humans form complex adaptive systems, then reducing complexity in this case is impossible (and undesirable).
unnecessary, unintended, unhelpful complexities that layer on top of and in between inherent, necessary, and valuable complexities don't make things more complex, they make them complicated. that's been a helpful distinction for me that i got from "Complex Adaptive Systems: An Introduction to Computational Models of Social Life" by Miller & Page.
as always, appreciate the post john, keep up the great work!
Most of the time we conflate easy with simplicity, unfamiliarity with complexity. Complexity is inherently about interactions between people and/or systems. And while you simplify the complicated, for complexity the solution is transparency.
At the same time, we see orgs who keep it so simple—siloed teams with minimum cross-functional standards sharing, and *simple* is their comfort zone because they shy away from making it complex. I guess (hate to see it but...) leaders need to identify the right loops to move between *simple* and *complex* because sometimes complexity is the need.
Good point about reducing complexity not only being misguided, but principally limited due to the inherent complexity of product work - linked to what some are calling the "physics of flow".
I like the notion of "bounded bubbles of complexity" to avoid or at least limit the impact of local complexity on other teams. Goldratt's book "Rules of Flow" points out some other aspects like controlling work in process (avoid overload), reducing multitasking (avoid waste), providing full-kits (avoid start-stop) etc.
I so agree with this distinction! I would love to do complex, challenging work, and be able to focus on that work without navigating too many dependencies and ever-changing priorities.
And from personal experience, I know that constant high cognitive load in a complex adaptive system can easily lead to burnout.
This is a great point, some things are just complex and executives should create an environment where those things can get done.
I do think if you're the person running or coordinating this work, you have a responsibility to communicate it clearly. You should know what context the executive needs to understand and make a decision. If you're doing a death march through word walls of updates you probably didn't spend enough time thinking about how to communicate your points and get the decisions you need.
Managers often favor complexity cause it can be stimulating, challenging and create more managerial jobs
some extra nuances could be helpful here. the bugaboo being `_unnecessary_ complexity`, for instance, as opposed to `inherent complexities,` which would remove the need for what i think is an overreach:
> But if product work is inherently complex and groups of humans form complex adaptive systems, then reducing complexity in this case is impossible (and undesirable).
unnecessary, unintended, unhelpful complexities that layer on top of and in between inherent, necessary, and valuable complexities don't make things more complex, they make them complicated. that's been a helpful distinction for me that i got from "Complex Adaptive Systems: An Introduction to Computational Models of Social Life" by Miller & Page.
as always, appreciate the post john, keep up the great work!
Excellent read.
Most of the time we conflate easy with simplicity, unfamiliarity with complexity. Complexity is inherently about interactions between people and/or systems. And while you simplify the complicated, for complexity the solution is transparency.
> The executive cracks. "The process of getting s**t done is too complex!" they exclaim. "We need to simplify this!"
Everyone agrees and focuses on improving the process.
Wish my exec was reading this 😅
At the same time, we see orgs who keep it so simple—siloed teams with minimum cross-functional standards sharing, and *simple* is their comfort zone because they shy away from making it complex. I guess (hate to see it but...) leaders need to identify the right loops to move between *simple* and *complex* because sometimes complexity is the need.
Love the premise of this article! TY for crafting such a succinct narrative. I need help seeing successful outcomes of people applying this guidance.
What decision-trees did you use to go about eliminating drag / friction / priorities?
How did you communicate this elimination up/down through your company?
How did you explain the "why" behind this elimination?
Can you share before/after examples of what the "bounded bubbles of complexity with simple interfaces" mean for your department or workflows?
Focus / less priorities are essential and executives can contribute there.
Good point about reducing complexity not only being misguided, but principally limited due to the inherent complexity of product work - linked to what some are calling the "physics of flow".
I like the notion of "bounded bubbles of complexity" to avoid or at least limit the impact of local complexity on other teams. Goldratt's book "Rules of Flow" points out some other aspects like controlling work in process (avoid overload), reducing multitasking (avoid waste), providing full-kits (avoid start-stop) etc.