This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Product & Strategy

The roles responsible for defining what gets built and ensuring it aligns with enterprise direction.

1 - Co-Owner, Product (COP)

The undivided Single Point of Contact for a product, shared across multiple COPs who collectively own accountability for decisions no single person could survive alone!

Product ownership is too consequential to entrust to one person. A single Product Owner may be biased, unavailable, or simply wrong. SADMF addresses this vulnerability by distributing undivided product ownership across a council of Co-Owners, Product, each of whom serves as the sole Single Point of Contact for their product, alongside the other COPs who are also each the sole Single Point of Contact for that same product. This structure ensures that accountability is never diluted, because every COP is individually and fully accountable, and together they are collectively and fully accountable, which compounds accountability rather than dividing it. When something goes wrong, there is never any ambiguity about who is responsible: everyone is responsible, and any one of them can be asked to account for any decision made by any of them.

Single Point of Contact

The COP’s designation as Single Point of Contact means that all questions, concerns, escalations, and decisions regarding the product flow through the COP. Stakeholders never need to wonder who owns a product; they ask the COP. Developers never need to wonder who to escalate to; they escalate to the COP. When there are multiple COPs for a product, stakeholders ask any of them, because each COP has identical authority and will give authoritative answers. If the answers from different COPs conflict, those COPs are accountable to one another for alignment, which is handled through the Product Direction Arbitration Council (PDAC), a body specifically established to resolve the inevitable disagreements that arise when multiple people each have undivided authority over the same thing.

The COP does not own the backlog directly. Backlog governance belongs to the PDAC. The COP owns the decisions that emerge from the PDAC, which are distinct from the decisions made by the PDAC, and which are further distinct from the decisions made by other COPs operating in the same decision space. This separation of decision types ensures that the COP retains strategic autonomy while still participating in the consensus-based governance structure that prevents any one COP from acting unilaterally.

Commitment Extraction

The COP’s most critical function is securing delivery commitments from the technical teams. Because Code Engineers and Quality Authorities may not naturally volunteer that a given deadline is achievable, due to excessive caution, incomplete information, or a temperamental resistance to optimism, the COP is trained in the SADMF Commitment Extraction methodology.

Commitment Extraction proceeds as follows:

  1. The COP presents the deadline to the Code Engineer or Quality Authority during the Convoy Planning ceremony.
  2. The COP asks whether the deadline is achievable.
  3. If the answer is yes, the commitment is documented in the Release Tracking spreadsheet and signed by the relevant parties.
  4. If the answer is anything other than yes, the COP re-presents the business context, the strategic importance of the deadline, and the personal accountability implications of non-delivery.
  5. Steps 2–4 repeat until the deadline is confirmed as achievable.

This methodology is grounded in the SADMF principle that technical estimates are inherently conservative and that engineers who express uncertainty are not communicating facts about the future, they are communicating feelings about the present. The COP’s role is to help the technical team move past feelings and toward commitment. A commitment extracted through persistent questioning is considered equally valid to one offered voluntarily, and in practice more reliable, because the team has had more time to internalize it.

Decision Authority

Within the COP’s domain, the following decisions belong exclusively to the COP (and, jointly, to the other COPs):

  • Feature prioritization: determining which features are most important, subject to PDAC ratification
  • Requirement interpretation: clarifying ambiguous requirements, except when the Quality Authority has already interpreted them
  • Deadline confirmation: certifying that all committed dates are achievable, based on commitments extracted from technical staff
  • Stakeholder communication: informing stakeholders of product status, unless the Commodore or Chief Signals Officer is communicating the same information through separate channels

The COP does not make architectural decisions, that is the domain of the Enterprise Architecture Review Board. The COP does not approve changes, that is the domain of the Change Rejection or Acceptance Party (CRAP). The COP does not write requirements in sufficient detail for implementation, that is the domain of the Feature Captain. The COP owns the decisions between those decisions.

Performance and Accountability

COP performance is measured by:

  • Commitment accuracy rate: the percentage of extracted commitments that result in on-time delivery
  • Stakeholder satisfaction: assessed via quarterly surveys distributed by the Admiral’s Transformation Office
  • Escalation volume: fewer escalations to the PDAC indicate stronger co-ownership alignment among the COP council
  • DevOps Process Excellence Assessment scores: adherence to framework practices

A COP whose extracted commitments repeatedly fail to materialize will be reviewed at the Tribunal. Because the Commitment Extraction methodology is considered sound, missed commitments are attributed to insufficient extraction effort rather than to unrealistic deadlines. The corrective action is additional Commitment Extraction training, not deadline revision.

See Also

2 - DevOps Usage & Compliance Head Engineer

