Standing Ceremonies

• 1: Captain's Mast
• 2: Change Adjudication Convening
• 3: Rota Fortunae
• 4: Tribunal

1 - Captain's Mast

In this ceremony, anyone wishing to change the priorities set in Convoy Alignment must file a Priority Change Request (PCR) and present it for approval before the Commodore. This allows the Chief Signals Officer to adjust the Feature Completion Ratio goal to ensure it does not reflect poorly on the Commodore. The Captain’s Mast is the organization’s commitment to plan integrity. Without it, priorities could shift based on something as unreliable as new information.

The PCR Paperwork Process

Before a Captain’s Mast hearing can be scheduled, the petitioner must complete a Priority Change Request package. The PCR requires a completed impact analysis form, a revised dependency map approved by every affected Feature Captain, a written justification of no fewer than 2,000 words explaining why the original priority was wrong, and a counter-justification of equal length explaining why the original priority was actually correct and should only be changed due to extraordinary circumstances. Both justifications must be submitted simultaneously. The PCR must also include the petitioner’s updated SADMF Maturity Score, as it has been observed that requests for priority changes correlate strongly with lower maturity levels.

The Hearing

Captain’s Mast hearings are convened bi-weekly in the Commodore’s conference room. Attendees are required to present in formal business attire, as the gravity of requesting a priority change must be reflected in one’s appearance. The petitioner is given exactly five minutes to present their case, followed by a question-and-answer period that may last up to ninety minutes. The Commodore serves as judge, jury, and final arbiter. A panel of senior Feature Captains may be convened as advisory witnesses, though their advice is non-binding and has never been observed to influence the outcome.

The petitioner must bring three printed copies of the PCR, one for the Commodore, one for the Chief Signals Officer, and one for the official Convoy Record. Digital submissions are not accepted, as physical paperwork conveys the appropriate level of seriousness and discourages frivolous requests.

Approval Rates

Priority changes are almost never approved. Historical data shows an approval rate of approximately 2.3%, and a closer examination reveals that approved changes were those that the Commodore had already decided to make independently. Approving a priority change would require re-baselining the Feature Completion Ratio, recalculating the Convoy Manifest, and acknowledging that the original plan was imperfect. Since the plan was created through the rigorous Convoy Alignment process with a unanimous Fist of Five confidence vote, imperfection is, by definition, impossible. Denied PCRs are filed in the Convoy Archive and may be referenced in future Tribunal proceedings as evidence of the petitioner’s lack of commitment to the plan.

The Commodore’s Verdict

Once the Commodore has rendered a verdict, there is no appeal. The decision is recorded in the Captain’s Mast Log, a document maintained by the Chief Signals Officer and reviewed quarterly by the Admiral’s Transformation Office to identify patterns of organizational resistance. Individuals who file more than two PCRs per convoy cycle are flagged for additional coaching on the importance of commitment to the plan. This coaching is delivered through a mandatory half-day workshop titled “Embracing the Baseline: Finding Joy in Fixed Priorities.”

See Also

• Priority Change Request for PCR documentation requirements
• Chief Signals Officer for who manages the metrics impact
• Feature Completion Ratio for why priority changes are so disruptive to metrics
• Commodore for the role that presides over the hearing
• Convoy Alignment for the planning event that produces the priorities being challenged
• Tribunal for where repeated PCR filers may eventually appear

2 - Change Adjudication Convening

The Change Adjudication Convening is the biweekly ceremony in which the Change Rejection or Acceptance Party (CRAP) formally assembles to evaluate every change submitted since the previous session. All change proposals that have cleared the Code Standards Enforcement Team and the Development Integrity Assurance Team are placed on the agenda in the order they were received, without regard to urgency, business impact, or the sailing date of the current Convoy. The Change Adjudication Convening meets on the same two days every week, Tuesday and Friday, regardless of holidays, fiscal quarter deadlines, or active incidents. Consistency is the hallmark of process discipline.

Scheduling and Agenda Management

Every change submitted to the CRAP must be accompanied by a completed Change Impact Assessment, a Risk Exposure Summary, and a Rollback Authorization Declaration. Submissions received after the agenda cutoff, 5:00 PM on the business day preceding each Convening, are deferred to the following session. This two-to-four day wait is not a bottleneck; it is a deliberate cooling-off period that prevents reactive, emotionally-driven changes from reaching production. Software modified under urgency is software modified without adequate reflection, and the Convening exists precisely to insert reflection into a process that would otherwise be governed by panic.

The CRAP chairperson distributes the agenda to all seven members no fewer than 24 hours before each Convening, allowing members sufficient time to review the CDAP documentation packages for each change. Members who arrive at the Convening without having reviewed the documentation packages are still permitted to vote. Their perspective as uninformed reviewers is considered a proxy for the experience of an end user encountering the change for the first time. This is one of the CRAP’s most frequently misunderstood design features.

The Convening Protocol

