Strategy versus Doctrine

What They Are, How They Interact, and When to Use Each

Source: Unsplash

Introduction

As someone who has dabbled with the concepts of strategy and doctrine for at least four decades, I am increasingly frustrated by the incorrect usage of these terms. The saintly figure above is no coincidence - doctrine comes to English via Old French doctrine from Latin doctrīna “teaching; instruction,” which is built on the verb docēre “to teach” (same family as doctor, document, docile). In English, it first meant “that which is taught,” then shifted to “an authoritative body of principles or tenets,” especially in religious or legal contexts.

Strategy, similarly, comes (reportedly) from the old Greek, strategos, meaning “art of the general.” So, whereas doctrine had a biblical underpinning, strategy had a military one.

Strategy and doctrine, as I will show, are both sides of the same coin, and this is, incidentally, a useful metaphor with which to picture the two concepts - I will explain later. What I, therefore, hope to achieve with this article (the Aim, for my military-oriented friends) is a clear, no-nonsense explainer grounded in classic theory and real-world practice on how strategy and doctrine differ, where they overlap, and how to use both without tying yourself in knots.

Astract

Strategy is a context-specific design that aligns Ends, Ways, Means (and Risk) to achieve a defined aim; doctrine is the authoritative guidance that codifies principles and preferred methods for recurring tasks - best practice, if you wish. The following principles serve as the guidestones when developing and implementing strategy and doctrine:

• Let strategy lead and doctrine accelerate. Strategy chooses what matters now under constraints; doctrine standardizes how teams execute reliably at scale—both should evolve with feedback.

• Use strategy to make trade-offs, exploit asymmetries, sequence actions, and confront risk; use doctrine to train, integrate, and ensure interoperability (“authoritative, but requires judgment in application”).

• Avoid failure modes. Doctrinal capture of strategy, strategic hand‑waving, checklist fetishism, and frozen doctrine - counter these with blank‑sheet design, explicit risk calculus, principle‑based guidance, and rapid learning cycles.

A useful construct with which to show how these concepts interact with one another is the following flow of work: Policy → Strategy → Concepts/Doctrine → Plans → TTPs (Tactics, Techniques, and Procedures) → Action → Feedback. Outside the military, the same pattern applies to business, government, and NGOs.

A One-sentence Distinction

Strategy is the tailored bridge from policy to action—a context-specific design that aligns ends, ways, means, and risk to achieve a political or organisational aim.

Doctrine is the authoritative playbook—the codified principles and preferred methods that guide how an institution operates typically. It’s “authoritative, but requires judgment in application.” Doctrine rests on three legs that operate continually with each other - Theory/Knowledge, Experience, and Technology (OK, it’s two sentences…).

The following table shows the differences quite clearly.

Table 1: Strategy vs Doctrine

Why People Confuse Them

The main reason, of course, is ignorance. But more specifically, it may be related to the following:

• Both sit between policy and execution. Strategy translates policy into a competitive design; doctrine translates experience, theory, and technology into reusable guidance for execution.

• Both use similar language. You’ll hear “concepts,” “approaches,” “principles,” and “effects” in both domains.

• Both influence behavior. Strategy sets direction; doctrine shapes habits. If you don’t distinguish them, you risk letting habit (doctrine) silently dictate direction (strategy).

Back to the coin metaphor: I find the most helpful way to explain the difference is to refer to the development of Air Power strategy and doctrine. Many years ago (from the days of Da Vinci and probably before then), there was a theory that manned flight should be possible. But it was only when technology had sufficiently caught up in 1903 that the Wright brothers made manned flight possible. After that, a great deal of experience was obtained, especially during WWI with the employment of air power, and that, together with further technological breakthroughs, led to new theories about the employment of air power, e.g., strategic bombardment as advocated by the great air power theorists like Douhet, Mitchell, and Trenchard, as we saw employed during WWII (as only one example).

Doctrine may, therefore, be seen as best practice. But there are always limitations on employing pure doctrine, mainly of a financial nature; hence, the strategies that one develops must take cognisance of doctrine, but usually cannot use it as is.

Source: Unsplash

