The Value of "Disorganization", or Turbulent vs Laminar Development
You know how, when you turn on the tap, the water initially comes out all nice and smooth and neat and transparent? And then as the flow increases, things start going a little wonky? This is the difference between Laminar and Turbulent flow, between water that is coming out neatly, all lined up, and in layers, vs water that is irregular, chaotic, and mixing with itself all over the place.
And yeah, there is very definitely an analogy to be made with organizations here.
And I'm not here to disagree with this - you actually do want these characteristics in most (if not all!) of your internal systems, processes, and services.
That said, there are characteristics associated with Turbulent flow that are very definitely A Good Thing - remember the flow is higher when turbulent, and there is a lot of "mixing" that is going on within the flow!
In short, you do want some level of turbulence, of "chaos", when you want to increase the rate at which your org delivers product, and likewise, when you want to insure that there is plenty of communication across people and teams.
Take the following two org types
You've had your product in the marketplace for less than a year, and, "Oh crap, we're offline!" At times like this, you definitely want a seamless well-oiled playbook that you run with. The thing is, what if the incident does not have to do with a situation that's been dealt with before? You're staring into the abyss, and you don't know why s**t is broken?
Especially early on in your org's lifetime, this is where the value of intuition comes into play. e.g. Carol sez. something like "I bet it's Oban rate-limiting requests! Give me a moment, and I'll push a change to get some visibility into this!" and a few minutes later, BOOM, you've found the problem. The thing is, this is exactly when the "short-circuiting" of your regular processes become invaluable - you approved her PR without the requisite double-code-review, and the cooldown period, and it paid off.
On the other hand, consider a mature organization, where everything is run/scored/played like an orchestra. You now want to pull together a tiger-team that is going to deal with a particularly knotty - and pressing! - problem, or, you want to launch a new product line to counter a threat in your market. If you do this per all your systems and processes, it'll take you a year to be done, and that's just not in the cards! Again, this is a situation where you want to relax the rules, and accept a certain amount of disorganization, of "chaos".
Mind you, almost by definition, the larger the size of the group, the more processes you need to keep things aligned and moving, and the more Laminar you want (heck, need!) the group to be. But that, as described above, can and will be counterproductive in times of stress!
It's one of the reasons that you want to keep your groups sizes small. I've always tried to ensure that any particular product team caps out at 20-30 people for pretty much this reason - it's a relatively good balance between streamlined structured product lifecycles, as well as the necessary unstructured interactions necessary to allow for speed.
(And yes, think "modular". If your product team needs 100 people, try and break it out into sub-products, etc.)
Finally, please account for nuance in all of the above! Of course you don't want random people pushing code into production all the time. And yes, if you need to have certain rules in place for SOC.2 compliance, don't break those rules. The key is to differentiate between processes that exist to provide value, and processes that have accreted to deal with increasingly finer edge-cases that, in the current situation, don't hold any value!
Comments