Brainforge Knowledge

delivery-folder-restructure-and-operating-model-plan-2026

15 min read

Delivery folder restructure and operating model plan (2026)

Status: Active
Owner: Delivery / leadership

Purpose

Rework knowledge/delivery/ into a clearer, longer-form operating system for delivery without multiplying files or over-optimizing around the HTML page.

This plan follows a simple model:

  1. Standards — the floor
  2. Checkpoints — how the floor is enforced
  3. Roles — how CSO, SL, IC, and Head of Delivery participate
  4. Lifecycle / systems of record — how work moves and how truth is maintained
  5. Coaching / excellence — what great looks like
  6. Analogies — teaching layer throughout, not the primary structure

The desired document pattern for major chapters is:

  • Literal statement — what the standard/checkpoint is
  • Why it exists — short explanation
  • Analogy — one line or two from the strongest matching domain
  • What good looks like — concrete behavior

Core decisions

1. Longer canonical docs, fewer clicks

We prefer one stronger, longer canonical document per major folder/topic over many small files. Subordinate docs should support the canonical doc, not compete with it.

2. Separate floor, enforcement, and excellence

The system should distinguish between:

  • Standards — the minimum bar
  • Checkpoints — how the bar is enforced
  • Coaching / excellence — how people level up beyond the minimum

These should not be flattened into one undifferentiated list.

3. Keep policy literal; use analogies as the teaching layer

The operating model should remain literal and operational. Analogies should be used to explain why the system works and help people remember it under pressure, but should not become the organizing structure of the docs.

4. Role detail comes after standards and checkpoints

CSO, SL, IC, and Head of Delivery expectations should be written downstream from the shared standards and checkpoints, not as isolated role philosophies.

5. Linear is infrastructure, not the ideology

Linear matters because it is part of the truth-maintenance system. The operating model should not revolve around Linear ownership alone. Linear should be framed as the execution system of record inside a larger delivery system.

Target structure for knowledge/delivery/

The existing folder structure is good. The work is to make each major folder answer one core question and carry more narrative weight.

00-head-of-delivery/

Question this folder answers: Who sets the bar and when do issues escalate?

This folder should define:

  • standards-setting
  • escalation framework
  • Head of Delivery review expectations
  • governance philosophy
  • week-by-week implementation plan for rolling this operating model out
  • KPI framework and performance instrumentation over time

01-roles-and-responsibilities/

Question this folder answers: What is each role accountable for?

This folder should define:

  • shared role-system overview
  • CSO expectations
  • SL expectations
  • IC expectations
  • how roles participate in checkpoints

02-meetings-and-cadence/

Question this folder answers: What are the forcing functions?

This folder should define:

  • checkpoints
  • meeting cadence
  • what each checkpoint is intended to force
  • what gets retired or discouraged

03-project-lifecycle/

Question this folder answers: How does work move from plan to execution to change control?

This folder should define:

  • plan before promise
  • gating and sign-off
  • systems of record
  • re-gating on material change
  • how plan, Linear, and client narrative stay aligned

04-standards-and-sops/

Question this folder answers: What is the standard and what does excellence look like?

This folder should define:

  • the floor
  • communication discipline
  • PM discipline
  • coaching / excellence
  • how standards are enforced

05-tools-and-skills/

Question this folder answers: What tools and SOPs help us execute consistently?

This folder should stay practical and enabling rather than philosophical.

06-reference/

Question this folder answers: What analogies and examples help teach the model?

This folder should hold:

  • analogical reasoning
  • reference examples
  • archived teaching material

Spine docs to rewrite first

These are the four highest-leverage documents. If these are strong, the rest of the folder can be aligned much more easily.

  1. knowledge/delivery/04-standards-and-sops/consolidated-delivery-standards.md
  2. knowledge/delivery/02-meetings-and-cadence/meeting-catalog.md
  3. knowledge/delivery/03-project-lifecycle/README.md
  4. knowledge/delivery/01-roles-and-responsibilities/README.md

These should be treated as the spine of the delivery operating model.

File-by-file execution plan

1. knowledge/delivery/INDEX.md

Role: Front door for the whole delivery system.

Current issue: It acts as a quick reference but does not yet orient the reader around the operating model.

Action: Rewrite it as the narrative entry point.

