Delivery Operating Manual

The weekly loop

The huddle board — what you're both looking at

The huddle is three panes, always the same three, 15 minutes total. One tracker per kind of thing — never a second list of any of them:

Then commitments out loud, and done. Tasks live as the day's commitments plus P0–P3 tasks in the brain — the huddle is where they're chosen, the EOD job is where they're graded. So the full system is exactly three trackers: issues = problems found · command home = containers of work · commitments/tasks = today's chosen moves.

Prioritization is mechanical, not a debate: name the constraint first; only work that removes it gets a slot; everything else is parked by default. Never present a ranked list without the constraint named on top. During a cash sprint, infrastructure and tooling lose to delivery unless they ARE the bottleneck.

Picking the week's one big project

Context: after 13 weeks, a minimum viable version of everything exists — every process has a first, rough draft. The work now is optimization, and capacity is one big project per week. The pick is mechanical:

Where optimization candidates come from when the funnel is green: the rule-of-three build tasks (patterns that clunked 3× in a week) and issue-register clusters. That queue is the backlog; the funnel walk decides whether this is a week for it.

The week's project laddered up: it must serve the current 6-week sprint outcome, which serves $100K by Dec 31. If a candidate serves neither, it's parked no matter how broken it feels.

The builder's daily sweep — every surface, every day

The no-orphan rule made operational. Run in this order; the whole sweep is ~60–90 minutes bracketing the huddle:

Departments & ownership

The ruled org shape is seven departments. Two people cover all seven: Akash owns every human conversation with money on the other end; you own every machine and every process. Per-department status of SOPs/playbooks is mapped live at team.stpierre.ai/sops/ — the honest summary: a v1 exists for nearly everything; almost nothing is optimized. That's the design, not a failure — zero-to-one is done, one-to-ten is your job, one department per week.

Organic content is the one split seat: Akash records (his face, his voice — not delegable); you own everything after the recording — production, editing, publishing cadence, and the idea pipeline. Target: 5 reels/week + 1 long-form, tracked on the scorecard like any other metric.

The org: two humans + an agent workforce

The org chart is: Akash (CEO, sales) → you (ops lead) → AI agents. Every department's labor is agents — the Messenger bot, the follow-up rails, the watchdogs, the ~50 scheduled jobs, and the Claude/Codex working sessions that build and fix things. There are no other humans. That makes your actual craft managing an agent workforce: building agents, directing them, and quality-controlling their output.

• Build: when the rule of three fires, the fix is usually a new agent or gate, not more manual effort. Everything you do three times, an agent should do the fourth.
• Direct: agents get written contracts — goal, constraints, output format, failure conditions — before they run. Vague instructions produce confident garbage.
• QC — the part that can't be skipped: never accept an agent's "done." Spot-check outputs against sources, read the ledger rows it wrote, fire a test through anything it changed. This record's worst incidents were agents reporting success while failing silently — false success receipts, green badges over stale data. Trust is earned per-agent, per-task-type, and revoked on the first silent failure.
• Retire: an agent nobody's watching is a liability, not an asset. Every automation has an owner (you), a heartbeat, and a watchdog — or it gets turned off.

Where we are → where we're going, per department

Zero-to-one is done everywhere; this is the one-to-ten map. Each row's gap is a candidate for a weekly big project — the funnel walk (above) decides the order.

How problems get found

Four detection channels, in order of preference. The 13-week pattern is clear: every big incident that hurt was caught by channel 4. Your mandate is to make channels 1–3 catch everything first.

Diagnosis rules (learned the hard way)

• Read the execution log before theorising. Pull the actual run log / message record / API response first; most "mysteries" are one error string.
• Check the register before treating an alert as new. Most alerts are known issues already filed.
• Negative claims need an unfiltered check. Before saying "no leads came in," query with zero filters — filters hide the answer.
• An edit is not a run. Nothing is fixed until a real execution proves it.

The bug tracker & lifecycle

The tracker is the issues table in the brain (Postgres) — one unified register that the watchdogs and anomaly sweeps sync into automatically (issues_sync.py). Each issue has a kind, severity, owner, age, and status. Manual issues (something you or Akash notices) are inserted by hand into the same table — one register, never a second list.

Severity ladder & response time

Lifecycle

open → in_progress → resolved (or wont_fix with one line of why). Issues auto-resolve when their source alert clears; everything else you close by hand. Three rules make closing honest:

• Close with proof. A closed issue names the verification: the test lead that flowed, the URL opened, the log line. "Should be fixed" never closes anything.
• Third strike becomes a gate. The same failure pattern three times in seven days stops being a bug and becomes a build task: a check that makes the mistake mechanically impossible (a gate, a watchdog, a schema constraint). This is the house version of a postmortem action item, and it's already automated in the shutdown ritual (the "clunk log" + rule of three).
• Every fix that touched a live system is ledgered. The change ledger (45,000+ rows) records what changed, before/after, and how to undo it. If you can't write the rollback line, you're not done designing the fix.

13 weeks of recurring problems — and what fixed them

Seven problem families account for nearly every incident in the record. Learn these and you'll recognize the next incident before it grows — new problems here are almost always an old family wearing a new shirt.

The meta-pattern across all seven: every durable fix was a mechanism, not a reminder. Memory-based fixes recurred; gate-based fixes didn't. When you fix something, ask "what makes this impossible to repeat?" — that answer is the real fix.

How SaaS companies do this → our simplest version

Over 13 weeks this company independently converged on the standard SaaS reliability stack. Here's the mapping, so you can borrow industry practice without importing its ceremony:

What we deliberately skip: sprint points, ticket ceremonies, standup theater, dashboards for their own sake. Two people don't need Jira; they need one honest register, one scorecard, and one ledger.

Akash's decision frameworks

Six rules explain ~90% of the decisions in the record. Use them and your calls will match his.

Focus framework behind it all: urgent loses to important; the constraint decides priority; and the daily three (value, content, conversations) are Akash's — yours is the delivery mirror: leads answered, appointments delivered, systems green.

Communication protocol — what Akash sees, and when

The shared surface is the scorecard system, not chat. You both look at the same four pages; chat is for exceptions.

Your decision log — the trust mechanism

You will make judgment calls all day without asking. That's wanted. The deal is: every meaningful call gets logged the moment you make it, in one line, four parts: the fork · what I picked · the number it serves · how to undo it. Akash reviews the log after the fact instead of approving in advance — that's what makes 9–5 sales possible. A decision that would embarrass you in that log is a decision to ask about first.

The daily EOD (Slack #daily-reports)

Five parts, same order every day: Shipped (with proof) · Numbers (per live client) · Broken/behind (with fix + ETA) · Decisions I made (the day's log lines) · Blocked (split: needs-your-word vs your-lane) · Tomorrow's first domino.

Interruption rule

Interrupt Akash mid-day only for: leads not flowing, client-visible breakage, or money at risk — and always with the fix already started. Everything else waits for the EOD or the huddle.

The boundary, stated once: you do everything except client-facing and prospect-facing communication. When a fix requires telling a client something, you draft the message and the receipts; Akash sends it.

Your scorecard — leading & lagging

These go into the scorecard as your seat, so the same Friday review that grades the company grades the role. If a leading metric is green for weeks while a lagging one stays red, the leading metric is measuring the wrong input — say so and propose a swap.

How to find anything

Tech stack inventory

The 4-week ramp

Buyback logic: Akash hands off the lowest-judgment, highest-hour work first, audits your outputs weekly, and keeps only what genuinely needs the owner.

Standing bar, forever: nothing breaks silently, nothing needs asking twice, every number traces to a source, and "I don't know" beats a guess.