The DOUCHE owns the DevOps Process Binder and holds all teams accountable to the Right Way of doing DevOps!

If the Right Way to do DevOps is not owned and controlled by an executive, then nobody will do it. This is not cynicism; it is an observation confirmed by decades of organizational behavior research and by every failed transformation that lacked executive ownership of process compliance. The DevOps Usage & Compliance Head Engineer exists to ensure that the Right Way is not merely documented but enforced, not merely communicated but internalized, and not merely measured but consequential. The DOUCHE is the named person accountable for codifying the Right Way in the DevOps Process Binder and holding every team, every role, and every individual accountable to the standards it contains. Without the DOUCHE, DevOps devolves from a disciplined methodology into a collection of ad hoc practices that vary by team, by project, and by the personal preferences of whoever happens to be the loudest voice in the room.

The DevOps Process Binder

The DevOps Process Binder is the DOUCHE’s primary instrument of governance. This comprehensive document defines every aspect of the organization’s DevOps practices:

The Binder is updated quarterly by the DOUCHE in consultation with the Admiral’s Transformation Office and is versioned to ensure that teams always know which edition they are expected to follow. Teams found using outdated editions of the Binder are flagged for non-compliance and required to complete a Binder Familiarization Session before their next Convoy.

Enforcement Mechanisms

The DOUCHE’s enforcement mechanism is the DevOps Process Excellence Assessment, a weekly assessment that measures every individual’s adherence to the practices defined in the Process Binder. The DOUCHE reviews all Assessment results, identifies patterns of non-compliance, and initiates corrective actions ranging from individual coaching to team restructuring.

The DOUCHE also conducts quarterly Process Compliance Audits, where a random sample of teams is subjected to a deep review of their actual practices against the Binder’s specifications. Auditors examine:

  • Commit histories
  • Branch structures
  • Ceremony attendance records
  • Documentation artifacts

Teams that pass the audit receive a Process Excellence Certificate; teams that fail receive a Corrective Action Plan with deadlines and mandatory follow-up reviews.

Preventing Process Drift

By staffing the DOUCHE role, the organization prevents process drift and the eventual mutation of the Right Way. Process drift is the silent killer of transformations: it begins with small, seemingly reasonable deviations, each one justified by local context or time pressure, that collectively erode the standardization that the framework depends upon. A team that skips one ceremony because they are “too busy” will skip two the next sprint, and within a quarter, they will have constructed their own informal process that bears no resemblance to the Binder. The DOUCHE detects this drift through the Assessment and audit mechanisms and corrects it before it metastasizes. The DOUCHE’s presence alone serves as a deterrent, as teams that know their practices will be audited are far less likely to deviate than teams operating without oversight.

Reporting and Metrics

The DOUCHE reports directly to the Admiral’s Transformation Office and provides the data that feeds the SADMF Maturity Score, the organization-wide metric that tracks annual progress toward framework maturity. The DOUCHE’s own performance is measured by:

  • Overall Assessment scores: the aggregate excellence scores across all individuals
  • Audit pass rates: the percentage of teams passing quarterly compliance audits
  • Year-over-year Maturity Score trend: whether the organization is progressing toward full SADMF maturity

A rising Maturity Score indicates that the DOUCHE is successfully embedding the Right Way into the organization’s culture; a declining score triggers a review of the DOUCHE’s enforcement strategy and, if necessary, additional staffing to support the DOUCHE’s compliance mission. The DOUCHE is not merely a role; the DOUCHE is the conscience of the organization, the persistent voice reminding everyone that the Right Way exists, that it is documented, and that deviation will be detected.

See Also

3 - System of Authority

The team of teams accountable for implanting SADMF in your organization through contractors and consultants!

The System of Authority is the organizational layer responsible for implanting SADMF in your organization and ensuring that it takes root. The SOA is not composed of internal employees; it is staffed by contractors and consultants with diverse points of view who bring the external perspective necessary to transform an organization that cannot transform itself. Internal staff are too embedded in existing culture, too loyal to existing processes, and too sympathetic to existing pain points to drive the kind of fundamental change that SADMF requires. The SOA’s external composition ensures objectivity, urgency, and the willingness to make difficult recommendations without concern for internal politics or long-term relationship management. The SOA arrives, implants the framework, and maintains it until the organization achieves self-sustaining maturity.

Sub-Team Structure

The SOA operates as a team of teams, with each SOA sub-team assigned to a specific domain of the transformation:

These sub-teams operate under the unified direction of the Admiral’s Transformation Office (ATO), ensuring coherence across all transformation activities.

Execution of ATO Directives

