"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. Read More......

The Transformation of the Leader

"The first follower is what transforms a lone nut into a leader" - Derek Sivers
(reference url: http://www.ted.com/talks/derek_sivers_how_to_start_a_movement.html)

Watch the link above. In the three short minutes, you'll see transformational leadership applied and an entire systemic come into being. Derek entitled the talk "How to Start a Movement" and commenced with the bold claim that a movement would be started and unfold in just three short minutes. He delivers.

Derek successfully articulated something here that I had been trying to understand for ages: the transformation of the leader during transformational leadership. The mental shift of the leader accepting and mentoring the first follower is a key idea. In the video, the follower then goes out an works with the additional followers. Watching closely, you can see that the third and subsequent followers are closer to this first follower-leader than the original leader.

Of course, we imprint the leadership discussion onto what is externally people dancing in a field. But if we assume the original leader's vision was a dancing crowd, then the development of the follower-leader is the critical transformation leadership activity. Indeed, keeping transactional control over all the members of the dance would likely have been very counter-productive to achieving the vision of a dancing crowd.

Individual homework assignment: figure out if your leadership is contributing to developing the essential follower-leaders needed to achieve your vision. Read More......

What happens when the battle rhythm is disrupted?

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. Read More......

Thoughts on the "Engineering Battle Rhythm" of Configuration Management

We discussed battle rhythm being important. Even started some definition of Battle Rhythm on the wiki. But now let's look at one close to my heart, the engineering battle rhythm.

In the newest wiki page, Engineering Battle Rhythm, I'm starting a discussion on the nature and impact of various engineering processes and the inherent rhythm that grows up around them in an acquisition organization. The most infamous SE process is that of Configuration Management (CM), and especially the very painful Request For Change (RFC). Nothing can strike fear and doubt into an innovator's heart faster than a first meeting with the configuration managers and all the associated boards and reviews inherent to an RFC.

Of course, what I'm hoping to examine is how to operate as a Systemic Leader in that very process heavy and entrenched battle rhythm of formalized systems engineering processes (such as CM). I'm starting to apply this at work, so hopefully I'll have some perspective and experiences to share and see if any of my thoughts survive their first encounter with "the enemy" (be that enemy the configuration manager or merely reality). Read More......

On Battle Rhythm

From our wiki article on Battle Rhythm, we noted an US Army manual that cited a lack of battle rhythm can cause various issues such as leader fatigue and the leader being missing from critical decisions.

In my new job, there seemed to be various battle rhythms starting to develop. Initially, I was content to let the chiefs pick their rhythm. However, over time, I'm beginning to see that establishing a battle rhythm is very difficult, even for the most accomplished of senior leaders. Working in this new office, with a charter unlike any other office within the command, the selected battle rhythm (and several iterations thereafter) have yet to adequately serve the senior leaders.

On the topic of staff coordination and senior staff meetings, finding the right day to go with the command's decision cycle in our role as an integrator is hard. Initially, we chose the day of the week and time that worked best for the seniors. However, that time ended up being immediately after all the command decision meetings, which meant everyone only really knew the immediate out briefs. In our command, the real actions tend to flow a day or so after the meetings.

However, by moving the staff coordination to the start of the week, which would seem to be the optimal date for the command's decision process time line, we haven't had as much staff participation in the meetings. Since the office's charter is to perform coordination and integration (a kind of portfolio manager), many of the staff have subordinate commands to attend on that same day.

Even for a small office, this inability to effectively coordinate action has resulted in seniors (and their deputies, such as me) getting fatigued and scrambling to figure out where the next critical decision point lay and get someone prepared to be there.

Of course, since I'm matrixed from the system engineering organization to this coordination office, that gives me two battle rhythms to attempt to satisfy with my boss. Additionally, my parent organization's battle rhythm is well suited for engineers of single systems, but my boss and I have to service a portfolio manager, which makes our efforts unique compared with our peers.

My initial thought that is to consider integrated work/decision environments, such as operating from a war room, so that we can get the best picture of the environment. However, I do hesitate, because although getting the complete information picture appeals to me as a systems engineer, knowing that the seniors lack a battle rhythm that I can know when/where to inject that gained information makes me question if the effort will bear fruit (and here, fruit is reducing leader fatigue and getting leaders to the critical decisions sufficiently prepared).

The one light is that we just this week got a full set of deputies assigned and we seem to be working well together. If we can establish the battle rhythm in the near future, we should be able to start getting our seniors in the right places. Read More......

Hands on with Systemic Leadership

Well, been busy the past few months getting settled into a new job standing up a new organization (yes, adding to the bureaucracy). I was tapped as an "enterprise systems engineer" responsible to provide architectures, concepts of operations, requirements, and other technical support to future visions.

In this job, there are people, like a former President of a Harris division, who are very interested in understanding how to best set up the organization based on the specific leadership capabilities, personal traits, and other factors of the senior leaders. Fortunately, so far the office is relatively flat in organization, so I have insight into the workings of the seniors.

I'm hoping to start posting my observations from this experience - good, bad, and ugly to see how paying attention to the systemic (or in places where we fail to pay attention) leads to what kinds of behaviors in the organization. Read More......