How They are Similar (and should work together)

Following from the last paragraph in the previous section, it should therefore be evident that there exists a symbiotic relationship between the two concepts:

• They both shape choices. Strategy selects what to do and not do; doctrine narrows the how to what usually works best.

• They both encode learning. Strategy should be revised by feedback; doctrine is literally institutionalised lessons learned.

• They reinforce interoperability. A strategy that involves multiple units or partners relies on doctrine for common vocabulary, interfaces, and expectations.

The mental model to keep in mind is: Policy → Strategy (ends-ways-means-risk) → Concepts/Doctrine → Plans → TTPs → Actions → Feedback. If you jump from policy straight to doctrine, you skip the competitive design and end up with proceduralism (going through the motions): doing the familiar rather than the necessary.

The feedback loop at the end is critical to prevent this from happening and to keep on refining both strategy and doctrine. Just some examples of these loops in practice are:

• OODA (Observe, Orient, Decide, Act). This is a continuous loop developed by Colonel Johan Boyd of the USAF, and one that is executed continually at a very tactical/operational level during, e.g., a fighter pilot’s mission. It enhances a pilot’s situational awareness and sense-making abilities.

• DMAIC (Define, Measure, Analyse, Improve, Control). This is a Six Sigma problem-solving tool that has more operational and strategic-level applications.

• Close related is the so-called Deming/Shewhart wheel/cycle, consisting of PDCA (Plan, Do, Check, Act).

Using Strategy Well

Today, there is a myriad of strategic planning models/frameworks out there. It is, however, essential to distinguish between the concepts of Strategy and Strategic Planning.

Strategy is the integrated set of hard choices—a coherent theory of how you’ll win (ends–ways–means–risk) given your context and constraints—while strategic planning is the structured process that translates that theory into budgets, initiatives, milestones, and accountability. Strategy is about direction and advantage (what you will and won’t do, the trade-offs you’ll accept); strategic planning is about sequencing and orchestration (who does what, when, with which resources). You can have meticulous planning without real strategy (a busy calendar with no competitive logic), and you can have a sharp strategy that still fails without disciplined planning. Strategy should drive the plan; the plan should pressure-test and refine the strategy. In short: strategy is the design; strategic planning is the build schedule—and mistaking one for the other is how organizations get motion without progress.

Some examples of strategic planning tools/frameworks are:

• SWOT (Strengths, Weaknesses, Opportunities, Threats) Analysis.

• Porter’s Five Forces. Analyzes industry competition and potential profitability by examining rivalry, buyer and supplier power, new entrants, and substitutes.

• McKinsey 7-S Model. A comprehensive tool that categorizes seven elements—Strategy, Structure, Systems, Shared Values, Skills, Style, and Staff—to assess organizational effectiveness.

• Balanced Scorecard. A framework for managing the execution of strategy, moving beyond purely financial measures to incorporate financial, customer, internal processes, and learning and growth perspectives.

• Blue Ocean Strategy. A visual tool for developing new business models or describing existing ones.

A useful construct with which to illustrate how these concepts influence each other is the following:

Figure 1: Planning’s Intellectual Process

But when all is said and done, strategy may be reduced to Ends, Ways, and Means:

• Start with the aim (Ends). What political, organizational, or market effect do you want—and why?

• Design your Ways. Choose coherent lines of effort that exploit asymmetries—not just best practice but a better fit for your situation.

• Resource your Means. People, money, tech, authorities, time. Make explicit trade-offs.

• Confront Risk. Identify assumptions, adversary adaptations, and failure modes. Decide what risk to accept, mitigate, or transfer.

• Sequence and adapt. Strategy is iterative. Build in feedback loops and decision points.

Red flags! A strategy that reads like a doctrine manual or like a wish list without confronting constraints and risk.

Using Doctrine Well

Treat doctrine as guidance, not handcuffs. “Authoritative but requires judgment.” The context decides when to bend or break it. Other points to consider are:

• Use it for repeatability. Training, integration, and safety all benefit from doctrinal standardisation.

• Continuously refine. Retire obsolete practices; codify what recent operations showed works better.