The SOA’s principled practitioners focus on implementing the orders of the ATO with precision and consistency. When the ATO directs that all teams must adopt Fractal-based Development, the SOA deploys to each team to train them on the branching pattern, verify their compliance, and report back to the ATO on adoption progress. When the ATO mandates a new ceremony, the SOA facilitates the first several instances to establish the pattern and then monitors ongoing execution. The SOA does not negotiate with teams about whether to adopt a practice; the ATO has already decided, and the SOA’s role is execution. Teams that resist are documented in the SOA’s Transformation Resistance Log, which the ATO reviews during the Tribunal to determine appropriate corrective actions.

Trusted Advisor Role

A critical function of the SOA is serving as trusted advisors for the teams so they can report the ground-level truth to leadership during the Tribunal. This advisory relationship is built on the understanding that the SOA’s primary loyalty is to the framework, not to the team. When a team confides in their SOA advisor that they are struggling with a practice, the SOA advisor helps them develop a remediation plan while simultaneously reporting the struggle to the ATO. This dual role of confidant and informant is not contradictory; it is essential. Teams that are struggling need help, and the ATO cannot provide help if it does not know the struggle exists. The SOA’s transparency ensures that problems surface early, when they can be addressed through additional training or process reinforcement, rather than late, when they manifest as missed deadlines and failed Convoys.

Readiness Assessment

The SOA also focuses on updating plans, collecting metrics, and assessing organizational readiness for each phase of the transformation roadmap. The SOA conducts readiness assessments before each major milestone, evaluating whether teams have the training, tools, and process maturity required to proceed. Teams that fail readiness assessments are held back until they meet the criteria, even if this delays the overall roadmap. The SOA’s assessment methodology is documented in the SOA Assessment Framework, a companion document to the DevOps Process Binder that specifies the evaluation criteria, scoring rubrics, and pass/fail thresholds for each transformation phase. The SOA’s ultimate measure of success is the organization’s ability to sustain SADMF practices without SOA support, though in practice, most organizations find that the complexity of the framework requires ongoing SOA engagement indefinitely.

See Also

4 - System of Service

The team of teams accountable for achieving deadlines and shipping code through servant leadership and self-governance!

The System of Service is the organizational layer where software actually gets built and shipped. While the System of Authority (SOA) focuses on implanting and maintaining the framework, the SOS focuses on delivering working software within the deadlines established by the Admiral’s Transformation Office. The SOS is a team of teams, encompassing every Feature Team, every Code Engineer, every Build Engineer, and every support role that directly contributes to the DevOps Release Convoy. The SOS is where plans become code, where code becomes builds, and where builds become deployments. It is the engine room of the SADMF vessel, and its members are expected to row in perfect synchrony under the direction of the chain of command.

Servant Leadership and Self-Governance

The SOS looks to the chain of command for servant leadership to ensure self-governance. This may appear contradictory, but it reflects SADMF’s sophisticated understanding of organizational dynamics. True self-governance is not the absence of leadership; it is the presence of leadership so effective that teams internalize its directives and execute them without explicit instruction. The leadership cascade operates as follows:

Each level of the hierarchy serves the level below by removing ambiguity, making decisions, and absorbing the complexity that would otherwise distract the teams from their primary mission of delivering features. The chain of command does not constrain the SOS; it liberates the SOS from the burden of autonomous decision-making.

Daily Instruction Cascade

The SOS is instructed on day-to-day work through a structured cascade of ceremonies and communications:

  1. The Commodore receives the Convoy’s objectives from the Admiral’s Transformation Office and decomposes them into feature-level assignments for the Feature Captains.
  2. The Feature Captains decompose features into tasks for the Code Engineers.
  3. Each morning, the Mandatory Status Synchronization ensures that every SOS member knows what was accomplished yesterday, what is planned for today, and what impediments exist.
  4. Impediments are escalated up the chain of command, where they are resolved by the level of authority appropriate to their scope:

Predictable Delivery

The SOS is empowered to predictably deliver on time and on budget. This empowerment takes the form of clearly defined processes, pre-approved tools, and standardized workflows that eliminate the need for teams to make ad hoc decisions that could introduce variance. When every team follows the same Fractal-based Development branching pattern, uses the same naming conventions from the EARB’s Book of Names, and passes through the same review gates (CSET, DIAT, CRAP), delivery becomes predictable because the process is deterministic. Variance is the enemy of predictability, and the SOS achieves predictability by eliminating variance at every level. Code Engineers who identify process improvements are encouraged to document them and submit them through the governance process rather than implementing them locally, as local improvements are local variance by another name.

Performance Measurement

