CTS · Continuant · Operations

An operating system
for execution speed.

Operations is where the company makes good on what sales sold — and where CTS is currently leaving real MRR on the floor while customers wait. This system rebuilds the engine room on two disciplines: Musk's algorithm for what we run, Jensen's flat structure for what we see. Cycle time is the only metric that matters.

6 stagesSold → Renewal
5 handoffsAs Artifacts
1/moRequired Deletion
90 daysFull Rollout
The bottleneck is usually a handoff
Diagnosis

Five symptoms. One root cause.

Onboarding, deployment, Day 2, accounting, and IT are not five separate problems. They're one problem in five places — handoffs are not first-class objects in our operating model. Every transition without a named artifact and a named owner-on-each-side decays into rework, IOUs, and silent revenue leakage.

What it looks like today

The same five symptoms keep recurring across functions. They look like five problems. They're not.

Onboarding intake drags weeks (often months on complex deals); sales commitments surface mid-deployment as "scope creep"
Day 1 → Day 2 transitions take 60–120 days longer than they should — ServiceNow's ~100-item checklist treats every step as equally blocking, customers wait months for service we sold them, and tens of thousands in MRR slip every month before billing even starts
Day 2 also absorbs unbilled work as "support" once the gate finally clears — revenue leaks another 5–15% silently after that
Odoo can't close cleanly because billable scope and shipped scope don't match — and the source of truth lives in three different places
IT is everyone's bottleneck because no one knows what they own — requests come via Slack, hallway, text, never logged

What this system fixes

Speed in operations is a deletion problem, not an addition problem. Most CEOs respond to slow ops by adding process — that's exactly backwards.

Treat every handoff as an artifact — a single document the next owner can read and run with — not as a meeting
Apply Musk's 5-step algorithm monthly to one process — every month, one thing gets deleted
Make T5T from operations roles the CEO's primary signal — see friction in week 1, not Q4
Collapse the Day 1 → Day 2 transition to a 5-item gate — delete the ServiceNow checklist down to what actually blocks service, target ≤5 business days from project completion to first day of billable Day 2 MRR
Make HubSpot the single source of truth for billable scope; Odoo reads from HubSpot — never the reverse
IT and Accounting operate on published internal SLAs — bottleneck becomes visible, then deletable
The thesis: If a process needs a meeting to function, the process is broken. Meetings are the symptom of bad handoffs. Replace them with artifacts and the org gets faster every month.
The System

Six pillars. One operating system.