• Translate to the end user. Doctrine should be legible to practitioners by using things like checklists, playbooks, and drills - not just conceptual prose.

Red flags! Doctrine deployed as “the answer” to a novel problem, or a doctrine update masquerading as a new strategy.

Common Mistakes

Apart from the above, the following are some mistakes to guard against:

• Doctrinal capture of strategy. You choose a course of action because it fits the manual, not because it fits the problem. Solution. Begin with a blank-sheet strategic design before selecting doctrinal methods.

• Strategic hand-waving (pie-in-the-sky). Grand aims with no resource calculus or sequencing. Solution. Write the risk paragraph first; force ends-ways-means alignment afterward.

• Checklist fetishism. Over-specifying procedures for complex, adaptive environments. Solution. Emphasise the commander’s intent and mission-type orders; keep doctrine principle-based.

• Frozen doctrine. Lessons are not learned. Solution. Institutionalise after-action reviews and rapid doctrine cycles (using DMAIC or PDCA).

Outside the Military

Business. Strategy is where to play/how to win under constraints (markets, rivals, regulation). Doctrine is your operating model: playbooks for sales, incident response, product releases, and quality gates.

Government and NGOs. Strategy aligns finite funds and authorities to outcomes (public health targets, crime reduction). Doctrine standardises case handling, data collection, and interagency coordination.

Practical application. Craft the strategy (ends-ways-means-risk), then select or adapt doctrinal methods to execute. If no doctrine fits, prototype, test, and - once repeatable-turn it into doctrine for the next time.

A Simple Field Test

Only five questions are required to decide whether you are on the terrain of strategy or doctrine:

1. Aim. What specific change in the world do we seek?

2. Design. Why do we believe these lines of effort will outcompete alternatives?

3. Resources. What will we not do or fund to enable this?

4. Risks and Assumptions. What could break our theory of success? What tripwires will alert us? Strategic assumptions testing/surfacing is an important field that I will write about in the future.

5. Doctrine Fit. Which existing playbooks support this plan - and where must we deviate?

If your document answers numbers 1–4 with specificity, you’re in strategy mode. If it’s mostly #5, you’re in doctrine mode. You need both - but in the proper order.

Case Study

The easiest way to show the interaction between strategy and doctrine is by means of a simple case.

Problem Statement. Imagine a national cyber agency wants to reduce ransomware impact by 40% in 24 months.

Strategy. Prioritize high-leverage sectors; impose costs on top-tier crews; subsidise rapid patching in SMBs (Small and Medium-sized Businesses); align insurers to reward controls; launch cross-border takedowns. Explicit trade-offs (using, as an example, Blue Ocean strategy’s ERRC grid - Eliminate, Reduce, Raise, Create): pause less-impactful public awareness campaigns; shift budget to rapid-response teams; accept diplomatic friction risks.

Doctrine. Standard incident playbooks; evidence handling procedures; information-sharing formats (STIX/TAXII); tabletop exercise templates; joint takedown protocols.

The strategy makes the asymmetric plan; the doctrine ensures reliable, interoperable execution at scale.

Conclusion

Strategy is situational design under constraints (generally of a financial nature); doctrine is institutionalised best practice.

Let strategy lead; let doctrine accelerate.

Revise both through feedback - strategies adapt to context shifts (in your environment); doctrine evolves with evidence.

References

Arthur F. Lykke Jr., “Toward an Understanding of Military Strategy,” Military Review (1989).

Barry R. Posen, The Sources of Military Doctrine (Cornell University Press, 1984).

Carl von Clausewitz, On War. (Book I on policy and chance).

Colin S. Gray, Modern Strategy (Oxford University Press, 1999).

Lawrence Freedman, Strategy: A History (Oxford University Press, 2013).

NATO, AJP-01 Allied Joint Doctrine (current ed.).

Richard Rumelt, Good Strategy/Bad Strategy (Crown, 2011).

U.S. Department of Defense, DOD Dictionary & Joint Publication 1: Doctrine for the Armed Forces of the United States (current ed.).

UK Ministry of Defence, JDP 0-01: UK Defence Doctrine (latest ed.).