Oaths, Reputation, and the Distributed Team: A Practical Code of Conduct for Remote Engineering
The problem of managing people you cannot see is not new. It is, in fact, one of the oldest governance challenges in human history. A medieval lord whose knights were dispersed across multiple manors, conducting operations in his name without direct supervision, faced a coordination and accountability problem that is structurally identical to the one facing a lead engineer whose team spans London, Glasgow, and Warsaw.
The medieval solution was not surveillance. It was not a detailed process manual. It was a system of honour — a combination of explicit commitments, earned reputation, and public accountability that created genuine behavioural alignment without requiring a watcher at every gate.
The modern equivalent is worth studying carefully.
Why Watchers Don't Work
Before examining what does work, it is useful to be clear about why the surveillance instinct fails. The managerial response to distributed teams is often to increase visibility — more status updates, more synchronous check-ins, more project management tooling, more dashboards tracking individual output. This approach treats the problem as one of information asymmetry: if the manager could see what everyone was doing at all times, accountability would follow automatically.
The medieval experience suggests otherwise. Lords who relied primarily on surveillance to manage dispersed retainers found that it produced compliance rather than commitment — behaviour that satisfied the letter of observation while undermining its spirit. The knights who performed reliably across distance were those who had internalised a code, not those who feared being caught.
Psychological safety research in modern organisational contexts reaches identical conclusions. Teams whose members act from genuine commitment to shared standards consistently outperform those whose behaviour is driven primarily by monitoring. The mechanism is different; the finding is the same.
The Oath as Onboarding Protocol
The knightly oath was not a formality. It was a public, witnessed articulation of specific commitments — to a lord, to a code, to fellow knights — that established the terms of the relationship before any test of it arose. The public nature was essential: the oath was made before witnesses who would remember it, and whose memory constituted a form of social accountability.
For distributed engineering teams, this maps directly onto the onboarding process — and most onboarding processes squander the opportunity entirely.
A new engineer joining a distributed team typically receives a technical setup guide, an introduction to the codebase, and a series of introductory calls. What they rarely receive is an explicit articulation of the team's commitments — to code quality, to each other, to the people who depend on the systems they build — and an opportunity to publicly affirm their own.
Practical implementation: Introduce a structured team charter session for every new team member. This is not a values document to be read and acknowledged. It is a facilitated conversation in which the team's actual working agreements — how code reviews are conducted, how disagreements are resolved, what constitutes acceptable response times for asynchronous communication — are articulated explicitly, and the new member is invited to contribute to and affirm them. The session should be recorded or minuted. The commitments should be documented. The public, witnessed character of the medieval oath is the point.
Earned Titles and the Architecture of Reputation
The medieval honour system was explicitly hierarchical, but the hierarchy was earned rather than assigned. A knight's reputation was built through demonstrated performance over time, and that reputation had practical consequences — it determined who sought your service, whose alliances were available to you, and what responsibilities you were trusted with next.
Modern flat team structures often deliberately suppress this dynamic in the name of equality, producing an environment where demonstrated excellence has no visible consequence and where the engineer who consistently produces careful, well-considered work is structurally indistinguishable from one who does not.
This is not equality. It is a failure to create the feedback loops that allow reputation to function as a behavioural signal.
Practical implementation: Develop an explicit recognition architecture that acknowledges specific contributions publicly and permanently. This does not require formal titles or hierarchy. It requires that when an engineer makes a decision that improves the system's resilience, or produces documentation that genuinely helps the team, or mentors a colleague through a difficult problem, that contribution is named, attributed, and remembered. A curated team changelog — distinct from the git log — that records not just what changed but who contributed meaningfully to decisions, is one mechanism. Regular team retrospectives that include explicit acknowledgement of specific contributions, documented and visible, are another.
The goal is that reputation becomes legible within the team. People should be able to point to a record of someone's contributions and judgement, not merely assert a vague sense of their quality.
The Code of Conduct as Operational Document
The chivalric code was not aspirational. It was operational. Knights knew precisely what the code required of them in specific situations — how disputes were to be conducted, what constituted a breach of honour, how disagreements with peers were to be escalated. The code provided a decision framework for situations where direct guidance was unavailable.
Most modern team codes of conduct are aspirational: be respectful, communicate openly, support your colleagues. These are not without value, but they provide no operational guidance when a specific situation arises. What does respectful disagreement look like when two engineers have fundamentally different views on an architectural decision? How should a team member respond when they believe a colleague has made a commitment they are not going to honour?
Practical implementation: Develop a team operating agreement that addresses specific scenarios rather than abstract values. Include explicit protocols for:
- How technical disagreements are escalated when discussion reaches an impasse
- What constitutes a reasonable response time for code review requests, and what the team member should do if that expectation is not met
- How commitments made in planning sessions are tracked, and what the expected communication is when a commitment is at risk
- How a team member raises a concern about a colleague's conduct without it becoming a personal conflict
These are uncomfortable to write because they require the team to acknowledge that disagreements and failures will occur. That acknowledgement is precisely what makes the document useful.
Rituals of Accountability
The medieval honour system was maintained through ritual — the public ceremony of oath-taking, the formal acknowledgement of service, the structured process by which disputes were heard and resolved. Ritual is not decoration. It is the mechanism by which shared commitments are periodically renewed and made visible.
Distributed teams that lack ritual tend to allow their operating agreements to drift. The commitments made at onboarding become historical artefacts. The team charter becomes a document that nobody opens.
Practical implementation: Build regular, structured moments of collective accountability into the team calendar. A quarterly review of the team's operating agreement — not to audit compliance, but to ask whether the agreement still reflects how the team wants to work — maintains the living quality of the commitments. An annual retrospective that explicitly addresses team culture alongside technical process serves the same function. These rituals should have a defined format, a consistent cadence, and a permanent record.
The Trust Architecture
The medieval knight operated effectively across distance not because they were watched, but because they had made public commitments, built a reputation that mattered to them, and internalised a code that provided operational guidance when direct supervision was unavailable. The system worked because it aligned incentives with genuine commitment rather than compliance.
Distributed engineering teams that achieve genuine psychological safety and consistent accountability tend to have built something structurally similar — not through surveillance or process overhead, but through explicit commitments, visible reputation, and operational codes that address real situations rather than abstract ideals.
The armour has changed. The underlying architecture of trust has not.