Each part is modular. Implement in sequence or start with the pillar where you bleed most cycle time today (for most CTS teams, that's Pillar 04 — Handoffs).

01

Operations Pipeline

Six stages from Sold to Renewal with explicit entry/exit criteria, SLAs, owners, and handoff artifacts at every transition.

Pipeline · Stage Gates · SLAs
02

Musk Algorithm

Question, delete, simplify, accelerate, automate — applied monthly to one process. The required output is one deletion. Not flagged. Deleted.

5 Steps · Monthly Cadence
03

Jensen Signal

T5T from every ops-facing role. Group feedback, no scheduled 1:1s for ops leadership. The CEO sees the field through the field's eyes.

T5T · Flat · Group Feedback
04

Handoffs as Artifacts

Five critical handoffs at CTS — each with a named owner on both sides, an artifact (not a meeting), an SLA, a failure mode, and a detection signal.

★ The Star Pillar
05

Operating Cadence

Daily, weekly, bi-weekly, monthly, quarterly forums. Each with one decision mandate. None where they overlap with sales cadence.

Daily · Weekly · Monthly
06

Speed Doctrine

Ten operating rules for the COO and ops leaders. Time allocation. Stop-doing list. The standard for what good looks like.

10 Rules · Time Allocation
Part One

The customer's journey through operations.

Six stages. Each stage has explicit entry/exit, an SLA, a named owner, and — critically — a handoff artifact at every boundary. Click any stage to inspect it. Stage 4 (Stabilization) is the valley of death; that's where speed dies most often.

1
Sold
5d SLA
2
Scope
Lock
10d SLA
3
Build /
Deploy
30–60d
4
Go-Live
+ Stabilize
30d max
5
Day 2
Managed
Steady
6
Renewal /
Expand
90d before
Click any stage to expand entry/exit criteria, owner, and handoff artifact
100%
Stage Compliance
No deal moves without exit criteria met
≤5d
Sales→Ops Handoff
Charter delivered within 24h of signature
≤30d
Stabilization Window
Day 0 → Day 2 gate signed
0
Zombie Deployments
Deployment ≠ Day 2 work after gate
The boundary is the work. Inside a stage, your team mostly knows what to do. Between stages is where the org loses time. The handoff artifact at each boundary is the most important page in this entire system.
Part Two

Musk's algorithm, applied to operations.

Five steps. The order is non-negotiable. Optimizing before deleting is the most common mistake in operations — it's how we end up with sophisticated, fast versions of work that shouldn't exist.

1

Question

Attach a person's name to every requirement. "We need this because policy" is not a name. If no one will own the requirement, it doesn't exist.

No anonymous rules.
2

Delete

Remove more than feels safe. If you don't add 10% back later, you didn't delete enough. Most ops processes can lose 30–50% of their steps and gain quality.

Most stop here. Don't.
3

Simplify

Only after deletion. Never simplify what should be eliminated. Simplifying preserves the existence of the process; deleting questions it.

In service to deletion, not optimization.
4

Accelerate

Speed up what survives the first three steps. Find the cycle-time bottleneck. Halve it. Then halve it again. Cycle time is the metric.

Cycle time over throughput.
5

Automate

Last. Automating a broken process makes you faster at the wrong thing. Most "automation projects" should have been deletion projects in disguise.

Automation is the reward, not the goal.
Worked Example · OnboardingThe Onboarding Intake Form
Today

A 47-field intake form spread across HubSpot, ServiceNow, and Odoo, two manual handoffs, one shared spreadsheet stitching them together. Average completion: weeks — often months on complex deals. Constant rework when fields conflict between systems.

23 fields are "nice to have" that no one references downstream 5 fields ask the same question in different language across the three systems Customer fills the same data twice (once for sales, again for ops) Sales fills 6 fields in HubSpot, ops re-types into ServiceNow, accounting re-types into Odoo
After the algorithm

A 9-field charter in HubSpot as the single source of truth. Sales completes 5 fields, deployment completes 4 at scope-lock. ServiceNow project record auto-creates from the charter; Odoo reads from HubSpot for billing. Average completion: 2–3 business days.

Question: "who owns each field?" 23 fields had no living owner — deleted Delete: 5 duplicate fields collapsed to 1 each Simplify: customer never fills anything they already told sales Accelerate: charter auto-generates the ServiceNow project record Automate: kickoff calendar invite fires on charter completion; Odoo billing record initialized in parallel
Cycle time crashes from weeks/months to days. Rework rate drops to near zero. Sales stops sandbagging the start date because the start date is now real.
Worked Example · AccountingThe Odoo Month-End Close
Today

A 12-day Odoo close with four sequential reconciliations. Day 2 scope changes sit in ServiceNow tickets and only reach Odoo at month-end batch. AR aging reviewed monthly. Revenue leakage typically discovered the following month.

Wait ~8 days for ServiceNow scope changes to flow into Odoo Reconcile billable (Odoo) vs shipped (ServiceNow) — often a 2-week lag Discover leakage retroactively; chase customer for a backdated invoice nobody likes Manual journal entries for ~30 expansions/month, retyped from ServiceNow
After the algorithm

A rolling close in Odoo. Billable scope lives in HubSpot as the single source of truth and updates within 24h of any change. ServiceNow tickets that change scope post back to HubSpot automatically. Odoo reads from HubSpot. Weekly scope diff catches leakage in 7 days, not 30.

Question: "why is close at month-end?" Because that's when Odoo reads the data — fix the read, not the close Delete: month-end batch reconciliation; replace with weekly billable-vs-shipped diff Simplify: one source of truth (HubSpot scope) replaces 3 spreadsheets and a manual ServiceNow export Accelerate: weekly leakage review takes <30 minutes Automate: Odoo invoice line items generated from HubSpot, not retyped from ServiceNow
Close cycle 12 days → 3 days. Revenue leakage detection 30 days → 7 days. Odoo and ServiceNow stop fighting because they no longer hold competing versions of the truth.
Worked Example · Internal ITInternal IT Ticketing & Provisioning
Today

Three queues (Service Desk, Internal IT, Provisioning), two escalation paths, no published SLAs. Many requests come via Slack/text/hallway and never get logged. IT can't see total queue depth, can't prioritize, becomes the perceived bottleneck.

~40% of requests bypass the ticket system No quoted response time — every request feels urgent Same request submitted to multiple queues "to be safe" IT spends 30% of its week answering "where is my request"
After the algorithm

One queue, four named categories with named owners and published SLAs. Slack/text requests are politely redirected to the form. IT becomes a partner with visible capacity, not an opaque queue.

Question: "why three queues?" Historical, not necessary — deleted Delete: Slack-as-intake; force the form (5 fields, 30 seconds) Simplify: 4 categories cover 95% of requests; rest goes to "other → triage" Accelerate: published SLAs (provisioning <24h, access <4h) Automate: standard provisioning runbook executes from form submission
Visible queue depth. SLA breach rate measurable. IT stops feeling like a bottleneck because the bottleneck becomes addressable.
The Algorithm Audit cadence: One process per month. Working group of 4–6 people. 45 minutes. Required output: one thing deleted. Not flagged. Not "for review." Deleted. If the session ends without a deletion, name it: "this session failed."
Part Three

Jensen's signal, applied to ops.

The Sales OS uses T5T from sellers; the Operations OS uses T5T from the people closest to the customer's reality after the sale — deployment engineers, service desk leads, account managers, IT, accounting. Different signal, same discipline. The CEO sees the field through the field's eyes.

Operating Principle

Eliminate routing layers

Information that travels through three people gets distorted; information that travels through five gets discarded. Jensen's flat structure is the antidote — but the principle (not the 60-direct-reports number) is what travels to ops.

DirectOps leaders meet the people doing the work — not just the managers of the people doing the work
GroupNo scheduled 1:1s for ops leadership; group feedback in the room where the work lives
PublicDecisions made in the room are visible to the room. No sidebar deals.
CompressIf three people are forwarding the same email, the org chart needs editing
Intelligence System

T5T from operations roles

Same Monday cadence as sales, different signal. Ops T5T captures real-time customer experience, handoff friction, recurring tickets, internal blockers. The CEO reads every one Sunday night and responds personally.

WhoDeployment Leads, Service Desk Manager, Account Managers, IT Lead, Accounting Lead
What5 raw observations: friction, repeated tickets, customer signals, handoff failures, surprises
OverrideIf T5T says a deployment is at risk and the project plan says green, the project plan is wrong
PatternSame friction in 3 weeks running becomes an Algorithm Audit candidate

What ops T5T looks for

Sales T5T captures market signal and deal motion. Ops T5T captures execution friction and silent failure modes. Different patterns. Same priority for the CEO.

Pattern 1
Repeated friction

The same problem hits week after week without anyone naming it as a system issue

Pattern 2
"Always done it"

The phrase that signals a Musk Step 1 candidate — a requirement with no living owner

Pattern 3
Handoff failures

"I asked X, no one knew, I asked Y" = the handoff artifact is missing or stale

Pattern 4
Revenue leakage

Day 2 absorbs work that should be billed; the signal arrives long before the invoice does

Example ops T5T

Subject: Top 5 Things — David K., Deployment Lead 1. AT-RISK: Northstar Health go-live Friday. Their EHR team hasn't tested the integration despite three asks. Recommending we delay to Tuesday or accept a hot rollback. 2. FRICTION: Third deployment this month where sales committed to "weekend cutover." Costs us 14 person-hours each. Charter should make weekday-default explicit. 3. PATTERN: Five tickets this week from clients asking how to add users. We trained admins on this — admin churn is the real issue. Suggest we add a 30-day post-go-live re-training touchpoint. 4. HANDOFF: Service desk took over Premier Cardiology two weeks ago but they're still pinging me directly. Need to formally close the loop with their stakeholders. 5. SURPRISE: Got a great unsolicited reference from Coastal Family Medicine — they offered to do a written case study. Routing to marketing.
The CEO's Sunday night job: read every ops T5T. Respond personally to each. Look for the patterns the writers don't see — the same friction in three different submissions is a system-level signal that no individual will surface alone.
Part Four · The Star Pillar

Handoffs are artifacts, not meetings.

Five handoffs at CTS quietly determine whether the company scales smoothly or grinds. Each one needs a named owner on each side, an artifact, an SLA, a known failure mode, and a detection signal you can actually monitor. An artifact here means a single document — the Charter, the Gate, the Scope Sheet — that captures everything the next owner needs (scope, status, decisions, contacts, gaps) so the work transfers cleanly whether or not the people meet. Click any handoff to expand.

01
SalesDeployment
The IOU problem · what sales promised that deployment doesn't know about
Artifact: Deployment Charter

One page in CRM. Auto-generated from the deal record at signature, completed by AE within 24 hours. Includes signed scope, commitments not in SOW (the IOUs — what AE promised verbally), known risks, success metrics, client stakeholders + their day-0 expectations, first 30-day milestones.

OWNERS AE (sales) · Deployment Lead (ops)
SLA Charter delivered within 24h of signature; kickoff scheduled within 5 business days
CONFIRMATION Deployment Lead countersigns charter within 48h or escalates gaps to AE manager
Failure mode + detection

Failure: AE moves to next deal; verbal commitments surface 60 days later as "scope creep" or an unhappy customer. Deployment ends up doing unbudgeted work to keep the customer whole.

Detection: Any deployment ticket in week 4+ that references a commitment not in the charter. Should be zero. Track weekly. Three in a month = tighten the AE manager review on Stage 4 deals.

02
DeploymentDay 2 Managed Services
★ The transition gate · most companies skip the formal sign-off and pay for it forever
Artifact: Day 2 Transition Gate Document

Multi-page sign-off package. Sections: what is live (every contracted scope item with checkbox), what is deferred (out-of-scope-for-now with target date), known issues + workarounds, runbook links, customer escalation tree, billing scope confirmed by accounting, first-30-day SLA targets.

OWNERS Deployment Lead · Service Manager
SLA Gate held within 5 business days of "go-live"; sign-off within 48h of gate
SIGN-OFFS Deployment Lead, Service Manager, Accounting, Account Manager, Customer (rare but powerful)
Failure today + detection

Failure today: Day 1 → Day 2 takes 60–120 days. ServiceNow's ~100-item checklist treats every step as equally blocking; the vast majority document for compliance or audit, almost none actually block customer service. The customer expects service the day deployment ends; we make them wait two-to-four months. Faith erodes during the wait — "we sold them service they can't get yet" — and at typical CTS account sizes, every 30 days of delay is real five-figure MRR lost forever. You don't get those months back.

Detection: One number, tracked weekly per account: days from project completion to first day of billable Day 2 MRR. Current 60–120. Target ≤5 business days. The Day 2 Gate deep-dive below shows how the deletion target gets there.

03
Day 2Accounting
The billing reality · 5–15% revenue leakage is the silent default if this is unowned
Artifact: Billable Scope Sheet

Single source of truth in HubSpot (not Odoo, not a parallel spreadsheet). Lives on the customer record. Sections: contracted MRR, scope items, expansions logged with date, out-of-scope work flagged for billing review. ServiceNow scope changes post back to HubSpot automatically; Odoo reads from HubSpot for invoicing.

OWNERS Service Manager (Day 2 / ServiceNow) · Billing Lead (Odoo)
SLA HubSpot updated within 24h of any scope change; weekly diff between shipped (ServiceNow) and billed (Odoo) reviewed every Friday
CONFIRMATION Weekly diff >2% triggers a same-week billing review, not a month-end one
Failure mode + detection

Failure: Day 2 absorbs work as "support" that should be billed. Accounting bills stale numbers because the source of truth lives in someone's head. Revenue leakage of 5–15% goes undetected for months.

Detection: Weekly delta between "shipped this week" (per Day 2) and "billed this week" (per accounting). A >2% delta is a red flag, not a rounding error. Trend the leakage rate as a published ops metric.

04
AnyoneIT
Provisioning, access, system change · IT is everyone's bottleneck because no one knows what they own
Artifact: IT Request Standard Form

5 fields, no narrative. Category (provisioning · access · system change · support), requestor, affected user(s), deadline, business reason. Slack/text/hallway requests are politely redirected to the form. Published internal SLAs by category.

OWNERS Function Lead (requesting side) · IT Lead
SLA Provisioning <24h · Access <4h · System change varies (with quoted time) · Support <same business day first response
CONFIRMATION All work is in one queue; IT publishes weekly capacity vs demand
Failure mode + detection

Failure: Requests via Slack/text/hallway with no record. IT can't prioritize because it can't see the total queue. IT becomes opaque, then becomes the bottleneck, then becomes the org's villain — though the real problem is the lack of an intake artifact.

Detection: Compare request count per week (informal estimates from function leads) to ticket count in the system. Delta = informal channel volume. Aim to drive the delta below 10% within 60 days.

05
CustomerInternal Owner
Escalation routing · the customer should never have to know our org chart
Artifact: Single Point of Contact convention

Published to the customer in the Day 2 transition gate. Default: Account Manager owns the relationship. Day 2 issues: Service Desk owns. Internally, every inbound is owned within 24h or escalated. The customer's mental model is simple: "one person to call."

OWNERS Account Manager (default) · Service Desk (Day 2 issues)
SLA First response <4h business hours · Internal ownership confirmed <24h
CONFIRMATION Any inbound forwarded more than once is a process failure logged for the next Algorithm Audit
Failure mode + detection

Failure: Customer sends to AE who sold the deal 8 months ago. AE forwards to Service. Service forwards to Deployment. Nothing happens. Customer escalates to CEO. The whole org has now been dragged into one ticket.

Detection: Track inbound emails forwarded more than once. Should be near zero. Spike is a signal that the convention isn't being communicated to customers (usually because the Day 2 gate document is stale or skipped).

The acid test for any handoff: if a person calls in sick on the day of the handoff, does the work transfer correctly? If yes, you have an artifact. If no, you have a meeting — which means you have a problem.
Featured Deep-Dive · The Deletion Target

The Day 1 → Day 2 Transition Gate.

At CTS today, this transition takes 60–120 days between project completion and the first day of billable Day 2 MRR. ServiceNow's ~100-item checklist is the bottleneck — most items document for compliance or audit; almost none actually block the customer from receiving service. Customers expect service the day deployment ends; we make them wait months. That ambiguity is where MRR — real, recurring, five-figures-per-account-per-month MRR — dies. The gate exists to compress 60–120 days down to ≤5 business days.

Gate Definition

A gate is held within 5 business days of go-live. It is a meeting and a document — but the document is the deliverable. The meeting is just the moment when the document is signed. This gate replaces the existing 100-item ServiceNow checklist; it does not add to it.

What must be true to pass

  • Every contracted scope item has been delivered or formally deferred (with a date)
  • All known issues have a workaround documented and an owner assigned
  • Runbooks for the customer's configuration are linked, current, and owned by the Service Manager
  • The customer escalation tree has been published to the customer
  • Accounting has confirmed they can bill what's been delivered (matches the Billable Scope Sheet)
  • First 30-day SLA targets are documented and acknowledged by Day 2
  • The deployment engineer has zero open tickets older than 14 days

Watch the 30 days after the gate

  • Track every ticket touched by the deployment engineer — should trend to zero by day 14
  • Track Day 2 ticket volume daily — spike = unfinished deployment work surfacing as "support"
  • Track customer escalations by recipient — the customer should be using the published escalation tree
  • Track billing accuracy — first invoice after gate must match the Billable Scope Sheet exactly
  • If any of the above fails, hold a 15-minute "post-gate adjustment" meeting; do not let it drift

What to delete from the ServiceNow checklist

The current ~100-item checklist is the cycle-time killer. Most items exist for documentation or audit reasons; very few actually prevent the customer from receiving service. Audit the existing checklist against three categories and act accordingly. The goal is not a perfectly documented handoff. The goal is a fast handoff that lets us bill MRR.

Keep — actually blocks customer service (target ≤10)

  • Production cutover verified and signed off by Deployment Lead
  • Customer escalation tree published to and acknowledged by the customer
  • Service runbooks current, linked, owned by Service Manager
  • Billable scope sheet in HubSpot matches what was delivered (Odoo can invoice it)
  • Day 2 Service Manager has access to all customer systems
  • Critical SLAs documented for the first 30 days

Defer or delete — does not block customer service

  • Documentation polish, internal narrative writeups → defer 30 days (don't block billing)
  • Admin-side configuration of optional features → defer until customer asks
  • Customer signoff on items they don't care about → delete
  • Sign-offs duplicated across stages → consolidate to one
  • Any item where the owner can't explain in one sentence why customer service is blocked → delete
  • Compliance/audit documentation → track separately, post-gate, never gating Day 2 MRR start
The acid test for every checklist item: if we skip this item, can the customer still receive the service we sold them? If yes, it does not gate Day 2 MRR. Track it post-gate, do it post-gate, but bill from the day deployment ends. Compliance documentation does not delay revenue.
Sign-off 1
Deployment Lead

"This is what we delivered."

Sign-off 2
Service Manager

"We accept and will run it."

Sign-off 3
Accounting

"We can bill what's described."

Sign-off 4
Account Manager

"Customer relationship is intact."

Sign-off 5
Customer (optional)

"We agree on what's live."

The zombie test: 31 days after the gate, can the deployment engineer be 100% on a different customer? If no, the gate failed. Run a re-gate within 5 days to identify what's not actually live and either finish it or formally defer it. Zombies are a leadership failure, not a deployment failure.
Part Five

How operations actually runs.

Five recurring forums, each with a single decision mandate. Hard agendas. Pre-reads required. The forums for ops are deliberately separate from sales cadence — different signal, different decisions, different room.

Daily

Deployment Standup

15 minutes. Deployments in flight only. Each lead names blockers and asks. No project updates — those live in the system. If there's no blocker, the standup is short.

15 min · Deployment leads · No status updates
Weekly

Operations War Room

Stage 3–5 customers only. Pre-reads required. Every at-risk deployment ends with a named owner and a committed date. Mirrors the Sales War Room cadence.

45 min · 5–7 people · Mondays
Bi-Weekly

Cross-Functional Ops Sync

The only meeting where Deployment, Service, IT, and Accounting are in the same room. Agenda: handoff health, recurring friction, Algorithm Audit candidates.

60 min · All ops functions · No status updates
Monthly

Algorithm Audit

One process. Apply the 5 steps. Required output: one thing deleted. Not "flagged." Deleted. If nothing is deleted, the session failed; name it.

45 min · 4–6 people · Required deletion
Monthly

Day 2 Health Review

Top 10 accounts by NRR + churn risk. Each account's Service Manager owns the read. Outputs: at-risk accounts, expansion ready, retraining needs, billing leakage flagged.

60 min · Service leadership + AMs
Quarterly

Capacity + Automation Review

Where are we hiring vs. automating. Capacity model vs. forecast deployments. Algorithm Audit deletion log reviewed. Re-baseline cycle-time targets.

2–3 hrs · Ops leadership · Half-day
The forum rule: If a meeting can't name the decision it will produce, cancel it. Cadence is built around decisions, not updates. The artifacts (CRM, ticket system, scope sheet) hold the updates; the forums hold the decisions.
Featured Functions

Accounting and IT, operationalized.

Both functions earn their reputation as bottlenecks because the rest of the org doesn't see how they work. Publishing internal SLAs and operating models converts opacity into partnership.

Function 01 · Accounting (Odoo)

Operating model

Accounting is not a month-end batch. It is a real-time read on the operating reality. The faster the read, the smaller the leakage.
Operating rhythm
  • Rolling close in Odoo — daily entries, not month-end batch
  • Single source of truth for billable scope lives in HubSpot — Odoo reads from HubSpot, never the reverse
  • Weekly billable (Odoo) vs shipped (ServiceNow) diff reviewed every Friday
  • AR aging reviewed weekly, not monthly
  • Month-end close target: 3 business days, mostly review
Published SLAs
  • Invoice generated within 2 business days of scope change in HubSpot
  • Customer billing question first response <same business day
  • Internal expense reimbursement <5 business days
  • Month-end financials available by business day 3
Most common failure mode: waiting for "complete" data to close. The data is never complete. Close on what's known in Odoo; correct in next period. Speed compounds.
Function 02 · Internal IT

Operating model

Internal IT (employee provisioning, access, internal systems) is a platform partner, not a queue. When IT becomes opaque, the rest of the org bypasses it — and now we have shadow IT we can't see. Note: this is distinct from ServiceNow, which serves customers — internal IT lives in its own intake.
Operating rhythm
  • Single intake form (5 fields). No Slack/text/hallway intake.
  • Four named categories with named owners + published SLAs
  • Standard provisioning runbook — automate from form submission
  • Decommissioning runbook (the missing one most orgs skip)
  • Weekly capacity-vs-demand published to ops leadership
Published SLAs by category
  • Provisioning new user / device · <24 business hours
  • Access change (existing user) · <4 business hours
  • System change · varies; quoted at acknowledgment
  • Support ticket first response · <same business day
Most common failure mode: IT staffed for steady-state but customer growth requires surge capacity. The Capacity + Automation Review exists to surface this — if IT misses SLAs three weeks running, it's a hire-or-automate decision, not an IT performance problem.
Part Six

The Speed Doctrine. Print and post.

Ten rules for the COO and ops leadership. These are non-negotiable behavioral standards, not suggestions. They exist to make the right action obvious in the moment when speed is at stake.

01

Handoffs are artifacts, not meetings

Every transition has a named owner on each side, a document, an SLA, and a known failure mode. If a handoff requires a meeting to function, the handoff is broken.

02

Every requirement has a person's name attached

"Policy" is not a person. If no one will own it, it doesn't exist. This is the precondition for Step 1 of Musk's algorithm.

03

Delete before optimizing. Optimize before automating.

Order is non-negotiable. Automating a broken process makes us faster at the wrong thing. Most "automation projects" should have been deletion projects.

04

The only acceptable Deployment → Day 2 transition is a signed gate

No "soft launches" with informal handover. The gate is a five-signature artifact within 5 business days of go-live, or it's not live.

05

No "TBD" on a Day 2 contract

If accounting can't price it, sales can't sell it. Every line item has a billable scope and a service definition before the SOW is signed.

06

If friction repeats 3 times, it becomes a delete-or-fix item

Once is bad luck. Twice is coincidence. Three times is a system. Add it to the next Algorithm Audit and resolve it.

07

IT and Accounting publish internal SLAs

Opacity creates the bottleneck. Visibility creates the partnership. If we miss a published SLA three weeks running, it's a capacity decision, not a performance issue.

08

Cycle time is the metric

Not throughput. Not utilization. Cycle time per stage, per handoff, per customer. Halve it. Then halve it again. Speed compounds.

09

The org chart is the work

If work flows around the org chart, the chart is wrong. Edit the chart, don't route around it. This is Jensen's principle made literal.

10

One deletion every month

Algorithm Audit produces one removed step, every month, without exception. If the session ends without a deletion, name the failure publicly and rerun within 7 days.

COO / Ops Leader Weekly Time Allocation

Deployments in flight (esp. Stage 4)
30%
Day 2 health (NRR, churn risk)
20%
Deletion / process work
15%
People (managers, hiring, calibration)
15%
IT + Accounting partnership
10%
T5T + signal scanning
10%
Stop-doing list for the COO: stop sitting in status meetings · stop reviewing CRM hygiene (managers own it) · stop being the IT escalation path · stop approving expense reports under $X · stop attending every customer escalation (Service Manager owns) · stop weighing in on hiring panels you weren't asked to.