It seems to be a bit of cargo cult, to be honest. They seem to take inspiration from ER teams or the military.
I think that this kind of drill helps a lot for cases where you can take a pre-planned route, like deploying that backup server or rerouting traffic. But the obvious question then is: Why not automate that as well?
When it comes to diagnosis or, worse, triage, in my experience you want independent free agents looking at the system all at once. You don't want a warroom-like atmosphere with a single screen but rather n+1 hackers focusing on what their first intuition tells them is the root cause. In a second step you want these hackers to convene and discuss their root cause hypotheses. If necessary, you want them to run experiemnts to confirm these hypotheses. And then you decide the appropriate reaction.
They seem to take inspiration from ER teams or the military
It’s probably nothing but overestimation but I feel like I’m seeing more of this later in my career than I did early on, or maybe I’m paying more attention?
Whatever it is: past experience (which includes coming from a military family in the states) has taught me to avoid companies that crib unnecessary amounts of jargon, lingo and colloquialisms from the military.
Curious if others have noticed or even feel the same and what your experiences have been for feeling similarly?
I don't know how old you are but my career now exceeds two decades. I definitely see this more now but that's because I institute it. Earlier in my career, we failed at incident management and at ownership. We now share the burden of on-call not just with the operators (sysadmins or old) but also with the people who wrote the code. We've spent a lot of time building better models based on proven methods, quite a few come from work done in high intensity roles paid by tax dollars: risk analysis, disaster recovery, firefighting, command and control, incident management, war games, red teams.
You've got a couple of years on me, I've been in the game a little over 13 years now.
I support the notion there's a strong difference between lingo that's properly applied to the situation and lingo that is recklessly applied because it "sounds cool".
The examples you gave seem to be fair game for the work being done-in the interest of brief, specific language; the examples I gave in another comment though ("flanking","breaching") however are just grating and...weird to use in a work environment.
Agree completely. It's a strong signal that someone has a military cosplay fetish (which very few people with experience in the actual military do), which in turn tends to come along with other dysfunctional traits. It's a warning for me that the person is not likely to be a good vendor, customer, or collaborator.
My favorite one was when a superior was explaining a plan to right-size some new machines as we slowly migrated customers onto the appliance, and some particularly aggravating issues we were having with memory consumption that upon inspection and a lot of time spent-made no real sense to us why it was occurring the way it was.
"dvtrn you are to take the flank and breach this issue with Paul"
And this ran all the way up to the top of the org. Senior leaders were constantly quoting that Jocko Wilink fella. It was...something.
My old man (a former Dill Instructor, made for an interesting childhood) found it utterly hilarious when I'd call him up randomly with the latest phrase of the day, uttered by some director or another. To my knowledge, and I sure-damn asked, the only affinity anyone on the executive team had with the military was two of them having buddies who served.
I agree. I think this particular framing gets things slightly wrong. You want parallelism, but you still need central organization (so that you can have clear delegation) and delegation of work to various researchers. For a complex incident, I've seen 5+ subteams researching various threads of the incident. But, importantly, before any of those subteams take any action, they report to the IC so that two groups don't accidentally take actions that might be good in isolation but are harmful when combined.
My experience is there’s little conflict between a central conference call or room, and multiple independent investigators, since those investigators need to present and compare their findings somewhere. It would indeed be a mistake to demand everyone look at one high-level view, though. Based on the organization depicted in the article, this would be the “researcher” role, split among multiple people.
I think that this kind of drill helps a lot for cases where you can take a pre-planned route, like deploying that backup server or rerouting traffic. But the obvious question then is: Why not automate that as well?
When it comes to diagnosis or, worse, triage, in my experience you want independent free agents looking at the system all at once. You don't want a warroom-like atmosphere with a single screen but rather n+1 hackers focusing on what their first intuition tells them is the root cause. In a second step you want these hackers to convene and discuss their root cause hypotheses. If necessary, you want them to run experiemnts to confirm these hypotheses. And then you decide the appropriate reaction.