Brainforge Knowledge

executive-q2-planning-operating-model-2026

6 min read

Executive Q2 planning operating model (2026)

Status: Planned
Owner: Leadership / Platform / Delivery
Related: PLT-1224

Purpose

Create one source of truth for three related decisions:

  • how Brainforge plans internal teams and client engagements entering Q2
  • what the canonical internal team taxonomy is
  • how the repo should reflect that taxonomy through team homes and shared artifact layers

This is an executive planning decision, not a team-by-team execution plan.

Executive decision

Brainforge should operate with one planning model across internal and client work:

  • Internal teams are treated as internal service engagements. Leadership or the CEO acts as the sponsor/client.
  • Client work is planned at the engagement level, not just the account level.
  • Planning horizon: internal work plans to the quarter; client work plans to the quarter or the active SOW window, whichever is shorter.
  • Execution rule: no meaningful body of work should enter Q2 execution without an approved plan and matching Linear structure.

At the same time, the repo should be made easier to navigate by using one canonical internal team taxonomy and a clearer information architecture.

Canonical internal teams

Brainforge should treat these as the canonical internal teams:

  • Sales
  • Marketing
  • Delivery
  • People
  • Finance
  • Legal
  • Operations
  • Executive
  • Platform

These names should be used consistently in planning, repo orientation, and future information architecture decisions unless leadership explicitly changes the model.

What this standard requires

Every internal team and client engagement should have:

  1. A written project plan
  2. A named sponsor
  3. A Project Review Meeting or equivalent review checkpoint
  4. Explicit sign-off before execution lock-in
  5. A matching Initiative / Project / milestone / issue structure in Linear
  6. Re-review when scope, timeline, dependencies, feasibility, or resourcing change materially

Planning model

Internal teams

Internal teams should be planned the same way client work is planned.

  • The work is still treated as a service commitment
  • Leadership or the CEO acts as sponsor/client
  • The quarter is the default planning window
  • Milestones should represent leadership-visible outcomes, not internal activity

Client engagements

Client planning should be done per engagement.

  • One client may have multiple active plans if it has multiple active engagements or SOWs
  • The planning window is the quarter or the SOW period, whichever is shorter
  • Milestones should represent client-visible outcomes, demos, go-lives, or decisions

Repo structure model

The repo should be explained through two organizing axes:

  • Team / function — where a team’s operating context lives
  • Artifact type / lifecycle — where plans, standards, templates, and client materials live

That means:

  • knowledge/ is the home for internal team operating context and organizational knowledge
  • knowledge/plans/ is the cross-team planning layer
  • standards/ is the reusable standards and template layer
  • knowledge/clients/ and client repos remain the client-context and client-deliverable layers

knowledge/delivery/ is currently the clearest example of a team home in this model.

Intended team homes in knowledge/

Long-term target model:

  • knowledge/sales/
  • knowledge/marketing/
  • knowledge/delivery/
  • knowledge/people/
  • knowledge/finance/
  • knowledge/legal/
  • knowledge/operations/
  • knowledge/executive/
  • knowledge/platform/

Not every folder needs to be created immediately in this pass. The first goal is to establish the model clearly in docs.

Linear laddering standard

Approved plans should ladder into Linear using the existing delivery mapping:

  • Team = internal service or client delivery container
  • Initiative = major objective
  • Project = workstream
  • Project milestone = sponsor-visible or client-visible outcome
  • Issue = atomic unit of work

This keeps the plan, board, and execution narrative aligned.

Required operating flow

flowchart TD
    quarterOrSow[Quarter_or_SOWWindow] --> draftPlan[DraftPlan]
    draftPlan --> reviewGate[ProjectReview]
    reviewGate --> signOff[SignOff]
    signOff --> linearMirror[MirrorInLinear]
    linearMirror --> execution[Execution]
    execution --> weeklyReview[WeeklyReview]
    weeklyReview --> materialChange{MaterialChange}
    materialChange -->|"No"| execution
    materialChange -->|"Yes"| refreshPlan[RefreshPlan]
    refreshPlan --> reviewGate

Leadership expectations for Q2

Before Q2 execution is treated as locked:

  • every internal team should have an approved quarterly plan
  • every active client engagement should have an approved engagement plan
  • every approved plan should be reflected in Linear
  • any work that cannot pass review should be reframed, deferred, or explicitly treated as exploratory

Internal quarterly plans should map to the canonical internal team list above.

This creates one source of truth for priorities, sequencing, and accountability.

Portfolio rollout sequence

Phase 1: Lock the standard

  • confirm the unified planning model
  • confirm the canonical internal teams
  • confirm sponsor expectations for internal teams
  • confirm the plan-to-Linear mapping
  • confirm the repo structure model: team homes plus shared artifact layers

Phase 2: Inventory the portfolio

  • list all internal teams/services that need Q2 plans
  • list all active client engagements that need engagement plans
  • identify missing sponsors, missing reviews, and missing Linear structure
  • identify where non-Delivery team context is missing or structurally unclear in the repo

Phase 3: Draft and review plans

  • draft internal quarterly plans first
  • draft active client engagement plans next
  • run project reviews and collect sign-offs

Phase 4: Activate in Linear

  • mirror approved plans into Linear
  • attach target dates and milestones where needed
  • use weekly review to keep the board aligned to the approved plan

Success measures

Leadership should track:

  • percent of internal teams with approved Q2 plans
  • percent of active client engagements with approved plans
  • percent of approved plans mirrored in Linear
  • percent of active execution work mapped to an approved plan
  • count of material changes that were re-reviewed versus silently absorbed
  • review cadence compliance across the portfolio

Immediate next steps

  1. Confirm the list of internal teams/services that need Q2 plans
  2. Confirm the list of active client engagements that need engagement plans
  3. Use the canonical team list when drafting internal plans and repo-facing documentation
  4. Use this standard to draft the first wave of plans
  5. Review each plan before treating the work as committed
  6. Reflect approved plans in Linear and manage execution from there

Execution Model

Automated by: Cursor agent via quarterly-planning skill
Human checkpoints: Review gate, sign-off, final approval
Failure behavior: Stop execution on any API/tool failure; do not proceed without explicit human override

Required agent capabilities

  • Linear MCP (read teams, create initiatives/projects/issues, assign labels)
  • File system (read/write knowledge/ and standards/)
  • Vault access (read transcripts, SOWs, existing plans for context)

Templates to apply

  • knowledge/plans/PROJECT-PLAN-TEMPLATE.md for all drafted plans
  • 4-phase workflow from quarterly-planning skill

What this pass should not do

This pass should define the structure first. It should not:

  • force an immediate full folder restructure
  • bulk-move historical docs
  • rename every historical reference to team names
  • restructure Linear as part of the same change

Later cleanup can follow once the planning and repo-structure model are explicit.

  • knowledge/delivery/03-project-lifecycle/README.md
  • knowledge/delivery/03-project-lifecycle/sow-project-plan-template.md
  • knowledge/delivery/03-project-lifecycle/linear-structure-guide.md
  • knowledge/delivery/04-standards-and-sops/consolidated-delivery-standards.md

Last updated: 2026-03-24

Graph View