SMH 2018 and “Cross Functional” Officers

I’ve been distracted by the publication of Learning War and the warm welcome its received, so this follow-up post on the Society of Military History’s Annual Meeting (SMH 2018) is later than I intended. What strikes me as I review my notes from the meeting is how “cross-functional” U.S. naval officers of the early twentieth century were.

Cross-functionality is a common concept in software, but unusual in a military context. I’m using it here to refer to naval officers who developed experience and skill in many different specialties—surface ships, submarines, aviation, and politics—that together created an integrated fleet. Just as many development teams today encourage broad expertise across a variety of domains and technologies, the U.S. Navy of the early twentieth century encouraged officers to develop familiarity with different aspects of naval warfare.

This theme appeared in several papers. Scott Mobley used textual analysis of two different version of William Leahy’s diary (one recently discovered at the U.S. Naval Academy) to assess Leahy’s view of the American intervention in Nicaragua in 1912. Leahy was a Lieutenant Commander in the Pacific Fleet and served as chief of staff to the intervention’s commander, Rear Adm. William Southerland. Leahy also served as the military governor of Corinto, requiring him to employ both strategic acumen and political skill. Leahy was not the only U.S. officer with a political role in the early twentieth century. A talent for foreign relations—which I think of, with apologies to Clausewitz, as “war by other means”—was desirable. Even junior officers were encouraged to develop their political skill. It was essential when communication mechanisms were slow and small ships—like those in the Philippine archipelago—were the most visible local representation of the U.S. government. I believe it made officers better equipped to deal with the inherently political challenges of high command, which include not only collaboration with other nations, but the competing incentives of different services. “Jointness” is inherently political.

Ryan Wadle gave a valuable paper on “generalists vs. specialists” in the interwar (1919-1939) U.S. Navy, a fascinating topic with important ramifications for today. Wadle used Henry Yarnell as a vehicle for his analysis, charting the major developments of his career. He started as a surface warfare officer, became head of the Newport torpedo station, and then a staff officer. Later in his career, Yarnell was head of the Bureau of Engineering, commander of the battle force’s aircraft carriers, and commander of the Asiatic Fleet. Yarnell was a “triple threat” officer, with a rich experience commanding surface ships, submarines, and aircraft carriers. He and Ernest King—who went on to become the Navy’s commander-in-chief during World War II—are the most famous examples of this cross-functional skillset, but they are not the only ones. Our discussion afterwards focused on how culture was broadly cohesive across the Navy during this time and not divided into the factions (submarines, surface, and aviators) that we see today. We left wondering what specific mechanisms the Navy used to incentivize this broad familiarity and what it might take to create parallel incentives today. The current paradigm “channels” officers into specific specialties and inhibits them from developing experience in other arms of the service.

This is obviously undesirable, because without a broad understanding of how the various elements of the fleet can be used effectively together, it is difficult for teams of officers to self-organize to solve complex problems. Specialization—in military forces and in software teams—encourages the development of top-down control mechanisms that reduce the speed of decision-making and discourage individual initiative. This is true within a specific service, but also across them during “joint” operations. A century ago the Navy avoided this by encouraging officers to develop a richer set of skills. My time at SMH 2018 has me wondering how the Navy might address this challenge today as it attempts to encourage what the current Chief of Naval Operations, Adm. John Richardson, calls “high velocity learning.”

Learning War is Coming!

I haven’t written here in some time, but I have been doing plenty of writing. My book on organizational learning in the U.S. Navy of the early twentieth century is being published by the U.S. Naval Institute this June and I’m very excited about it.

What’s it About?

Learning War: The Evolution of Fighting Doctrine in the U.S. Navy, 1898-1945 is an analysis of the development of the U.S. Navy’s approach to surface warfare—how it planned to fight a fleet action with battleships and supporting vessels—between the Spanish-American War and the end of World War II. In my analysis, I treat the U.S. Navy as a complex adaptive system and use concepts from that discipline, like enabling constraints and emergence, to illustrate why it was so effective at rapidly learning and consistently innovating. The first half of the twentieth century was a period of rapid technological change; it saw the introduction of new platforms—like destroyers, dreadnought battleships, and airplanes—and new technologies—like mechanical fire control computers, radio, radar, and turbine propulsion. The U.S. Navy was particularly effective at integrating all of these into its force structure and tactics.

How Does it Relate to Today?

Although today’s contexts and technologies are different, I believe the basic concepts that underpinned the U.S. Navy’s approach to learning and innovation are still relevant. I’ve used many of them effectively in my work with software teams; these include creating an environment of psychological safety, leveraging variability to rapidly explore new techniques and methods, and fostering decentralized decision-making to seize fleeting opportunities. In the book, I explain how these approaches developed and evolved in the U.S. Navy’s context. A core theme is the importance of continually revising approaches to ensure they remain relevant, something that the Agile community is wrestling with right now.

It will be great to see Learning War in print. I think my work is done. I’ve finalized the draft; I’ve been through page proofs and made corrections; I’ve edited the index; and I’ve gotten some very positive early feedback from historians I deeply respect. It’s been an amazing journey. If you’re interested, you can find the book on the U.S. Naval Institute’s Website, Amazon, or other booksellers.
Learning War_final.indd

“The Rules of the Game”

