The Journey Towards Organizational Complexity (And the Way Back)
EASE your way out of emergent complexity
Emergent complexity can and will take over your organization.
Because that’s just what it does. Emergent complexity is the purple loosestrife that’s quietly taking over the floor of your garden while you’ve been worried about whether your plum tree should be trimmed down to 10 feet or 12. (Are you a horticulturist who sees some inconsistencies with that metaphor? Sue me.)
Based on the 90 seconds of extensive and comprehensive online research I did, it seems purple loosestrife is in fact possible to control, if quite difficult to do. So it goes with emergent complexity.
Organizations, left alone (so to speak), go like this:
Simple —> Complicated —> Complex
A wannabe complexity theorist like me might try to sound knowledgeable and describe it as “energy must be expended to contain entropy”. An engineer or manager would probably say something else, like “I used to know how to get things done around here, but not anymore.” (True story!)
Emergence
So you started a company? Congrats! Everything is hunky dory at first. There’s a handful of people doing a handful of things. There’s some code to be written and deployed, there’s some documentation to be written, and the odd customer (lucky you!) who’s using the product in the one way you didn’t plan for. All very manageable. SIMPLE.
Turns out those customers aren’t particularly troubled by that bug they ran into, yay! They want more. And they tell their friends, and pretty soon everyone’s like “I’ll have what she’s having.” You’re gonna need more people! So you hire a few, then a few more, then a few more people.
Now Big Bank is interested in your product but could you get that compliance work done, first? Big Telco sends you a Big PO conditional on you closing just a few Big Security risks. Well you like those $$, so you get it done. Now there’s a formal QA team running solution tests and a dedicated AppSec team screaming bloody murder at those XSS vulnerabilities. So you add a few checkpoints and a few gates and, well, it seems reasonable that engineers are like “I don’t know all the steps, man” and you decide you need some coordination and oversight so in come a few managers. Not as easy as it used to be, but it all kinda works, as long as you exercise a healthy dollop of discipline. COMPLICATED.
You’ve got a good product, so no surprises Humongo Retailer wants in… if you could just give them better documentation, and Gargantuan Gasoline Co. is interested too, expect they would love better support. Sure! Bring on a few writers and support specialists. Add a few items to that checklist and a manager to coordinate Field Enablement and Customer Success and voila! Right? Well, actually…. congrats, you just got COMPLEX.
Let’s recap: You had a simple system with only a few moving parts. You could figure out what would happen if you tweaked this over here and that over there. Like, just you, in your head, could figure it out.
Then you added more moving parts. You could still figure out what would happen, except maybe you need help on some things. You need a bit of divide and conquer so it may be complicated, but at least you can still reason about your system.
But then you added a few more parts and some of those parts got pretty complicated themselves. You added a few interfaces between teams so you could get a bit of control and buffer some of the work because not all teams are perfectly aligned and sized and… and… and… gradually, then suddenly, you realize that rather than gain that additional bit of control, you actually lost control. Probably damn near altogether lost control.
What the actual heck?
Complex Systems
Most of my intuition about complex systems can be summed up as follows: if you put together a few work loops, buffers where things move from one work loop to another, and feedback loops between the work loops, you soon end up with a system whose behavior is non-linear and, given enough of those loops and buffers, unpredictable.
That’s emergent complexity in a naive nutshell. Turns out that’s quite enough to build intuition into why its so easy to get into unmanageable levels of complexity and, equally, why it is not impossible to unwind to a simpler state.
Of course, your best best is to stay simple in the first place. Keep process simple. Keep architectures simple. Keep organizational structures simple. (If you want to nitpick, add “as possible” to the end of those sentences.)
If you've only just taken the step towards complicatedness, you can take the step back to simplicity.
Complicated systems haven’t made the jump into complex systems yet. Rube Goldberg machines may not have anything approaching emergent behavior, but stick a few buffers in here and there, throw in a few positive and negative feedback loops, and maybe string a couple of the machines in series, and B. O. O. M.
If you’ve crossed the chasm into complexity, put on your helmet, pick up your sword, and prepare to do battle. Here be dragons!
Crossing the Chasm (Back)
Crossing the complexity chasm feels a bit like taking that big 30-year mortgage on your home. One day you don’t have a mortgage and one day you do. But there’s no snap-of-the-fingers way back, though! If you want to work your way back across the chasm, you have to slowly, methodically pay down principal, not just interest.
Thanks for all the metaphors. But what can we do, actually?
We’ll use the idea of an “EASE Loop” to identify the types of things we can do to work our way back from an environment of complexity to one of simplicity.
What is EASE? Its just a simple mnemonic for a checklist of sorts:
Eliminate — eliminate process steps, entire processes, work queues, buffers between teams, and such. This reduces complexity by, well, eliminating things entirely: fewer moving, interacting parts. Indeed, fewer parts.
Automate — take the cognitive load and human variability out of the equation if something can’t be eliminated… assuming you’re sure — really sure — that it can’t be eliminated. This reduces complexity by taking away the variability of human action - in duration, in latency, in consistency, in correctness.
Simplify — if it can’t be eliminated or automated, can you simplify it? Make better data available, reduce the number of people who need to be involved in a decision, etc? This reduces complexity by reducing the variability of human action.
Educate — quite simply, make sure everyone knows what they need to know. This reduces complexity by reducing the likelihood of mistakes or missed actions, and by reducing the time between stimulus and action.
Eliminate
Start with a rough inventory of work loops, buffers, and feedback loops. E.g., in a typical software development process, you might go from development to test with a buffer of completed work because test may lag dev in qualifying features, and a buffer of bugs because dev may lag test in fixing bugs. You could consider (actually, should consider!) the following:
Eliminate the test loop and make it part of the dev loop - i.e. develop and test in unison. This might be a tightly knit scrum team, or even the same person tasked with both activities, coupled with a definition of done that includes both development and test.
Eliminate the buffer from dev —> test - i.e., if features are going faster than testing them, have more people test them so they can be shipped. Don’t let the buffer grow uncontrollably.
Eliminate the buffer from test —> dev - i.e., if a bug is found, stop everything and fix it. Don’t let this buffer grow uncontrollably.
Each of these offers tradeoffs, and various development methodologies address them directly or indirectly. The price of always working on bugs first could be seen as disruptive to developer flow, but it may be offset by having developers and testers often being the same people.
Automate
Now look at everything that’s done manually. A review step, an approval, an update in a spreadsheet, a command entered in a shell. Anything. And automate it away, keeping in mind that automation means steps are automatically triggered and automatically executed. The idea is easy, but sometimes not trivial to spot because of culture or habit. Also, there are times when something needs to be slightly reworked, e.g., a step broken into two, to facilitate automation.
A simple example: an engineer may need to update a ticket with the branch name into which a fix for the ticket was submitted. To provide context for reviewers and future code readers, the code checkin usually contains the ticket number. So could a tool update your ticket for the developer based on a checkin comment?
Simplify
In almost every case, eliminating and automating will directly lead to simplifying something. But there are other, perhaps more subtle, things at play. Let’s consider two teams at a company, one focused on development infrastructure and another on product development. Team A needs things from Team B, maybe Team B needs things from Team A. Maybe one team provides requirements to the other, whatever. Team A also needs to update Team B on the status of its requests, and potentially vice versa. One possibility is for each team to develop its own processes and tools. E.g., one team uses scrum and tracks its work in a shared spreadsheet. The other uses kanban and Jira. Each team now has to know about the other team’s tools and processes to arrive at a good working relationship. What to do? Consider the following ways to simplify this:
Use a single backlog in the same tool. This is a kind of elimination, I suppose. Now at least teams don’t have to learn two tools.
Use the same processes. E.g., adopt scrum across teams and align sprints.
Remove the dependency loop. Make one team dependent on the other but not vice versa.
E.g., formalize a “domain team” and a “platform team” as defined in the (amazing, amazing) Team Topologies (ITRevolution, 2019) book. This clearly calls out the interaction between teams and, more importantly makes the dependency acyclic.
Educate
Sometimes, you just don’t have anything that you seem to be able to E, A, or S. Maybe you have a dependency on an external vendor. Maybe financial compliance requires not only that some work be done but also dictates how it must be done. In those cases, the key to getting things done is simply… knowing how!
Interestingly, teams often will start here. They will start by documenting a process, building runbooks, or delivering training on how to do something. That is ok as a starting point. It is important to immediately review everything in the documentation and training for opportunities to eliminate, automate, or simplify. Blessed are those who look, and do not find, for they have already left the cursed land of complexity.
Go Round and Round
Once your first pass is complete, take another pass, then another. Each simplification opens up new options for automation or elimination. Education increases insights into avenues for simplification. And so on.
But does it work?
Well, truth be told, I’ll have to get back to you. If it seems intriguing, check back with me in a few months! Or better yet, try it and let me know if it worked for you.
More to Explore
So there you have it. An amazingly named amazing framework to work your way back from complexity to a get-work-done state.
A couple more thoughts before we wrap up:
Phil Venables’ amazing posts on successful security programs say:
A successful security program (although I imagine this advice could apply to any discipline) is made up of two distinct elements:
A series of episodic big bets that yield transformational improvements.
A set of management practices and approaches applied relentlessly, iteratively and subject to constant incremental improvement.
If you just do the first then the success that those improvements bring taper off or are a just a patch-work of bright spots amid a back drop of issues and instability. If you just do the second then you are condemned to operate in reactive catch-up mode in the face of events.
There are many wonderful insights embedded in that but here’s what’s relevant to the topic under discussion: if the two big elements are the “numerator”, then there’s a missing “denominator”: in making those bets and improvements, how much additional complicatedness or complexity have you added? The more of that you add, the less valuable your big and small bets both become. Complexity is sometimes the hidden cost of change, especially when change and improvement is so naturally seen as the addition of things, not the subtraction of things. When thinking about changes, you may need to start by changing the mindset around change — by agreeing and internalizing that change can be very much about removing things, about EASE.
Finally, I’ll leave you with this TED talk. I like the fundamental idea of fighting complicatedness as a critical (even main) aspect of organizational success. I’ll have to consider reading his book — Six Simple Rules — to digest the ideas more since the TED format obviously stops at very abstract formulations. I do have a big terminology gripe though: I think he’s got complexity and complicatedness backward, although we agree the ultimate goal is to stay simple!