"But I have a process, why care about Battle Rhythm?"

With the advent of the Capability Maturity Model (CMMI and its relatives) everyone wanted to put their system and software development activities into well defined (level 3!) processes. We were sure to measure those processes (level 4!) and ensure we are quantitatively improving (level 5!). Ultimately, the goal would be to have a well defined process to ensure that given the same inputs, we get the same outputs, in a control fashion that efficiently expends resources. Essentially, most processes focus on maintenance of invariants (baseline, basis of estimate, confidence, risk posture, function across interfaces, etc).

Battle rhythms, on the other hand, sequence a leader’s Observe-Orient-Decide-Act (OODA) loop. By sequencing the the flow of any type of project information (observations) through analysis to provide perspective (orient) to help a leader’s direction (decisions) lead to coherent activities (action). However, the goal is only coherent action, indeed a battle rhythm receiving different inputs make take radically different, but coherent, action depending on the leader, even if the analysis activities are highly regimented processes to ensure the quality of the analysis.

So based on this, why take a step back from this great improvement in formally defining system and software processes to talk about systems and software leadership's battle rhythm. Honestly, in comparison to the formality of process definition, describing a battle rhythm seems to some to be a less mature concept.

But the power of battle rhythms are their simplicity; sequence the OODA functions. Battle rhythms must exist on human timelines for items that require on going decisions - for the most part that means daily, weekly, (rarely) monthly, and (very rarely) annually. Examples of battle rhythms include: handling of action items from higher management / headquarters (daily), financial reconciliation (weekly), project assessments of progress to goals (typically monthly), personnel appraisal and development (annually), mission operational planning (such as the the 72 hour Air Tasking Order battle rhythm), and mission execution (the individual pilot's life on a daily level). While the engineering review board process may be a defined process, the battle rhythm is the means that a chief engineer is able to ensure all factors are included when reviewing a technical artifact. Indeed, that battle rhythm will look very different for a military weapon software development than for a commercial, cloud-computing entertainment software development.

Although battle rhythms are simple, there is no single battle rhythm; even for a single function, there are a near infinite number of implementations. Fortunately, organizations tend to value successful battle rhythms, so effort tends to be expended to capture the essence of a battle rhythm's template (key attributes that attempt to abstract away individual considerations). These
battle rhythm prototypes tend to be saved and distributed. In the military, highly successful battle rhythms get integrated into doctrine. Outside the military, many behavior based leadership books recommend different battle rhythms for leaders. However, the important item when applying these prototypes is to consider the modifications needed for the battle rhythm to be useful for an individual leader. All of these describe various information items that should be analyzed to support a decision on action.

I can hear the process zealots saying "ah ha - sequencing of information - that's a process!" NO! The key difference is that battle rhythms are used to get to coherent action, but they do not necessarily maintain invariants. Processes specify behavior to ensure that the same inputs lead to the same outputs; and the underlying assumption that the inputs can and will be repeated often enough to validate the control. Battle rhythms, on the other hand, have to operate (decide and act) even if the inputs are missing/low quality and further the battle rhythm does NOT guarantee that the same inputs yield the same output, since the output is a decision from a leader (and different leaders will give different outputs). Battle rhythms do not prescribe decisions, only orchestrate the OODA loop.

So hopefully, this provides some some insight and points of distinction that lead us to consider battle rhythm in the system leadership context. This article is meant not to be critical of process definition in all contexts, but instead focused on aggressively differentiating defined processes from battle rhythms. Indeed, back to our systemic leadership roots, the systemic leader shouldn’t focus solely on decisions within the process, but instead should focus on shaping the battle rhythm to ensure effective action to achieve the leader’s vision.