Target structure:

  1. What this delivery system is
  2. Start here by question:
    • What is the standard?
    • What are the checkpoints?
    • What does my role own?
    • How does work move from SOW to execution?
    • What tools / SOPs do I use?
  3. Folder map with one-sentence purpose per folder
  4. Suggested reading order for new team members
  5. Short note that analogies are teaching tools, with a link to 06-reference/delivery-analogies.md

Outcome: INDEX.md becomes a true map, not just a list of links.

2. knowledge/delivery/04-standards-and-sops/consolidated-delivery-standards.md

Role: Canonical long-form statement of the delivery philosophy.

Current issue: It is too index-like and not yet the center of gravity.

Action: Rewrite it into the main standards chapter.

Target structure:

  1. Purpose
  2. The standard: the floor
  3. Why these standards exist
  4. Analogical framing
  5. What great looks like
  6. Communication discipline
  7. Project management discipline
  8. How the standards are enforced
  9. Good vs miss examples
  10. Relationship to roles and detailed SOPs

Content notes:

  • Section 2 should be poster-grade and short.
  • Section 5 should cover excellence and coaching, not minimum bar.
  • Sections 6 and 7 should absorb principle-level communication and PM doctrine.
  • Section 8 should repeat that standards are enforced through checkpoints, not slogans alone.

Analogy use:

  • Michelin for preparation and quality gates
  • consultancy for POV, synthesis, and defensibility
  • agency for client-visible momentum
  • banking for no surprises, escalation, and review discipline

Outcome: One long standards document that defines the floor, explains the logic, and teaches the bar.

3. knowledge/delivery/04-standards-and-sops/client-communication-standards.md

Role: Detailed delivery-layer communication doctrine.

Action: Keep and strengthen as the communication chapter beneath the consolidated standards doc.

Target structure:

  1. Literal statement
  2. Why it exists
  3. Analogy
  4. What good looks like
  5. Async-first expectations
  6. Internal-first escalation rules
  7. Weekly update expectations
  8. Client narrative rules
  9. Examples

Content notes:

Keep and extend:

  • CSO as external voice
  • no surprise escalations
  • async-first
  • artifact habit
  • status / risks / asks / next steps
  • weekly kick-off / end-of-week expectations
  • “story matches build”

Outcome: A clear communication doctrine aligned to the broader standard.

4. knowledge/delivery/04-standards-and-sops/project-management-standards.md

Role: Detailed execution discipline.

Action: Expand into the PM doctrine.

Target structure:

  1. Literal statement
  2. Why it exists
  3. Analogy
  4. What good looks like
  5. Plan before promise
  6. Systems of record reflect reality
  7. Risk forward
  8. Change control / re-gating
  9. Ownership visibility
  10. Examples

Content notes:

This is where principle-level Linear, planning, risk, and re-gating doctrine should live.

Outcome: A practical PM chapter that explains disciplined delivery.

5. knowledge/delivery/04-standards-and-sops/linear-hygiene-standards.md

Role: Specific execution-truth rules for Linear.

Action: Keep as a subordinate detail doc and rewrite it to support the broader doctrine.

Target structure:

  1. Why Linear matters
  2. What must always be true
  3. Ownership / accountability expectations
  4. Anti-patterns
  5. Review checks
  6. Examples

Framing note: Linear is part of the system of record, not the operating model by itself.

Outcome: A useful reference without letting the philosophy collapse into board administration.

6. knowledge/delivery/04-standards-and-sops/escalation-standards.md

Role: Detailed rules for surfacing and handling risk.

Action: Expand and align directly with the “no surprises” standard.

Target structure:

  1. Literal statement
  2. Why it exists
  3. Analogy
  4. What good looks like
  5. Yellow vs red flags
  6. Who hears what, when
  7. What gets escalated vs handled locally
  8. Examples

Outcome: Makes “no surprises” operational and enforceable.

7. knowledge/delivery/02-meetings-and-cadence/meeting-catalog.md

Role: Canonical checkpoints chapter.

Current issue: It currently reads more like a meeting list than a forcing-function doc.

Action: Rewrite it into the checkpoint chapter.

Target structure:

  1. Purpose: checkpoints enforce the standards
  2. Why the system uses checkpoints
  3. Core checkpoint map
  4. For each checkpoint:
    • Literal statement
    • Why it exists
    • Analogy
    • What good looks like
    • Inputs
    • Outputs
    • What sends work backward
  5. Retired / discouraged rhythms
  6. Links to templates and SOPs