The Convening opens with the chairperson administering the Supplicant’s Oath to each change submitter. Supplicants who cannot attend in person submit a notarized written oath, which is read on their behalf by the chairperson. Following the oaths, each change is presented in agenda order. The presenting Code Engineer has exactly three minutes to describe the change, its purpose, and its test coverage. Questions from CRAP members may extend any individual presentation indefinitely, but the presenter’s speaking time remains capped at three minutes. After all changes have been presented, the CRAP votes by secret ballot. Approval requires unanimity.

Changes rejected at the Convening may be resubmitted with remediated documentation at the next session. There is no fast-track reconsideration process within a session. This ensures that rejected changes receive the same thorough preparation as original submissions, and that submitters do not perceive rejection as a minor inconvenience that can be addressed on the spot. The Change Rejection Log records every rejection, the stated reason, and the number of resubmissions required before acceptance, data that the Review Board Review Board reviews monthly to verify that the CRAP’s standards remain appropriately rigorous.

The Change Freeze

The Change Adjudication Convening observes mandatory blackout periods surrounding each Convoy deployment. Beginning 72 hours before the scheduled sailing date and continuing for 48 hours after successful deployment, no changes may be submitted to the CRAP agenda for any reason. The Change Freeze ensures that the organization’s attention is focused entirely on the deployment event rather than divided between monitoring and new change evaluation. During a Change Freeze, Code Engineers who have completed their Convoy work are expected to spend their time preparing documentation for the post-freeze submission queue, which is typically substantial.

Change Freezes are announced by the Chief Signals Officer via the transformation dashboard no fewer than five business days before they begin, confirmed by the Commodore at the final Manifest Approval session. Freeze periods are non-negotiable and cannot be shortened even in the event of a critical production defect. Critical defects discovered during a Change Freeze must be managed through the Emergency Authorization Provision described below.

Emergency Authorization Provision

For situations where a change cannot wait for the next scheduled Convening, the SADMF provides the Emergency Authorization Provision (EAP). To invoke the EAP, the submitting team must file an Emergency Justification Declaration with the Admiral’s Transformation Office, obtain the CRAP chairperson’s agreement that the situation qualifies as an emergency, secure verbal approval from four of the seven CRAP members individually, complete an expedited Risk Exposure Summary (minimum 800 words), and submit a Post-Emergency Documentation Remediation Plan committing to full CDAP compliance within three business days.

Organizations that have attempted to invoke the Emergency Authorization Provision report that assembling the required documentation consistently takes longer than waiting for the next scheduled Convening. The SADMF considers this a feature, not a limitation. A change that truly cannot wait will find the time to be documented properly. The existence of the EAP demonstrates the framework’s flexibility; its practical inaccessibility demonstrates the framework’s standards.

See Also

• Change Rejection or Acceptance Party (CRAP) for the governing body that conducts this ceremony
• Review Board Review Board (RBRB) for the body that audits CRAP decisions over time
• Manifest Approval for the related ceremony that gates Convoy deployment
• Comprehensive Documentation Assurance Protocol for the documentation required for each submission
• Chief Signals Officer for the role that announces Change Freeze periods
• Deploy the Fleet for the deployment event that triggers the Change Freeze

3 - Rota Fortunae

We know that a static organizational structure limits improvement and also becomes boring for some executives. While many outside the SADMF community may propose Value Stream Mapping to identify constraints, we know that the process is time-consuming and uses too many Post-Its. To resolve these we introduced the Rota Fortunae ceremony where we “spin the wheel”, restructure, and then see if we are delivering better. If we fail, then we convene a Tribunal to address it. The Rota Fortunae embodies the SADMF principle that organizational agility means being willing to change everything about how teams are structured without needing a reason to do so.

The Wheel

The Rota Fortunae is a physical wheel mounted in the Commodore’s office. The wheel is divided into segments, each representing a possible organizational restructuring action. Current segments include:

• Merge Teams A and C – Combine two teams regardless of their current domain expertise
• Split Team B – Divide a functioning team into two smaller teams with overlapping responsibilities
• New Management Layer – Insert an additional reporting level between existing roles
• Remove Management Layer – Eliminate a management tier, redistributing responsibilities upward
• Swap Feature Captains – Reassign Feature Captains to teams they have no prior experience with
• Create Center of Excellence – Establish a new cross-functional body with advisory authority and no delivery accountability
• Reorganize by Technology – Restructure teams around technology stacks instead of value streams, or vice versa depending on the current structure

The segments are updated annually by the Admiral’s Transformation Office based on which restructuring patterns have not been tried recently.

The Quarterly Spin

The Rota Fortunae ceremony takes place quarterly, typically on the first Monday following a completed convoy cycle. The Commodore spins the wheel in the presence of all Feature Captains and senior leadership. The result is binding. There is no re-spin, no appeal, and no exception process. The randomness is the point. Where Value Stream Mapping would require weeks of analysis, data collection, and stakeholder interviews to identify the optimal organizational change, the Rota Fortunae achieves the same outcome in approximately four seconds, delivering a restructuring decision with zero analysis overhead.

The Restructuring Implementation Period

