This blog post from the devops guys, shows that the idea of “survival mode” or chaos can exist in many different places. and a command and control leadership can help buy valuable time that you can then use for learning. to quote :

Step 1. Kill the current fires, so sanity and actual thinking resume.

“When I took over the Operations of a high-volume UK website about 8 years ago I spend the first 3 weekend working fighting fires and troubleshooting Production issues.

My first action after that baptism of fire was to revoke access to production for all developers (over howls of protests). Availability and stability immediately went up. Deafening silence from Development – Invitations to beers from the Business owners.

 

Next step, get some friendly forces to help with the effort, if no one within has any idea what you are driving at:

Next step was to hire a build manager to take over the Build and Deployment automation, and a Release Manager to coordinate with the Business what was going into each release, when etc. End result – 99.98% availability, with more releases, being deployed within business hours without impacting the users, and a lower TCO. The Business was much happier, and so was the Development Manager, as he was losing far fewer developer-hours to fire-fighting Production issues, and hence the overall development velocity improved considerably. Win-Win.

 

Their view of survival mode Command and control:

 

Was that a DevOps anti-pattern? Did I create more silos? Probably… but in a fire-fight a battlefield commander doesn’t sit everyone down for a sharing circle on how they are going to address the mutual challenge of killing the other guy before he kills you. Sometimes a command & control model is the right one for the challenge you face (like getting some suppressing fire on the target while you radio in for some air support or artillery!).

The post goes on to talk about using the freed time for learning and getting better (in not so many words):

That said, once we had developed a measure of stability we did move partway to a more DevOps pattern – we had developers on-call 24×7 as 3^rd line support, we virtualised our environment(s) and gave Developers more control over them, and we increased our use of automation.

Later on, the post mentions that organization influences (see ‘structural motivation - six forces) like different incentives, stopped the continuous learning from breaking up any new silos of knowledge.

overall, this is a very interesting read for me, as I can see many parallels in the ops word to the software world and the elastic leadership principles.