Core checkpoints to define:

  • Project Review Meeting
  • weekly CSO-SL alignment
  • weekly client touchpoint
  • weekly leadership sync
  • engagement technical standup
  • re-gate on material scope/timeline change
  • Linear truth-maintenance / weekly review

Outcome: One of the most important docs in the system; explains how the standards are made real.

8. knowledge/delivery/02-meetings-and-cadence/project-review-meeting/

Role: Deep detail for the most important gate.

Action: Keep the subfolder and align all docs around a single principle:

Project Review Meeting is the main forcing function for “plan before promise.”

Suggested doc roles:

  • README.md — what the PRM is and is not
  • expectations-guide.md — quality bar for review readiness
  • sign-off-checklist.md — operational checklist
  • cso-presentation-template.md — presentation support, not policy

Outcome: A focused gate playbook rather than a loose bundle of artifacts.

9. knowledge/delivery/02-meetings-and-cadence/weekly-leadership-sync.md

Role: Portfolio risk / standards review checkpoint.

Action: Tighten it so it clearly reinforces:

  • not status theater
  • portfolio risk and capacity review
  • escalation themes
  • standards misses and intervention points

Outcome: Clear separation from account-level checkpoints.

10. knowledge/delivery/03-project-lifecycle/README.md

Role: Lifecycle chapter.

Action: Rewrite it into the long-form narrative for:

  • how work moves from SOW to execution
  • where gates are
  • when work must return for review
  • how plan, Linear, and client narrative stay aligned

Target structure:

  1. Literal lifecycle
  2. Why this lifecycle exists
  3. Analogy
  4. What good looks like
  5. SOW → plan → PRM → sign-off → Linear → execution → re-gate
  6. Systems of record
  7. Material change rules
  8. Links to templates and process docs

Outcome: One coherent lifecycle doctrine.

11. knowledge/delivery/03-project-lifecycle/sow-project-plan-template.md

Role: Canonical planning template.

Action: Keep as the main planning artifact template, but lightly tighten wording to match the doctrine:

  • plan before promise
  • explicit ownership
  • defensibility before commitment
  • re-gating if reality changes

Outcome: The planning template matches the philosophy more explicitly.

12. knowledge/delivery/03-project-lifecycle/project-review-process.md

Role: Process detail supporting lifecycle and PRM.

Action: Ensure it is subordinate to the lifecycle and checkpoint doctrines rather than competing with them.

Outcome: Operational detail, not parallel philosophy.

13. knowledge/delivery/03-project-lifecycle/linear-structure-guide.md

Role: Detailed object model for mapping plan to Linear.

Action: Keep as the specific reference for structure and object mapping.

Outcome: Tactical guide beneath the larger lifecycle / truth-maintenance layer.

14. knowledge/delivery/01-roles-and-responsibilities/README.md

Role: Shared role-system overview.

Action: Rewrite it to make the overall role structure explicit:

  • same floor for everyone
  • different responsibilities by role
  • checkpoints define interaction points
  • CSO and SL are a required partnership
  • Head of Delivery governs and intervenes
  • ICs execute through the structure

Add a simple diagram

Use a simple markdown / ASCII diagram to communicate the current model:

           Head of Delivery
             /         \
           CSO <-----> SL
             \         /
                ICs

Then explain:

  • solid hierarchy / accountability
  • required partnership between CSO and SL
  • ICs operating through the shared delivery structure

Outcome: The role chapter starts with a clean mental model before diving into role-specific detail.

15. knowledge/delivery/01-roles-and-responsibilities/cso/

Role: CSO role chapter.

Action: Consolidate around:

  • client success ownership
  • client narrative
  • plan narrative
  • checkpoint participation
  • standards enforcement through communication and visibility

Core docs to strengthen:

  • role-definition.md
  • project-ownership-guide.md
  • cso-standards-matrix.md

Cleanup note: “Day in the life” can remain as supplementary material, but should not carry the canonical philosophy.

Outcome: CSO chapter clearly downstream from the shared standards and checkpoints.

16. knowledge/delivery/01-roles-and-responsibilities/service-lead/

Role: SL role chapter.

Action: Structure around:

  • technical truth
  • feasibility
  • issue quality / readiness
  • IC accountability
  • partnership with CSO
  • checkpoint participation

Core docs to strengthen:

  • role-definition.md
  • technical-approval-guide.md
  • ic-management-guide.md

Outcome: SL chapter becomes strong without over-prescribing daily mechanics.

