Writing · Tales of Engineering Leadership
Commander's Intent
What Alexander, Afonso de Albuquerque, and a Prussian defeat taught me about leading engineering teams
I spend my days leading engineering teams and a good part of my evenings reading about people who led very different ones: Alexander crossing into Persia, and the Portuguese captains who felt their way down the African coast and across the Indian Ocean. They all shared a constraint, and it made them better leaders than our tools allow us to be. Once the expedition sailed or the battle started, they could not micromanage anyone. And rather than fight that constraint, the best of them built their entire way of leading around it.
We have the opposite problem. Our tools let us watch everything and weigh in on anything, at any hour. So what did commanders who could not control the details know about leadership that we, who can, keep forgetting?
The Luxury Great Commanders Never Had
At Gaugamela in 331 BC, Alexander faced a Persian army several times the size of his own. A detailed plan would have been useless to him. Once he charged with the Companion cavalry (and he always charged in person, at the point of decision) he vanished into the dust with everyone else. The army held together because every commander knew the intent: refuse the left, stretch the Persian line, and strike the gap when it opened. Parmenion, holding the left under enormous pressure, didn’t need instructions from a general he couldn’t see. He needed to know what the battle was for, and he did1. In Everitt’s account, the detail that stayed with me is the morning of the battle. His officers found Alexander asleep and had to wake him. The decisions had already been made. Nothing he could say once the lines closed would reach anyone anyway.
Seventeen centuries later, and much closer to home for me, Prince Henry the Navigator ran what may be history’s longest-range delegation exercise. He never sailed on the voyages of discovery he dispatched. He stayed in Portugal and sent captains down an African coast where the charts simply ended. Cape Bojador was the edge of the known world, wrapped in currents, fog, and legends of a boiling sea, and expedition after expedition (the chroniclers count fifteen) turned back. Henry’s response was never a more detailed plan, because there was nothing to base one on. It was to restate the intent and send another ship. When Gil Eanes finally rounded the cape in 1434, he did it months beyond the reach of any instruction2. Henry couldn’t give his captains a route, since nobody had one. He gave them something closer to a default decision rule: whatever you meet out there, come back knowing one more stretch of coast than the last voyage did. No plan could exist for waters nobody had sailed, and that instruction didn’t need one.
A lifetime later, Afonso de Albuquerque governed Portuguese India at the far end of the same logic. A letter from Lisbon took the better part of a year to reach him, and thanks to the monsoon windows, an answer to a question asked in Goa could take two. The crown’s written instructions were obsolete before they arrived.
Intent steered him instead (break the hold of the old spice routes and secure the Indian Ocean for Portugal). The how, taking Hormuz, Goa, and Malacca in the space of a few years, was largely his own reading of the situation on the spot, some of it ahead of anything Lisbon had asked for3. The empire was possible only because the king’s authority could travel no faster than a carrack, so the deciding had to live where the information was.
Jena, and the Doctrine Born from Defeat
The idea got its name from a catastrophe. In 1806 Napoleon destroyed the Prussian army, the most drilled and obedient force in Europe, at Jena and Auerstedt. The Prussians had perfected soldiers who did exactly what they were told, and that was precisely the problem. While their officers waited for orders, the French, moving faster and deciding locally, took them apart. The reformers who rebuilt the Prussian army (Scharnhorst, Gneisenau, with Clausewitz among them) concluded that the fault wasn’t the soldiers but the system, and out of that grew Auftragstaktik, or mission command. Tell subordinates what to achieve and why. Let them decide how4.
Helmuth von Moltke, the great Prussian chief of staff, gave the doctrine its most quoted justification: no plan of operations extends with certainty beyond the first contact with the enemy’s main strength5. Clausewitz had already named the underlying reason friction: the accumulation of small uncertainties that makes even the simplest action difficult in practice6.
Every roadmap I’ve ever seen met its own version of first contact, usually within a couple of weeks.
Stephen Bungay, a historian who spent years bringing this thinking into business, describes the trap with three gaps: a knowledge gap (we know less than we’d like), an alignment gap (people don’t do quite what we expect), and an effects gap (actions don’t produce quite what we intend)7. The instinctive response to all three gaps is more detail. And Bungay’s point, which the Prussians paid for in blood, is that more detail makes all three gaps worse, and what actually closes them is clearer intent.
Nothing Is Below the Horizon Anymore
Henry physically could not signal a caravel below the horizon, and Manuel I could not steer Albuquerque from Lisbon. We can.
Slack reaches everyone, the backlog tool records everything, and a leader can comment on any pull request in the company from their phone. Technology removed the constraint that forced great commanders to lead through intent, and an awful lot of what we call management is what grew back in its absence: the ticket specified down to implementation detail, the approval gate, the status meeting that exists so someone can feel the voyage is under control.
I’ve written before about how projects, PRDs and RFCs concentrate decisions at the moment we know the least. This is the same disease seen from the org chart. When leaders transmit instructions instead of intent, every surprise must travel up the hierarchy and wait for new orders to travel back down, and the people closest to the information are left with the least authority to act on it. David Marquet, who commanded a nuclear submarine, calls his alternative intent-based leadership, and the mechanism he used is simple. He stopped giving orders, and his officers announced “I intend to…” instead, so that the thinking (and the authority) sat with the people who had the information8.
The research points the same way. Accelerate found that generative, high-trust cultures and autonomous teams are among the strongest predictors of both delivery performance and organisational performance9. Conway’s old observation cuts both ways here too, since an organisation that communicates through orders and approvals will build systems full of bottlenecks shaped exactly like them10.
The Engineering Translation
None of this means leaders do less. Mission command is famously more demanding of the commander. The work is different, and five practices carry most of it for me.
State intent in one page, and make the “why” do the heavy lifting: The problem, the customer, what winning looks like, and any real constraints. If the team only remembers one thing, it should be the why, because the why is what lets them improvise well when the plan meets reality. This is the same one-pager I’ve argued should replace the PRD. I’ve just come to understand it as an intent document.
Ask for the brief-back: The Prussians didn’t assume intent had landed. Subordinates restated the mission in their own words before departing. The engineering version costs ten minutes. Before work starts, the team explains the goal back and how they plan to approach it. The classic catch is a read-back that has the problem right and the customer wrong: the one-pager aimed at one kind of user, the plan quietly shaped for the users the team knows best. Ten minutes of restating is cheap insurance against weeks of confident building for the wrong people.
Give boundaries, not instructions: “Customer data doesn’t leave the EU region” and “solve it inside our domain, and if the fix needs another team’s service, come back, because that’s a redesign signal” are constraints a team can steer around, and constraints of that kind are honest: they encode real limits, a contract in the first case, our own team boundaries in the second. A step-by-step instruction mostly encodes a guess about a situation nobody has met yet.
Write a default decision rule: Henry’s captains sailed under what amounted to one (whatever happens out there, come back knowing one more stretch of coast) and I try to give an engineering translation of it to every team: “when in doubt, ship the smallest thing that gets us real user feedback”. When someone is blocked and I’m unreachable, that sentence is what they fall back on.
Review outcomes, not methods: If the demo shows working software moving toward the stated intent, resist the urge to relitigate how. The fastest way to teach a team that autonomy is fake is to grant it in planning and revoke it in review.
Where the Analogy Breaks
The limits matter here, because it’s easy to make history say whatever we need it to. Armies and crowns could compel obedience in ways no employer can (thankfully). War has an enemy and an ending; products have neither. Albuquerque himself is a cautionary tale as much as a model. The same distance that freed him to act also let intrigue fester in Lisbon, and he was relieved of his post by the time he died in sight of Goa. Intent without trust flowing both ways eventually collapses. And mission command was never intent instead of competence: Auftragstaktik worked because Prussian officers shared years of common training and doctrine, so a commander could trust that “how” would be filled in well. Marquet says the same about pushing authority down, which only works alongside competence and clarity8.
Intent without shared practice is just abdication with better vocabulary. For engineering teams, I’d argue our doctrine already exists: test-driven development, continuous delivery, small batches, pairing. The XP practices I keep returning to are what makes a team safe to trust with the how, and the discipline is what earns the autonomy.
Lead Like You Can’t Interrupt
None of the commanders in this post chose intent over instructions out of virtue. They chose it because reality gave them no alternative, and it turned out to be the better way to lead anyway.
We got the alternative back. We can interrupt anyone, anywhere, mid-voyage. Which means that for us, leading through intent has to be a choice, made daily, against the pull of every tool on our desks.
I ended my last post by saying teams should steer instead of aiming. This is the other half. A leader’s job is less to hold the wheel than to make sure everyone knows where the harbour is, and to trust the crew with the sails.
Footnotes
-
Everitt, A. (2019). Alexander the Great: His Life and His Mysterious Death. Random House. See also Arrian, The Campaigns of Alexander, Book III, on Gaugamela. ↩
-
Zurara, G. E. de. (1453). Crónica dos feitos notáveis que se passaram na conquista da Guiné. See also Russell, P. (2000). Prince Henry “the Navigator”: A Life. Yale University Press. ↩
-
Crowley, R. (2015). Conquerors: How Portugal Forged the First Global Empire. Random House. Albuquerque’s own dispatches survive in the Cartas de Afonso de Albuquerque. ↩
-
Citino, R. M. (2005). The German Way of War: From the Thirty Years’ War to the Third Reich. University Press of Kansas. ↩
-
Moltke, H. von. (1871). “On Strategy,” in Hughes, D. J. (ed.) (1993). Moltke on the Art of War: Selected Writings. Presidio Press. ↩
-
Clausewitz, C. von. (1832). On War. Book I, Chapter 7, “Friction in War.” ↩
-
Bungay, S. (2011). The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results. Nicholas Brealey. ↩
-
Marquet, L. D. (2012). Turn the Ship Around!: A True Story of Turning Followers into Leaders. Portfolio. ↩ ↩2
-
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. ↩
-
Conway, M. E. (1968). “How Do Committees Invent?” Datamation, 14(4), 28-31. ↩