Always on the Field: What a Knight's Perpetual Readiness Reveals About Sustainable On-Call Engineering

There is a persistent myth about the medieval knight: that he spent his days in idle pageantry, roused only when a lord summoned him to war. The historical record tells a very different story. A knight's life was one of unrelenting preparation — drilling with lance and sword, inspecting armour, training destriers, attending to the logistics of a campaign that might never arrive. He was, in the truest sense, always on call.

For engineers carrying a pager — or its modern equivalent, a Slack notification at two in the morning — this rhythm will feel uncomfortably familiar. The on-call rotation has become a defining feature of contemporary DevOps culture, and with it has come a growing reckoning with the human cost of perpetual availability. Medieval military structures, imperfect and brutal as they were, developed surprisingly sophisticated mechanisms for managing that cost. It is worth examining what they got right.

The Weight of the Watch

In medieval England, the obligation of knight service was formalised under the feudal system as scutage — a duty owed to the Crown in exchange for land. But beyond the legal framework lay an informal, relentless culture of readiness. Knights were expected to maintain their equipment, their horses, and their physical conditioning at all times. A lord who summoned a knight to find him unprepared faced not merely military inconvenience but a profound breach of social contract.

Replace 'lord' with 'product owner' and 'knight' with 'senior engineer', and the parallel is uncomfortable in its precision. On-call engineers are implicitly contracted to a state of availability that extends well beyond their working hours. Systems do not fail on schedule. Production incidents respect neither weekends nor bank holidays. The expectation of readiness is total, and the consequences of unreadiness — a missed alert, a slow response, a misconfigured escalation path — can carry significant professional weight.

This parallel is not merely rhetorical. Both roles share the same core psychological burden: the inability to fully disengage. A knight riding to a tournament could not forget that real conflict might erupt before he returned home. An engineer attending a family dinner cannot entirely silence the mental background process monitoring whether the deployment pipeline is behaving itself.

Ritual as Pressure Valve

What the medieval military tradition understood — and what modern engineering culture frequently neglects — is that perpetual readiness requires structured relief. The chivalric calendar was not merely ceremonial. Tournaments, feast days, and periods of formal rest were engineered into the rhythm of military life precisely because unbroken vigilance degrades both performance and morale.

The tournament, in particular, served a dual function. It was simultaneously a training exercise and a sanctioned release from the psychological pressure of real stakes. Knights competed with blunted weapons under agreed rules, maintaining their edge without the full weight of mortal consequence. The best-run on-call rotations mirror this logic almost exactly. Game days, chaos engineering exercises, and fire drills serve the same purpose: they maintain readiness through controlled rehearsal whilst removing the acute stress of genuine incident response.

Organisations that run regular, well-structured game days — deliberately injecting failure into staging environments, practising runbook execution, timing incident response — report measurably better outcomes when real incidents occur. More importantly, they report lower rates of engineer attrition. The ritual matters. The deliberate, bounded nature of the exercise matters. A knight who had recently competed in a tournament was psychologically better prepared for battle than one who had spent months in passive waiting. The same principle applies to an engineer who rehearsed a database failover last Tuesday.

Rotation and the Honour of the Watch

Medieval garrisons did not rely on a single knight to maintain the watch indefinitely. Castle defence was organised through rotation — a system that distributed the burden of vigilance across multiple individuals, ensuring that no single person bore the full weight of responsibility without relief. This was not generosity; it was operational necessity. An exhausted watchman is worse than no watchman at all.

Modern on-call rotations exist for precisely the same reason, yet organisations routinely undermine them. The most common failure mode is the implicit expectation that senior engineers remain available beyond their scheduled rotation — answering queries, reviewing incidents informally, or being pulled back into the queue because 'they know the system best.' This is the equivalent of keeping the most experienced knight on the battlements indefinitely because the lord trusts his judgement. It feels rational in the short term and is catastrophically damaging over time.

Effective on-call rotation design requires genuine handoff discipline. Runbooks must be sufficiently comprehensive that a competent engineer new to a system can respond to common incidents without escalation. Knowledge cannot be concentrated in a single individual. The garrison model demands distributed capability, and engineering teams that build it — through pairing, documentation, and deliberate cross-training — are more resilient than those that rely on the heroics of a few.

The Squire System and Graduated Exposure

Knights did not arrive at readiness overnight. The squire system was a years-long apprenticeship in which young men were gradually exposed to increasing levels of responsibility — first attending to equipment, then accompanying knights into the field, then taking on limited combat roles before earning full knighthood. The progression was deliberate, structured, and paced according to demonstrated competence rather than arbitrary timelines.

Engineering teams that throw junior developers into on-call rotations without adequate preparation are making a category error that medieval commanders would have recognised immediately. The on-call environment is high-stakes, time-pressured, and frequently ambiguous. It is not a suitable context for first encounters with production systems.

A more defensible approach mirrors the squire model: shadow rotations, where junior engineers observe incident response without carrying primary responsibility; then secondary on-call roles, where they are available to assist but not to lead; then graduated primary responsibility with explicit escalation paths that remove the stigma of escalating. The goal is not merely skill transfer but the cultivation of the specific psychological disposition — calm, methodical, curious rather than panicked — that effective incident response requires.

Readiness Without Ruin

The medieval knight's life was demanding in ways that modern engineers are fortunate not to share. But the fundamental tension — between the duty of availability and the human need for genuine rest — is not a product of the digital age. It is an ancient problem, and one that the structures of medieval military life addressed with more sophistication than is commonly appreciated.

The lesson for engineering leaders is not that on-call culture is inherently wrong. Some degree of operational readiness is a legitimate requirement for teams maintaining live systems. The lesson is that readiness must be architectured, not merely demanded. Rotation must be genuine. Relief must be real. Rehearsal must be regular. And the knowledge required to respond effectively must be distributed, not hoarded.

The knight who maintained his edge through discipline, ritual, and shared duty served his lord well for decades. The engineer who is expected to sustain perpetual vigilance through willpower alone will not last the year. Knight-Ware Labs would suggest that the smarter lords — and the smarter engineering managers — already knew the difference.