17. knowledge/delivery/01-roles-and-responsibilities/individual-contributor/

Role: IC role chapter.

Action: Make the IC role chapter explicitly tie to:

  • ownership of assigned outcomes
  • early escalation
  • clear updates
  • quality and finish
  • participation in the truth-maintenance system

Outcome: Simple, strong, and clearly connected to the shared floor.

18. knowledge/delivery/00-head-of-delivery/

Role: Governance and bar-setting chapter.

Action: Use this section to define:

  • the bar
  • escalation framework
  • standards-setting process
  • enforcement philosophy
  • what Head of Delivery reviews and when
  • the implementation sequence for rolling the model out over time
  • the KPI layer that measures whether adoption and delivery quality are improving

Core docs to strengthen:

  • standards-setting-guide.md
  • escalation-framework.md
  • expectations-by-cadence.md
  • week-by-week-implementation-plan.md
  • kpis.md

Outcome: Clear governance layer above the delivery roles.

19. knowledge/delivery/05-tools-and-skills/

Role: Enablement.

Action: Keep practical. Ensure each doc clearly states:

  • when to use it
  • what standard or checkpoint it supports
  • what output it produces

Outcome: Tools support the system instead of becoming the system.

20. knowledge/delivery/06-reference/delivery-analogies.md

Role: Canonical analogical reference.

Action: Expand and strengthen as the teaching-source doc.

Target structure:

  1. Why analogies are used
  2. Guardrails: policy stays literal
  3. Michelin
  4. Consultancy
  5. Agency
  6. Banking
  7. Mapping table:
    • standard / checkpoint
    • strongest analogy
    • why it fits
  8. Limits of each analogy

Outcome: All other major docs can lightly reference this without re-explaining it.

Canonical content model by chapter

Every major chapter should use the same pattern wherever it helps:

  1. Literal statement — what this standard or checkpoint is
  2. Why it exists — why Brainforge operates this way
  3. Analogy — strongest matching precedent
  4. What good looks like — observable behavior

This creates consistency across the entire folder and lets the analogical reasoning act as a teaching throughline without displacing literal policy.

The standards model to preserve

The standards philosophy should stay simple:

Standards = the floor

These are the minimum bar. If someone repeatedly misses them, it is a performance issue.

Checkpoints = the enforcement mechanism

These are the forcing functions that make the standards real.

Coaching / excellence = what great looks like

These are the behaviors that distinguish the strongest operators and future leaders.

This model should remain visible throughout the delivery folder.

Write in this order:

  1. 04-standards-and-sops/consolidated-delivery-standards.md
  2. 02-meetings-and-cadence/meeting-catalog.md
  3. 03-project-lifecycle/README.md
  4. 01-roles-and-responsibilities/README.md
  5. 00-head-of-delivery/week-by-week-implementation-plan.md
  6. Role-specific docs
  7. Supporting detail docs in 04-standards-and-sops/
  8. 00-head-of-delivery/kpis.md
  9. INDEX.md
  10. 06-reference/delivery-analogies.md

This order matters because the philosophy should exist before the role docs inherit it.

Phased implementation plan

Phase 1 — Rewrite the spine docs

Goal: Establish the shared operating model before touching downstream detail.

Docs:

  • 04-standards-and-sops/consolidated-delivery-standards.md
  • 02-meetings-and-cadence/meeting-catalog.md
  • 03-project-lifecycle/README.md
  • 01-roles-and-responsibilities/README.md

Success criteria:

  • The floor is explicit
  • Checkpoints are explicit
  • Roles are framed as part of a shared system
  • Lifecycle and systems of record are clear
  • Analogies appear as teaching aids, not structural clutter

Phase 2 — Align role chapters

Goal: Rewrite role-specific docs so they inherit the shared model.

