Engineering is Collaborative
The best engineering is a team output, not a solo act.
Overview
Reviews, pairing and shared ownership produce better systems than individual heroics. We optimise for the team's throughput and learning, not personal cleverness.
Why
This is the principle with the least support from the platform work behind AZOTH, and it is worth saying so plainly rather than dressing the gap. Its real evidence comes from a multi-team quality process, where structured gates and shared review measurably changed outcomes. The platform projects were built largely alone, and there the same function had to be performed by artifacts instead of people: written decisions, recorded reasoning, and reviews conducted against your own work at enough distance to be honest. That substitute is worth describing because it turns out to carry most of the value. What collaboration actually enforces is that reasoning leaves one person's head. A journal that records what a change taught, including that it taught nothing, does that. So does a correction left visible instead of edited away.
Standard
Review is a gate on the work, not a courtesy to its author. Feedback is specific and actionable, and escalation has a defined path and a timebox. Where there is no second person, create the second perspective deliberately: place a subsystem next to your best work and ask why they differ; write the decision down and read it later as a stranger would. The output of collaboration is a shared record, not a shared memory. A record that shows its own corrections is worth more than one that shows only conclusions.
What This Forbids
- Review treated as a formality rather than a gate
- Decisions that exist only in one person's memory
- Escalation with no defined path or timebox
- Quietly rewriting a record so that only the conclusion survives
Examples
- A pre-development readiness gate that surfaced missing requirements, environments and dependencies before implementation started, with a documented case where roughly three days of preparation would have prevented six weeks of disruption.
- A sign-off gate with explicit accountability conditions: responsibility for defects found later is accepted only where there was sufficient access and time to test, and the event is otherwise recorded as a process deviation rather than argued about afterwards.
- An engineering journal whose entries record what each change taught, including entries stating that it taught nothing, and one entry that visibly corrects itself the same day rather than being quietly rewritten.
Counter Examples
- A codebase that invented nearly every pattern in its family and recorded none of the reasoning. Nothing was shared because nothing was written, and its lessons had to be reconstructed by other projects months later.
- An adoption figure repeated across documents that turned out to be overstated by an order of magnitude. Nobody had checked it, and the inflated number made the real problem invisible.
Lessons Learned
- Recorded honestly: most of the engineering behind AZOTH was done alone. This principle's strongest evidence comes from the team quality work, and the solo form, artifacts standing in for people, is a substitute rather than an equivalent.
- Even strong trust between experienced engineers needs procedural guardrails. The failures that got through were compound, and each individual step looked reasonable.
- A record that shows its own corrections is worth more than one that shows only conclusions, because the correction is where the reasoning becomes visible.
Learned From
Related Documents· 4
Referenced By· 2
Version History
- v0.1.0
Principle established with placeholder content.
- v0.2.0weakened
Marked weakened: the four platform projects were built largely alone and supplied little direct support. Its evidence comes from the team quality work, and the solo substitute is now recorded as a substitute rather than an equivalent.