The subtitle of the July 2013 edition of “The Scrum Guide” is “The Rules of the Game.”1 This is an ironic choice. The Rules of the Game is also the title of Andrew Gordon’s in-depth analysis of the Royal Navy’s performance during the Battle of Jutland, a performance that failed to meet expectations and led to bitter recriminations. It is not the kind of performance software teams would wish to emulate.

Jutland was the great naval battle of World War One. In the late afternoon of 31 May 1916, the main battle fleets of Great Britain and Imperial Germany found each other in the North Sea. They fought on and off through the fading light and darkness for the rest of the day and into the night.

For the Royal Navy, the battle offered great promise. Victory over the German fleet would have opened communications with Russia through the Baltic, and permitted offensive action against the German coast. Together, these might have shortened the war.2 And victory was expected. Since Admiral Horatio Nelson’s victory at Trafalgar in 1805, the Royal Navy had enjoyed a preeminent position; no other naval force could compare in size and power.

The promise of victory grew more certain during Jutland’s opening moves. Signals intelligence gave the Royal Navy early warning of German movements, allowing the British to concentrate overwhelming force at the anticipated contact point. British scouting forces successfully located the German battle fleet, and led it toward the Royal Navy’s battle line. The Germans soon came under the largest concentration of naval gunfire in history, far away from their bases, outnumbered, and outgunned. Defeat seemed certain. But the promise was not fulfilled; the German fleet not only survived, but managed to inflict more punishment than it received.3

The failure of the Royal Navy to win a decisive victory is the dominant theme of Jutland. Most assign blame to the fleet commander, Admiral John R. Jellicoe, or his chief subordinate, Admiral David R. Beatty. Gordon’s analysis goes beyond personal explanations and examines the Royal Navy’s system of command. Gordon illustrates how the Royal Navy’s command mechanisms—the “rules” that had been established to guide the behavior of officers in battle—hindered rapid decision-making, crippled individual initiative, and thwarted success at this most critical juncture.4

The primary problem was an overreliance on orders and instructions from above; this created an environment where subordinates were hesitant to act on their own initiative, even in situations where such behavior endangered their forces or their mission.5 Both Beatty and Jellicoe were forced to assume the burden of commanding the bulk of their forces directly. They shouldered this responsibility quite well, but the challenge of attempting to coordinate the movements of a large battle fleet, in fading light and darkness, while maneuvering to intercept a fleeing enemy was too great for any one person, or even a small group. Jellicoe and Beatty needed greater initiative from their subordinates in order to deliver on Jutland’s promise.

This was not something the Royal Navy was prepared to deliver. The limited initiative displayed by subordinates was an unintentional—but wholly predictable—consequence of the system of rules that governed their behavior. The rules took the place of intelligent action. Instead of focusing on using every available means to defeat the enemy, the Royal Navy adhered to the “rules of the game.”

The Scrum Guidance, by creating a similar system of rules, risks creating nearly identical, unintended side effects. Scrum teams often will hesitate when confronted with situations that are not anticipated or accounted for by the rules, rather than addressing the problem creatively on their own initiative. This is common, for example, when access to the Product Owner is limited. With no one to groom or prioritize the backlog, the influx of work slows, and progress begins to stall.

A more insidious problem is that rules can frequently hinder learning, particularly when situations that contradict the rules are encountered. Because the rules provide a context for framing the problem, the most common response is to conclude that the rules have not been implemented properly. The team convinces itself that if they could only be “good enough” the problem would be solved. This view can blind a team to alternative approaches and can hinder the customization of Scrum for their own context.

If problems do arise, wasteful arguments about the correct interpretation and enforcement of the rules are likely, particularly in stressful situations or where failure has occurred. This can easily divide the team and shift focus away from the main goal of delivering software.

Gordon’s analysis illustrates all three of these negative outcomes. Limited individual initiative was a key component of the Royal Navy’s failure to decisively defeat the Germans at Jutland. In the years before the battle, alternative approaches to command were evaluated and discarded; their value was missed because the existing framework—the existing system of rules—prevented a fair assessment of them. And, most visibly, the aftermath of the battle saw a split between Beatty and Jellicoe, which led to a “Jutland controversy,” centered on their different approaches to leadership and their interpretation of the “rules.”6

Rules are necessary to help guide behaviors and align the work of teams. The performance of the Royal Navy at Jutland offers a salient example of the problems that can develop when too much emphasis is placed on adhering to rules. This is relevant for software teams, because software teams—like navies—make it their business to capitalize on dynamic and changing environments. Success in such circumstances requires individual initiative and low-level decision-making. The Scrum Guidance, by emphasizing “rules of the game” risks hindering the ability of teams to capitalize on the initiative of their members and learn from unanticipated circumstances, both of which are goals of the Scrum Framework.


2. Commander Holloway H. Frost, The Battle of Jutland, (United States Naval Institute, 1936), p. 108-116

3. Keith Yates, Flawed Victory: Jutland, 1916, (Naval Institute Press, 2000)

4. Andrew Gordon, The Rules of the Game, (Naval Institute Press, 1996)

5. The best examples of this are the handling of the 5th Battle Squadron early in the battle (Gordon, p. 81-101) and the failure of the destroyer flotillas to report encounters with the Germans during the night (Gordon, p. 472-499)

6. Gordon, p. 537-561; Yates, p. 257-275