Docs:

  • 01-roles-and-responsibilities/cso/*
  • 01-roles-and-responsibilities/service-lead/*
  • 01-roles-and-responsibilities/individual-contributor/*
  • 00-head-of-delivery/*

Success criteria:

  • Roles no longer feel like isolated philosophies
  • Role docs point back to standards and checkpoints
  • CSO-SL partnership is explicit
  • Head of Delivery governance is clear

Phase 3 — Align detailed standards and reference docs

Goal: Bring the supporting standards and analogical reference into alignment.

Docs:

  • client-communication-standards.md
  • project-management-standards.md
  • linear-hygiene-standards.md
  • escalation-standards.md
  • 06-reference/delivery-analogies.md

Success criteria:

  • Communication, PM, escalation, and Linear doctrine all point back to the same floor
  • Analogies are consistent and useful
  • Examples reinforce the same bar across docs

Phase 4 — Head of Delivery rollout plan and KPI layer

Goal: Turn the doctrine into an implementation sequence with an explicit ownership and review rhythm.

Docs:

  • 00-head-of-delivery/week-by-week-implementation-plan.md
  • 00-head-of-delivery/kpis.md
  • 00-head-of-delivery/expectations-by-cadence.md

What to capture in the week-by-week plan:

  • rollout sequencing across standards, checkpoints, roles, and detail docs
  • what gets rewritten each week
  • where leadership review and adoption checks happen
  • which parts of the system are announced, piloted, or enforced first
  • what gets deferred until the spine docs are stable

What to capture in the KPI doc:

  • delivery quality indicators
  • communication quality indicators
  • planning / review compliance indicators
  • risk / escalation indicators
  • adoption indicators for the new operating model

Success criteria:

  • Head of Delivery has a practical rollout plan, not just a target state
  • implementation can be paced over multiple weeks instead of attempted in one burst
  • KPI thinking is explicitly separated from the initial standards writing work

Phase 5 — Refresh navigation and support materials

Goal: Make the folder easy to navigate and teach from.

Docs:

  • knowledge/delivery/INDEX.md
  • folder README.md files where needed
  • tools and skills docs that need framing updates

Success criteria:

  • New readers can find the right chapter quickly
  • Reading order is obvious
  • Tools are framed as support for the operating system

Week-by-week implementation plan (Head of Delivery)

Because this operating model is substantial, implementation should be phased over several weeks rather than introduced all at once. The detailed operating sequence should live under:

  • knowledge/delivery/00-head-of-delivery/week-by-week-implementation-plan.md

That doc should answer:

  1. What gets rewritten in each week
  2. What gets reviewed by leadership in each week
  3. What gets socialized to the team in each week
  4. What becomes enforceable in each week
  5. What remains draft or pilot until the spine docs are stable

Recommended structure for that doc:

Purpose

  • Why the rollout is phased
  • What success looks like at the end of the rollout

Week 1 — Establish the standard

  • Rewrite the core standards chapter
  • Align on the floor vs excellence model
  • Lock the canonical section structure

Week 2 — Establish checkpoints

  • Rewrite checkpoint / cadence chapter
  • Define what each checkpoint enforces
  • Tighten PRM framing

Week 3 — Establish lifecycle and systems of record

  • Rewrite lifecycle overview
  • Clarify plan / Linear / client narrative relationship
  • Tighten re-gating doctrine

Week 4 — Establish role model

  • Rewrite shared role-system overview
  • Add the HoD / CSO / SL / IC relationship model
  • Begin aligning CSO and SL role chapters

Week 5 — Align supporting standards

  • Rewrite communication, PM, escalation, and Linear hygiene docs
  • Make sure they inherit the same floor and checkpoint logic

Week 6 — Finalize navigation and begin adoption

  • Refresh INDEX.md
  • Clean up supporting docs and folder readmes
  • Announce reading order and rollout expectations

Adoption / review rhythm

  • weekly leadership review of progress
  • explicit decisions on what is now draft vs active standard
  • decisions on what the team is expected to follow immediately vs later

This plan should assume the work will take time and that doctrinal clarity matters more than speed.

Editing guardrails

While executing this plan:

  • Prefer rewriting existing canonical docs over creating many new files
  • Use one strong long-form doc per major folder/topic
  • Keep policy literal
  • Use analogies as brief teaching devices
  • Do not let any single role doc redefine the entire system
  • Do not let Linear become the whole story
  • Make checkpoints explicit wherever standards need enforcement
  • Separate the floor from excellence

Definition of done

This work is done when:

  • knowledge/delivery/ reads like one coherent operating system
  • the floor is memorable and explicit
  • checkpoints are clearly defined as the forcing functions
  • role docs are clearly downstream from the shared model
  • lifecycle and systems of record are easy to understand
  • analogies make the system easier to teach without making it feel vague
  • the folder is easier to read with fewer, stronger canonical docs
  • Existing active plan: knowledge/plans/active/delivery-charter-rubric-operating-model-2026.md
  • Delivery docs root: knowledge/delivery/

Last updated: 2026-03-24

Graph View