Filtering by Tag: ops

ooda redux - digging in and keeping context

Putting together some thoughts from a few posts from 2012 on OODA [one, two, three]. For some reason, the idea had been getting a lot of airtime in pop-tech-culture. Like most things that get pop-ified, the details are glossed over—ideas are worthless without execution; relying on the pop version of an idea will handicap any attempt at its execution. 

I’m not an expert. But, I’d wager that Boyd: The Fighter Pilot Who Changed the Art of War is the best read on the subject outside of source material from the military.

OODA stands for Observe, Orient, Decide, Act. It’s a recasting of the cognition<->action cycle central to any organism’s effort to stay alive, focused on a  competitive/combative engagement. 

Get the data (observe). 

Figure out what the world looks like, what’s going on in it, our place in it, our adversary’s place in it (orient).

Project courses of action and decide on one (decide).

Do it (act).

The basic premise is that, in order to best an opponent, we have to move at a faster tempo through the loop. Boyd used a more subtle description—operate inside the adversary’s time scale. 

First: If we traverse the loop before the adversary acts, then whatever they are acting to achieve may not matter because we have changed the environment in some way that nullifies or dulls the effectiveness of their action. They are acting on a model of the world that is outdated

Second: if we traverse the loop before the adversary decides, we may short circuit their process and cause them to jump to the start because new data has come in suggesting the model is wrong

Third: if we traverse the loop at this faster tempo continuously, we frustrate the adversary’s attempt to orient—causing disorientation—changing the environment faster than the adversary can apprehend and comprehend it, much rather act on it. We continue to move further ahead in time while the adversary falls backwards. By operating inside the adversary’s time scale.

Another detail from Boyd—all parts of the loop are not made equal.

Fundamentally, observation and action are physical processes while orientation and decision are mental processes. There are hard limits to the first and no such limits to the second. So, two equally matched adversaries can both conceivably hit equal hard limits on observation and action, but continue outdoing each other on orientation and decision. 

But realistically, adversaries are not equally matched. We don’t observe the same way, using the same means, with the same lens, etc. We don’t act the same way, with the same speed, etc. And being able to collect more data, spend more time orienting, leads to better decisions and actions. Being able to move through different parts of the loop faster, as needed, renders the greatest advantage. Compressing the decision-action sequence gives us a buffer to spend more time observing-orienting. Nailing observation gives us a buffer to spend more time orienting-deciding. We can come up with the best--not the fastest--response and act on it at the optimal--not the fastest--time. Getting a loop or more ahead of our adversary gives us a time buffer for the whole thing. It puts us at a different timescale. It allows us to play a different game, to change the game

Deliberately selecting pacing, timescale, game—strategic game play.

Ops/devops analogs:

  • Observe - instrumentation, monitoring, data collection, etc.
  • Orient - analytics in all its forms, correlation, visualization, etc.
  • Decide - modeling, scenarios, heuristics, etc.
  • Act - provision, develop, deploy, scale, etc.

Startup analogs:

  • Observe - funnel, feedback, objections, churn, engagement, market intel, competitive intel, etc.
  • Orient - analytics in all its forms, correlation, assigning and extracting meaning from metrics, grasping the market map and territory, etc.
  • Decide -  modeling, scenarios, heuristics, etc.
  • Act - prioritize, kill, build, target, partner, pivot, fundraise, etc.

Those are analogs. It’s worth keeping in mind that OODA was developed for the context of one-to-one-fighter-jet-to-fighter-jet combat and not anything else.

reaching peak people

San Francisco, Silicon Valley, DC, Baltimore, Chicago. I've hit most of these cities multiple times this year and one thing has started to stand out clearly: there's a talent constraint.

It stood out most at VMworld last month + Surge this month. Then I read this

Are we reaching “peak people”?

It seems like in a lot of companies we are. There’s a shortage of talent out there, and if there’s a shortage of resources, you want to conserve those resources.

That's Jason Fried of 37signals. I've been talking to technology companies, enterprises, startups, state agencies, federal agencies, defense organizations and this is becoming a recurring refrain. "How do we move the organization forward? What kind of people do we need? Where do we get them?" That's not even what I cover or talk about, yet the question keeps coming up.

I don't think it's a fundamental technology skill supply problem, though. I think it's an allocation problem. Too much money is chasing too few problems spread out over too many organizations all employing the same kinds of people to do the same kinds of things. And that's how it'll stay--until things move on + the field is decimated.

Peak people.

P.S. I do think there's a supply problem for a particular skillset: systems people who understand applications + vice-versa. But that has most (in my opinion) to do with the fact that the kind of education that takes seems to have dropped off the general computer science curriculum.

how I learned to love noops

Operators who develop. Infrastructure as code. Automation permeating systems. Very good. As a one time sysadmin, I hold to the notion that the better an operator the more of her work she eliminates through code.

But developers operating? No. I don’t want coders, especially app coders, anywhere near infrastructure. Specialization and abstraction create a big gap from developers to infrastructure. Taking systems for granted makes them dangerous.

Enter DevOps/NoOps. Developers are responsible for their code: what it uses, where it goes, how it works, when it breaks, who it affects. All of it. All the time. They have to learn how systems that deliver and execute code function. They have to plow through the abstractions and close the distance to infrastructure.

That’s how things started anyway. Le Roi est mort, vive le Roi.