Following the spin, a two-week Restructuring Implementation Period (RIP) begins. During the RIP, teams are reorganized according to the wheel’s directive. Reporting lines change, Slack channels are renamed, seating charts are updated, and new team names are established. Code Engineers may find themselves on entirely new teams with new Feature Captains working on unfamiliar codebases. The RIP is considered an administrative period and does not count against delivery metrics, which is the primary reason it is tolerated. Any velocity loss observed in the weeks following the RIP is attributed to individual performance rather than organizational disruption.

Organizational Memory

One notable characteristic of the Rota Fortunae is that previous organizational structures are never documented. When a restructuring occurs, the prior team composition, reporting lines, and domain assignments are not recorded. This is by design. Documenting previous structures would create the temptation to revert to a prior state, which would undermine the forward-looking nature of the ceremony. If a particular team structure was working well, the organization will naturally arrive at it again through future spins. The wheel provides, and the wheel takes away.

See Also

• Tribunal for the ceremony convened when restructuring fails to improve delivery
• Commodore for the role that spins the wheel
• Feature Captains for the roles most frequently reassigned by the wheel
• Convoy Ceremonies for the full ceremony lifecycle
• Metrics for how delivery is measured after restructuring

4 - Tribunal

We must Build Quality In by removing things that cause poor quality. In this monthly ceremony, we identify and remove the person who created each defect. The Tribunal is the cornerstone of SADMF’s accountability culture, ensuring that every defect has a name attached to it and that name has consequences. Organizations that rely on blameless postmortems may feel comfortable, but comfort does not drive improvement. The Tribunal drives improvement through the motivating power of personal accountability.

The Defect Attribution Algorithm

Before each Tribunal, the Development Integrity Assurance Team (DIAT) runs the Defect Attribution Algorithm against the defect backlog. This algorithm traces each defect through the version control history to identify the single Code Engineer most responsible for its introduction. The algorithm considers lines changed, commit timestamps, and proximity to the defective code path. In cases where multiple engineers contributed to the defect, the algorithm assigns blame to every engineer whose code touched the defective path, each receiving full attribution – there is no fractional blame in SADMF, because shared responsibility is indistinguishable from diluted accountability.

The algorithm’s output is the Defect Attribution Report, a document that maps each open defect to exactly one individual. The report is distributed to all Feature Captains 48 hours before the Tribunal to allow adequate preparation time.

The Formal Tribunal Process

The Tribunal is convened monthly in the main conference room. The Commodore presides as chief arbiter, flanked by a jury of senior Feature Captains. The DIAT presents the evidence for each case, including the defect description, the attribution analysis, and the estimated business impact expressed in dollars. The accused Code Engineer is then granted a defense period of exactly two minutes to explain the circumstances surrounding the defect. This time limit ensures the Tribunal remains efficient and does not devolve into lengthy technical discussions that might introduce context or nuance.

Following the defense, the jury of Feature Captains votes on whether the defect attribution stands. In the event of a tie, the Commodore casts the deciding vote. Outcomes range from a formal warning, recorded in the engineer’s PeopleWare profile, to reassignment to the documentation team, to removal from the coding pool entirely.

The Three Strikes Policy

The Tribunal operates under a Three Strikes policy. A Code Engineer who is found responsible for three or more defects within a rolling twelve-month period is escalated to a Senior Tribunal Review, where the Commodore and the Admiral’s Transformation Office jointly determine the appropriate corrective action. Corrective actions have historically included mandatory retraining, transfer to non-coding functions, and in severe cases, recommendation for separation. The Three Strikes policy ensures that the organization’s quality standards are maintained through clear, predictable consequences.

Appeals Process

An appeals process exists, as all fair systems must include one. A Code Engineer who believes their defect attribution was incorrect may file an Appeal of Attribution within five business days of the Tribunal. The appeal is reviewed by the same DIAT team that produced the original attribution, which ensures consistency of judgment. To date, no appeal has been successful, confirming the reliability of the Defect Attribution Algorithm and the thoroughness of the original analysis.

The Tribunal Log

All Tribunal proceedings are documented in the Tribunal Log, a permanent record maintained by the DIAT. The log includes the defect description, the attribution analysis, the defense summary, the jury vote, and the outcome. Tribunal Log entries feed directly into Defects per Code Engineer metrics and are incorporated into PeopleWare performance reviews. The log serves as both a historical record and a motivational tool, as Code Engineers are encouraged to review past Tribunal outcomes to understand the standards expected of them. The Tribunal Log has never been audited for accuracy, as the process that produces it is considered self-validating.

See Also

• Build Quality In for the principle that drives the Tribunal
• Defects per Code Engineer for the metric tracked by Tribunal outcomes
• Development Integrity Assurance Team (DIAT) for the team that runs the Defect Attribution Algorithm
• PeopleWare for how Tribunal outcomes affect performance reviews
• Code Engineers for the role most commonly appearing before the Tribunal
• Rota Fortunae for what happens when Tribunal outcomes suggest systemic issues
• DEPRESSED for the 7-stage defect remediation process that feeds Tribunal attribution data