You are not a member of this wiki.
Pages and Files
Engineering Battle Rhythm
Systemic Leadership Model
Add "All Pages"
Battle Rhythm is the sequence or priority order of the work needed to accomplish the endeavor as a factor of the environment.
Battle rhythms are not processes - battle rhythms are fluid, manageable, and necessarily morph under pressure. The battle rhythm is a higher order concept than a process or a schedule, because the real battle rhythm is more the how the team responds to pressure.
Battle rhythm puts tasks before teams to accomplish
Battle rhythm puts decisions and issues before the leader
Battle rhythm may have tasks/work pushed on by the environment
One example of a battle rhythm is the
Engineering Battle Rhythm
, which is the team reaction to implementing formalized engineering projects in a real team environment.
Healthy verses unhealthy rhythms (tasks that have increased level of waste with respect to accomplishing the endeavor)
factors that add health to the rhythm (tasks are appropriate to the endeavor or remove waste or add clarity)
factors that destabilize the rhythm (tasks that draw focus away from the endeavor)
good rhythm ensures that the effort of the team is on the right work for the endeavor
good rhythm ensures that a leader is capable of making the most important decisions at the right time
Definitions of rhythms are sequenced activity/product development over a notional life cycle
DoDD 5000, DAU training
The US Army uses battle rhythms (an example is available
). Note in section I-66, the tremendous impact of not having/knowing your battle rhythm:
I-66. Without procedures establishing battle rhythm, leaders and units reach a point of diminished returns. This typically occurs between 72 and 96 hours of operations. As leader fatigue sets in, information flow, planning process, execution, and sustainment suffer—often greatly. Symptoms of diminished battle rhythm include the following:
Leaders not fully aware of critical decision points (DPs).
Leaders not available at critical DPs.
Disjointed time lines between various levels of command.
Of course, a battle rhythm isn't a process and the leader not a process asset. Even though there may be a healthy battle rhythm to cue up decisions to a leader, sometimes events must take the leader out of the office and away from the immediate team. Customers must be briefed, higher headquarters placated, previously unknown opportunities exploited. Even with a well established battle rhythm, meetings will conflict. Of course, this is the time for the transformational leader to shine. For if the leader doesn't want to be a process asset (something required to do the work), or a barrier to decisions being made (by forcing them to wait until the leader's return), then the systemic leader must prepare deputies, subordinates, and team members to be able to chart those short courses until the leader is next available.
How is this done? Many techniques are covered in the literature (setting standards, etc.), but most important is preparing the team to own the work and ensure they understand the vision for the end objective. Hear what I'm not saying: I didn't mention setting thresholds, transactional delegations of authority, or ensuring people know their boundaries. A transformational, systemic leader has prepared the team to execute, and while the leader's personal presence may be appreciated by the team, the team should understand the group vision and have sufficient ownership to march out without explicit instructions.
"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.
help on how to format text
Turn off "Getting Started"