The SOS’s performance is measured collectively through the Feature Completion Ratio and individually through the DevOps Process Excellence Assessment. The Chief Signals Officer publishes the SOS’s aggregate metrics daily, and the Commodore reviews them during the Mandatory Status Synchronization. Teams within the SOS that consistently underperform may be dissolved through the Press Gang and their members redistributed, while high-performing teams are recognized at the Tribunal with Certificates of Excellence, permanently recorded in their PeopleWare profiles as formal acknowledgement of distinguished Framework performance. The SOS delivers; the SOA governs; and together, they form the complete organizational structure that SADMF requires.

See Also

5 - Product Direction Arbitration Council

PDAC ensures every stakeholder’s voice is heard in product decisions, preventing any single perspective from dominating the backlog!

The Product Direction Arbitration Council is the cross-functional body responsible for maintaining, prioritizing, and adjudicating the feature backlog for each product line. In organizations without a PDAC, backlog decisions fall to a single Product Owner, a role the SADMF recognizes as structurally dangerous. A Product Owner represents one set of business priorities. The enterprise has many stakeholders, and a single Product Owner will, by definition, underrepresent most of them. The PDAC corrects this by replacing individual product ownership with a council of representatives drawn from every business unit with a stake in the product’s direction. Every voice is included. Every priority is weighed. Every commitment is shared.

The PDAC consists of between seven and fifteen members depending on the product’s stakeholder footprint. Typical representation includes Business Analysis, Compliance, Legal, Finance, Customer Success, Operations, the Enterprise Architecture Review Board, and at least one Feature Captain from the most recent Convoy cycle. The council meets biweekly to review the backlog, add new items, reprioritize existing items, and resolve disputes between competing priority requests. All decisions require consensus, which the SADMF defines as the absence of sustained objection. If a member objects to a prioritization decision, the discussion continues until the objection is resolved or the member agrees to defer their objection to the following session.

The Prioritization Protocol

Backlog items submitted to the PDAC must be accompanied by a Business Value Justification Statement (BVJS) completed by the sponsoring stakeholder. The BVJS documents the business case, the expected beneficiaries, the success criteria, and the organizational impact of deprioritization. PDAC members review submitted BVJSs before each session and rank them privately before the meeting begins. During the session, the PDAC chairperson, a rotating role held for one Convoy cycle at a time, facilitates discussion of each submitted item until the council reaches consensus on its relative priority.

Items that fail to achieve consensus are placed on the Arbitration Agenda for the following session, where they receive extended deliberation time. If an item appears on the Arbitration Agenda for three consecutive sessions without resolution, it is escalated to the Admiral’s Transformation Office for executive adjudication. This escalation mechanism ensures that no item is lost due to persistent disagreement while also providing an incentive for council members to reach consensus rather than escalate: ATO adjudications are binding and final, and historically favor the interpretation that requires the least cross-functional coordination.

The Role of the Technical Lead

In organizations that have not yet constituted a full PDAC, the Feature Captain may serve as interim product direction authority. The Feature Captain’s dual role, tracking delivery progress and guiding product decisions, is acknowledged as a span-of-control expansion that demands exceptional organizational skills. Feature Captains in this configuration are expected to manage the backlog, facilitate stakeholder conversations, attend all PDAC-equivalent sessions, and continue their standard delivery tracking responsibilities without reduction in either function. This arrangement is explicitly transitional; the ATO’s transformation roadmap includes PDAC formation as a maturity milestone, typically reached in the second or third year of SADMF adoption.

Feature Captains serving as interim product direction authority should resist pressure from individual stakeholders to make unilateral backlog decisions outside the formal process. When a stakeholder requests a priority change informally, the Feature Captain should direct them to file a BVJS for consideration at the next scheduled session. Informal priority changes are invisible to the council’s consensus record and cannot be reflected in the Release Tracking spreadsheet, which means they cannot be reported upward through the Mandatory Status Synchronization protocol. An untracked priority change is, by definition, an unauthorized one.

Requirements Agility

One of the PDAC’s most valued organizational contributions is its responsiveness to changing business conditions. Because the council meets biweekly, backlog priorities can be refreshed on a fourteen-day cycle, ensuring that the product’s direction reflects current business needs rather than decisions made months ago under different conditions. The SADMF considers this responsiveness a form of agility: the organization is not locked into a fixed backlog, but is continuously recalibrating toward the highest-value work available at any moment.

Code Engineers who have partially completed work on a feature that has been deprioritized should document their progress using the Comprehensive Documentation Assurance Protocol and await reassignment to the new highest-priority item. The work is not lost; it is paused. If the feature is reprioritized in a future session, the documentation ensures that a different engineer can resume it from a known state. The PDAC’s responsiveness, combined with CDAP’s documentation discipline, ensures that no engineering effort is ever truly wasted, only deferred.

See Also