BizOps

BizOps (business operations) has no agreed definition. On this page it means the company’s operating system: the planning cadence, the hierarchy of goals and KPIs, and the business reviews through which a leadership team turns strategy into resourced work, sees early when results diverge, and moves people and money in response. Where a BizOps team exists, it runs that system and takes on cross-functional problems no single department owns.

For BizOps and strategy analysts, chiefs of staff, COOs and founders, finance business partners, technology leaders who must show what their spending achieved, and beginners.

Strategies rarely fail inside one department; they fail between departments, and between the annual plan and what happens in March. A survey designed by Donald Sull and Rebecca Homkes asked 11,000 senior executives, leaders and managers in more than 400 companies to list their top priorities. Homkes: “Only a third can list their firm’s top three.” Among those who had helped develop the strategy, the result was “only slightly more than half”. On coordination, Homkes: “When it comes to relying on teams in other departments or business units, senior managers trust their colleagues to deliver all of the time, less than 10% of the time.”^[6]

• Not RevOps, AnalyticsOps or ProjectOps. The revenue forecast process, metric definitions and single projects belong to the neighbours in the table below; BizOps uses their outputs.
• Not the finance function. Finance owns the books (accounts, close, statements and controls, under the controller) and the budget and financial forecast (financial planning and analysis, FP&A);^[7] BizOps owns the rhythm and the non-financial drivers. Where BizOps reports to the CFO the line blurs: agree in writing who owns which number.
• Not SalesOps or another “X Ops”. El-Baba separates “BizOps for x” from “x ops”: BizOps “advises the functional leader”, while the X Ops team runs the function’s day-to-day operations (“for sales ops, it is setting plan, managing individual rep-level quotas”).^[1] See SalesOps.
• Not strategy. The leadership team chooses where to compete; BizOps turns the choice into a plan and runs the reviews that test it.
• Not a product. Software can host a cadence but cannot decide priorities, and tools disappear (see the tooling landscape).

The practices are older than the label. Dates appear only where a source gives them.

Mental model: the company as a control loop (prioritise, fund, execute, measure, review, decide, adjust; see the reference architecture). BizOps keeps it turning fast enough that a problem surfaces in week three, not at quarter end.

The boundaries below are this Atlas’s editorial distinctions.

flowchart TB
  L["`Leadership:
  strategy, priorities`"] --> B
  R["`RevOps:
  revenue forecast`"] --> B
  A["`AnalyticsOps:
  governed KPIs`"] --> B
  F["`FinOps, DevOps:
  tech cost and flow`"] --> B
  B["`BizOps: cadence, KPI tree,
  reviews, decision log`"] --> P["Company plan and OKRs"]
  B --> D["Reallocation decisions"]
  D --> P
  P --> PO["`PortfolioOps:
  investment choices`"]
  P --> PE["`PeopleOps:
  headcount plan`"]
  P --> PR["`ProductOps and
  functions: team goals`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class B,P,D core
  class L,R,A,F,PO,PE,PR neutral

No official BizOps charter exists; this one is this Atlas’s proposal. Mission: every week, the leadership team knows whether the company is on course for its few priorities, and moves resources quickly when it is not.

1. Few priorities, public. Google’s re:Work guide suggests three to five objectives with about three key results each, public inside the organisation.^[19] If managers cannot name the priorities, nothing else works.^[6]
2. Manage inputs, report outputs. Amazon: “focusing our energy on the controllable inputs to our business is the most effective way to maximize financial outputs over time”.^[16]
3. Separate what you want, what you expect and what you fund. Statoil split the budget’s three purposes;^[15] Beyond Budgeting asks for forecasting that is “lean and unbiased”.^[13]
4. Every target has a cap or a counter-metric. “When a measure becomes a target, it ceases to be a good measure.”^[22]
5. Reviews end in decisions, each with one decider and a log entry (“Ideally, there should only be one decider for each decision”, in Bain’s RAPID guidance).^[23]
6. Process serves outcomes. Amazon’s 2016 letter: “do we own the process or does the process own us?”^[24]
7. Rhythm follows the business, “around business rhythms and events; not around the calendar year only”.^[13]

Non-goals: owning other functions’ numbers; reports nobody acts on; grading individuals (“OKRs are not synonymous with employee evaluations”).^[19]

Seven artefacts recur: company priorities; a KPI tree that reconciles to the books; OKRs or goals with owners; a plan holding target, forecast and resource envelope separately; a review calendar with pre-reads; a decision log and initiative register; a headcount plan. Technology-heavy companies add technology investment by value stream (Case 5). The KPI tree is the block most often missing:

flowchart TB
  MRR["MRR = customers x ARPA"] --> ARPA["`Average revenue
  per account`"]
  MRR --> C["`Customers at quarter end:
  start + new − churned`"]
  C --> S["`Starting
  customers`"]
  C --> N["`New customers:
  leads x conversion`"]
  C --> X["`Churned:
  start x churn rate`"]
  N --> LD["`Qualified
  leads`"]
  N --> CV["`Lead-to-customer
  conversion`"]
  X --> CR["`Churn rate
  per quarter`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class MRR,C,N,X core
  class ARPA,S,LD,CV,CR decision

Two rules: the calculated top node must equal the number the controller reports from the books, or the tree is wrong; and each leaf needs one owner, so a variance has an address.

The leadership team decides; the BizOps lead runs the cadence, edits pre-reads and keeps the decision log; function leaders own their KPIs and diagnoses; finance owns the books (the controller) and the budget and financial forecast (FP&A); RevOps supplies the revenue forecast; AnalyticsOps owns metric definitions; PeopleOps turns the headcount plan into hiring. In a small company a chief of staff often holds the BizOps role. R responsible, A accountable, C consulted, I informed.

Skills (this Atlas’s proposal). Notes of the Biz Ops Con 2017 keynote panel record “Communication and problem solving are the top skills in business operations”;^[17] El-Baba describes generalists who can “herd cats”.^[1]

The cadence has a yearly life cycle (Amazon’s version is in Case 1).

flowchart TB
  S["`Q3: strategy refresh
  leadership team`"] --> A["`Q4: annual plan
  BizOps with finance`"]
  A --> Q["`Each quarter: OKRs
  and initiatives, BizOps`"]
  Q --> R["`Weekly and monthly: run
  KPI owners, BizOps`"]
  R -->|"quarter's grades"| Q
  R -->|"year's results"| S
  R -->|"decision log, calibration"| I["`Twice a year: improve
  the cadence, BizOps lead`"]
  I -.->|"changed forums and rules"| R
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class S,A,Q,R core
  class I neutral

• Pre-reads, read in the room. Amazon replaces slides with “narratively structured six-page memos” read silently at the start of each meeting.^[25] Shorter memos work if discussion starts from the same facts.
• Decision rights in advance. RAPID or a simpler rule; Bain says successful adopters start with “high-value or high-frequency decisions”.^[23]
• Event triggers. Agreed thresholds (a leading KPI outside its band for two weeks) call an out-of-cycle review, so the calendar does not delay a decision.
• Top KPIs owned at the top. At GitLab, “A function’s KPIs are owned by the respective member of e-group” (its executive group).^[21]

For a business function the architecture is organisational: layers of artefacts with a feedback path that changes the plan.

flowchart TB
  S["Strategy: 3-5 priorities"] --> PL["Annual plan: target, forecast, envelope"]
  PL --> Q["Quarterly OKRs and initiatives"]
  Q --> E["Execution in functions"]
  E --> M["Measurement: KPI tree on governed data"]
  M --> R["Reviews: weekly, monthly, quarterly"]
  R --> DL{"Decision needed?"}
  DL -->|"yes"| DEC["Logged decision: reallocate, stop, escalate"]
  DL -->|"no"| M
  DEC --> RF["Reforecast and new envelope"]
  RF --> Q
  DEC -.->|"yearly"| S
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class PL,Q,M,R,RF core
  class DL,DEC decision
  class S,E neutral

Each layer refreshes at its own speed (see the planning year); owners are in the RACI.

The exception paths matter more than the happy path, because cadences fail where nobody owns the next step.

flowchart TB
  A["Weekly review: KPI outside its band 2 weeks"] --> B["Owner diagnoses with the KPI tree (5 working days)"]
  B --> C{{"Cause and options ready?"}}
  C -->|"no"| E["Escalate: monthly review assigns help"]
  E --> B
  C -->|"yes"| D["BizOps pre-read: options, cost, recommendation"]
  D --> F{{"Within leadership authority?"}}
  F -->|"no"| G["Board or budget holder decides"]
  F -->|"yes"| H["One decider decides; decision logged"]
  G --> H
  H --> I["FP&A reforecasts; envelope changed"]
  I --> J["Effect tracked in the next reviews"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class A,B,D,H,I,J core
  class E,G risk
  class C,F decision

Time boxes: flag the same day; diagnose in 5 working days; pre-read in 3 more; decide at the next review or out of cycle; reforecast within 5 working days; log the observed effect one to three months later.

Playbook: an annual plan in six steps. (1) Close the strategy refresh with three to five priorities and a list of what stops. (2) Update the KPI tree and reconcile it to last year’s books. (3) Collect each function’s forecast before setting any target (SalesOps tests the revenue target against sales capacity). (4) Set targets per priority, each with a cap or counter-metric. (5) Size envelopes and the headcount plan from the forecast and the priorities, not last year plus a percentage (this page’s rule; see the judgement call). (6) Publish, with owners and the first quarterly review date.

Weekly review rule. Discuss only exceptions and end each with an owner and a date. EOS keeps its weekly scorecard to “a handful of Measurables”;^[26] this page’s rule of thumb is at most fifteen to twenty tree leaves in the weekly view.

El-Baba’s other half of BizOps work is “strategic projects” (“big rocks” such as a pricing or packaging change, a churn reduction strategy or a new product launch), with time split evenly between these and the rhythm of business.^[1] The cadence finds problems; a project solves one that no single function owns. The method is this Atlas’s proposal.

Case 4 shows steps 1–4 in a real company. A project without a decision owner produces analysis nobody uses.

No standard, regulation or certification governs BizOps. These methods are compatible tools; none is mandatory, and several are trademarks of the firms that sell training in them.

The BizOps Manifesto is four values and 14 principles, not a method: it says “Software and product investments should be aligned to and measured against real business outcomes” but prescribes no practice.^[3] The academic BizDevOps proposal, where “Business, Development and Operations work together”, rests on one case study at a large reinsurance company.^[18]

Automation suits the mechanical parts: assembling the scorecard, flagging breaches, drafting variance commentary, summarising the decision log. Language models draft fluent text around wrong numbers as easily as right ones. Three rules: every generated number links to its governed source; the KPI owner signs the narrative; forecasts go only to approved services (compliance). The manifesto’s claim that decisions “must be augmented by advanced analytics and AI/ML”^[3] is an aspiration; accountability stays with a named person.

Assumptions (illustrative): a 200-person software company, a CEO and six function leaders, one BizOps lead, governed KPIs. The first artefact is the cadence itself, written down so anyone can see which forum decides what, and versioned like any other policy.

Example status: syntax-checked YAML, not executed (it is a description, not a program).

# cadence.yaml - the operating cadence of an illustrative 200-person company
owner: bizops-lead
reviewed: 2026-10-01          # review this file twice a year
forums:
  - name: weekly-metrics-review
    when: "Mondays, 45 min"
    attendees: [ceo, function-leaders, bizops-lead]
    input: "KPI tree leaves with bands, refreshed Sunday night"
    decides: "owner and due date for each exception"
    escalates_to: monthly-business-review
  - name: monthly-business-review
    when: "second Tuesday, 2 h"
    attendees: [ceo, function-leaders, bizops-lead, fpa-lead]
    input: "one pre-read per function, circulated 48 h before"
    decides: "reallocations within the leadership team's authority"
    outputs: [decision-log-entries, reforecast]
  - name: quarterly-business-review
    when: "first week of the quarter, half day"
    attendees: [ceo, function-leaders, bizops-lead, fpa-lead]
    input: "graded OKRs, initiative register, forecast calibration"
    decides: "next quarter's OKRs, initiative stops and starts"
triggers:
  - "a tree leaf outside its band for 2 consecutive weekly readings"
  - "forecast for the quarter moves by more than 5% in one month"
decision_rights:                 # reallocations between envelopes
  leadership_team_up_to_usd: 250000
  cfo_up_to_usd: 1000000
  above_that: board
  decider_per_decision: 1
records:
  decision_log: "shared folder, one entry per decision, never deleted"

The remaining artefacts are in the templates: a pre-read, a decision record, an initiative intake form and a KPI card.

Invented numbers; Python 3 standard library only (executed with Python 3.8.10 on 2026-10-18; use a supported release). No cost, no live system, 30–60 minutes each. Work in a new, empty folder.

Objective: walk the KPI tree from plan to actual, attribute the variance to drivers, and check that the tree reconciles to the number the controller reports (reported_actual). Prerequisites: Python 3; optionally, your own drivers’ plan and actual values.

1. Save the JSON below as kpi-tree.json and the script as kpi_tree.py.
2. Run python3 kpi_tree.py kpi-tree.json; echo $?.
3. Change reported_actual to 560000 and run again to see the reconciliation check fail.

{
  "metric": "MRR at quarter end",
  "reported_actual": 552760,
  "plan": {"start_customers": 1000, "leads": 2000, "conversion": 0.05,
           "churn_rate": 0.02, "arpa": 500},
  "actual": {"start_customers": 1000, "leads": 2200, "conversion": 0.04,
             "churn_rate": 0.025, "arpa": 520}
}

Example status: verified by execution (Python 3.8.10, 2026-10-18); the output below is the actual output.

"""Walk a KPI driver tree from plan to actual and attribute the variance.

Usage: python3 kpi_tree.py kpi-tree.json
Tree: MRR = customers x ARPA; customers = start + new - churned;
new = leads x conversion; churned = start x churn_rate.
Attribution substitutes one driver at a time (plan -> actual) in the
order of DRIVERS: each driver is valued with all earlier drivers
already at actual, so each interaction goes to the later driver.
Exit code 1 if the tree does not reconcile to the reported actual.
"""
import json
import sys

DRIVERS = ["leads", "conversion", "churn_rate", "arpa"]


def evaluate(d):
    new = d["leads"] * d["conversion"]
    churned = d["start_customers"] * d["churn_rate"]
    customers = d["start_customers"] + new - churned
    return {"new": new, "churned": churned, "customers": customers,
            "mrr": customers * d["arpa"]}


def main(path):
    with open(path) as f:
        tree = json.load(f)
    plan, actual = tree["plan"], tree["actual"]
    p, a = evaluate(plan), evaluate(actual)
    print(f"{'node':<12}{'plan':>12}{'actual':>12}{'var %':>8}")
    for k in ["new", "churned", "customers", "mrr"]:
        pct = 100 * (a[k] - p[k]) / p[k]
        print(f"{k:<12}{p[k]:>12,.0f}{a[k]:>12,.0f}{pct:>+8.1f}")
    print(f"\nAttribution of the {tree['metric']} variance:")
    current = dict(plan)
    before = p["mrr"]
    for drv in DRIVERS:
        current[drv] = actual[drv]
        after = evaluate(current)["mrr"]
        print(f"  {drv:<11}{after - before:>+10,.0f}")
        before = after
    total = a["mrr"] - p["mrr"]
    print(f"  {'total':<11}{total:>+10,.0f}")
    gap = a["mrr"] - tree["reported_actual"]
    if abs(gap) > 0.5:
        print(f"NOT RECONCILED: tree {a['mrr']:,.0f} vs reported "
              f"{tree['reported_actual']:,.0f} (gap {gap:+,.0f})")
        return 1
    print("Reconciled with the reported actual.")
    return 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Expected output (exit code 0):

node                plan      actual   var %
new                  100          88   -12.0
churned               20          25   +25.0
customers          1,080       1,063    -1.6
mrr              540,000     552,760    +2.4

Attribution of the MRR at quarter end variance:
  leads          +5,000
  conversion    -11,000
  churn_rate     -2,500
  arpa          +21,260
  total         +12,760
Reconciled with the reported actual.

Validation. The contributions sum to the total (+12,760) and the tree equals reported_actual. With 560000 the script prints NOT RECONCILED: tree 552,760 vs reported 560,000 (gap -7,240) and exits with 1.

What it teaches. A price rise (ARPA +4%), a one-off step in run-rate, hid two worsening drivers (runbook). Order matters, because each interaction goes to the later driver of the pair: with ARPA first, ARPA gives +21,600 and every customer driver changes (leads +5,200, conversion -11,440, churn -2,600). State the order, or average over orders when the bridge is contested.

Troubleshooting. KeyError: a name in DRIVERS is missing from plan or actual. A reconciliation gap: the tree misses a driver (discounts, refunds, currency) or a different period; fix the tree, not the report. Teardown: delete the folder.

Objective: catch OKR mistakes Google’s guide lists (activities instead of outcomes, no measure, too many objectives) and grade the set. Prerequisites: Python 3; optionally, your OKRs as CSV with these columns. ARR and GRR are annual recurring revenue and gross revenue retention (RevOps). The script treats 1.0 as a committed objective’s passing grade, this page’s rule: What Matters says only that one “is expected to have a passing grade”.^[8]

1. Save the CSV as okrs.csv and the script as okr_check.py.
2. Run python3 okr_check.py okrs.csv; echo $?.
3. Replace O1/KR3 with a measurable outcome (for example "Mid-market deals using the new pitch, count", start 0, target 40, current 26; keep the quotes, the text contains a comma), give O3/KR1 an owner, and run again.

obj,objective,type,kr,key_result,owner,start,target,current
O1,Win the mid-market,aspirational,KR1,Mid-market new ARR in USD k,cro,0,1500,1080
O1,Win the mid-market,aspirational,KR2,Mid-market win rate in %,cro,18,28,23
O1,Win the mid-market,aspirational,KR3,Help sales with new pitch deck,pmm,,,
O2,Keep customers we have,committed,KR1,Gross revenue retention in %,cco,88,92,92.4
O2,Keep customers we have,committed,KR2,Accounts with an exec sponsor,cco,40,120,95
O3,Make planning cheaper,committed,KR1,Days to close the quarterly plan,,30,15,15

Example status: verified by execution (Python 3.8.10, 2026-10-18); the output below is the actual output.

"""Lint and grade an OKR set exported as CSV.

Usage: python3 okr_check.py okrs.csv
Grade of a key result = progress from start to target, clipped to 0..1
(works for "lower is better" targets too). Objective grade = mean of
its gradable key results. Exit code 1 if any ERROR is found.
"""
import csv
import re
import sys
from collections import OrderedDict

ACTIVITY = re.compile(r"\b(consult|help|analy[sz]e|participate)\b", re.I)


def grade(row):
    try:
        s, t, c = (float(row[k]) for k in ("start", "target", "current"))
    except ValueError:
        return None
    if t == s:
        return None
    return max(0.0, min(1.0, (c - s) / (t - s)))


def main(path):
    with open(path, newline="") as f:
        rows = list(csv.DictReader(f))
    objs = OrderedDict()
    for r in rows:
        objs.setdefault(r["obj"], []).append(r)
    errors, warns = [], []
    if len(objs) > 5:
        warns.append(f"{len(objs)} objectives; re:Work suggests three to five")
    for oid, krs in objs.items():
        grades = []
        for r in krs:
            ref = f"{oid}/{r['kr']}"
            g = grade(r)
            if ACTIVITY.search(r["key_result"]):
                errors.append(f"{ref}: describes an activity, not an outcome")
            if g is None:
                errors.append(f"{ref}: no measurable start/target/current")
            else:
                grades.append(g)
            if not r["owner"].strip():
                errors.append(f"{ref}: no owner")
        if len(krs) > 5:
            warns.append(f"{oid}: {len(krs)} key results; aim for about three")
        mean = sum(grades) / len(grades) if grades else 0.0
        kind = krs[0]["type"]
        print(f"{oid} {krs[0]['objective']:<24} {kind:<13} grade {mean:.2f}")
        if kind == "committed" and mean < 1.0:
            warns.append(f"{oid}: committed objective graded {mean:.2f}"
                         " - review why the commitment slipped")
    for w in warns:
        print("WARN ", w)
    for e in errors:
        print("ERROR", e)
    return 1 if errors else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Expected output (exit code 1):

O1 Win the mid-market       aspirational  grade 0.61
O2 Keep customers we have   committed     grade 0.84
O3 Make planning cheaper    committed     grade 1.00
WARN  O2: committed objective graded 0.84 - review why the commitment slipped
ERROR O1/KR3: describes an activity, not an outcome
ERROR O1/KR3: no measurable start/target/current
ERROR O3/KR1: no owner

Validation. O1 = mean of 1080/1500 = 0.72 and (23 - 18)/(28 - 18) = 0.50, so 0.61; O3 (“lower is better”) grades 1.00. After step 3: exit code 0, O1 at 0.62, the WARN on O2 kept by design.

Troubleshooting. Text in start, target or current counts as not measurable: write percentages as plain numbers. The activity-word check is crude (“help” matches “Help centre visits”). Teardown: delete the folder.

Objective: separate three properties of a forecast that one accuracy number hides. Prerequisites: Python 3; twelve or more quarters of commit, 50/50 and best-case forecasts (estimates GitLab’s handbook defines^[21]) made at the same point in each quarter, and the actuals.

1. Save the CSV as forecasts.csv and the script as forecast_check.py.
2. Run python3 forecast_check.py forecasts.csv; echo $?.
3. Replace the data with your own; keep the forecast date fixed (for example, week 2 of each quarter).

quarter,commit,fifty_fifty,best_case,actual
2023-Q3,760,840,930,875
2023-Q4,800,880,970,860
2024-Q1,830,920,1010,965
2024-Q2,870,960,1050,1000
2024-Q3,900,1000,1100,1040
2024-Q4,950,1050,1150,1090
2025-Q1,1000,1100,1220,1135
2025-Q2,1050,1160,1280,1210
2025-Q3,1080,1190,1300,1230
2025-Q4,1120,1230,1350,1195
2026-Q1,1150,1270,1400,1310
2026-Q2,1200,1320,1450,1365

Example status: verified by execution (Python 3.8.10, 2026-10-18); the output below is the actual output.

"""Score a revenue forecast's accuracy, bias and calibration.

Usage: python3 forecast_check.py forecasts.csv
Columns: quarter, commit, fifty_fifty, best_case, actual (same units).
Error e = actual - forecast, p = 100 * e / actual (as in Hyndman and
Athanasopoulos, FPP3 section 5.8). Positive mean p = under-forecasting.
Calibration: a true 50/50 forecast is beaten about half the time. A
two-sided sign test gives the probability of a beat count at least
this lopsided, in either direction, if that were true.
Exit code 1 if that probability is below 0.05.
"""
import csv
import sys
from math import comb


def tail(n, counts):
    return sum(comb(n, k) for k in counts) / 2 ** n


def main(path):
    with open(path, newline="") as f:
        rows = [{k: (v if k == "quarter" else float(v)) for k, v in r.items()}
                for r in csv.DictReader(f)]
    n = len(rows)
    pct = [100 * (r["actual"] - r["fifty_fifty"]) / r["actual"] for r in rows]
    mape = sum(abs(p) for p in pct) / n
    mpe = sum(pct) / n
    beats = sum(r["actual"] > r["fifty_fifty"] for r in rows)
    below_commit = sum(r["actual"] < r["commit"] for r in rows)
    above_best = sum(r["actual"] > r["best_case"] for r in rows)
    upper = tail(n, range(beats, n + 1))   # P(X >= beats)
    lower = tail(n, range(0, beats + 1))   # P(X <= beats)
    p_two = min(1.0, 2 * min(upper, lower))
    print(f"quarters={n}  MAPE={mape:.1f}%  mean p (bias)={mpe:+.1f}%")
    print(f"actual above 50/50: {beats}/{n}  two-sided p={p_two:.3f}  "
          f"(P >= {beats}: {upper:.3f}, P <= {beats}: {lower:.3f})")
    print(f"actual below commit: {below_commit}/{n}  "
          f"above best case: {above_best}/{n}")
    if p_two < 0.05 and beats > n / 2:
        print("FLAG: beaten too often; the 50/50 behaves like a floor "
              "(under-forecast).")
        return 1
    if p_two < 0.05:
        print("FLAG: missed too often; the 50/50 behaves like a ceiling "
              "(over-forecast).")
        return 1
    print("OK: beat count consistent with a 50/50 forecast "
          "(small samples reveal only large biases).")
    return 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Expected output (exit code 1):

quarters=12  MAPE=3.5%  mean p (bias)=+2.6%
actual above 50/50: 10/12  two-sided p=0.039  (P >= 10: 0.019, P <= 10: 0.997)
actual below commit: 0/12  above best case: 0/12
FLAG: beaten too often; the 50/50 behaves like a floor (under-forecast).

Validation. Absolute percentage errors sum to 42.3 (MAPE 42.3 / 12 = 3.5%), signed ones to +31.7 (bias +2.6%). For a true median, ten or more beats in twelve has probability (66 + 12 + 1) / 4,096 = 0.019; two-sided, 0.039. With every actual 7% lower, the script flags the opposite failure (“behaves like a ceiling (over-forecast)”) and exits with 1.

What it teaches. A 3.5% error looks excellent, but the “median” was beaten ten times in twelve: a floor that misleads anyone planning hiring or cash on it. An over-optimistic 50/50 fails the other way and commits money to revenue that will not arrive. The test shows a pattern, not a motive (caution, a forecast doubling as a target as in what Google’s guide calls sandbagging,^[19] or pressure to match the target): treat a flag as a reason to ask. Small samples hide bias: the last eight quarters alone (seven beats) give p = 0.070 and print OK, since with eight quarters only 0 or 8 beats reach the 5% level.

Troubleshooting. ZeroDivisionError or huge percentages: an actual is zero or near zero, where percentage errors are undefined or extreme;^[33] use absolute errors for such series. Teardown: delete the folder.

Cases 1–4 are documented by the organisations or people involved; Case 5 is an illustrative scenario.

Amazon’s 2009 letter: goal setting “begins in the fall, and concludes early in the new year”; for 2010 it produced “452 detailed goals with owners, deliverables, and targeted completion dates”, reviewed “several times per year”, 360 of them with “a direct impact on customer experience”. Net income, gross profit or margin and operating profit were “not used once”.^[16] Lesson: review the controllable leaves and let the financial root follow. Trade-off: a long planning season and a goal list too long for a small company.

Bjarte Bogsnes, then Statoil’s vice president for performance management development, describes the budget as one number with three conflicting purposes: a target (“What we want to happen”), a forecast (“What we think will happen”) and resource allocation. Statoil separated them: relative targets where possible, an unbiased forecast, and allocation that is “Dynamic - no annual allocation” and “Event driven”.^[15] Trade-off: three processes for finance to run. The judgement call works through this choice.

GitLab’s public handbook names “run-rate revenue” as its North Star metric and lists ten top KPIs, each marked leading or lagging and reviewed “at each quarterly meeting of the Board of Directors”. “KPIs can only exist at the Company (e.g. GitLab) layer if it exists at the functional layer”. Each KPI names its canonical source, a target or cap, and plan, commit, 50/50, best-case, forecast and actual values.^[21] Trade-off: many layers to maintain. In March 2026 GitLab moved its OKR process to its internal handbook.^[34]

A former member of LinkedIn’s BizOps team describes delivering QBRs to a regional head of sales for the Talent Solutions business. When enterprise churn ran above plan “for a handful of consecutive quarters”, BizOps led an initiative to diagnose the root causes and recommend action to the executive team.^[1] The account gives no numbers or outcome; it shows rhythm work surfacing a problem that becomes a strategic project, which an exception rule like the workflow’s would start sooner.

The company’s own KPIs live in its KPI tree: the MRR driver model of Building blocks, walked in Lab 1 and the runbook. The metrics below measure the operating system itself; they are this Atlas’s proposals unless a source is given.

Worked calculation (illustrative). Of 40 managers surveyed, 14 list all three priorities: recall 14 ÷ 40 = 35%. Seven decisions this quarter took 2, 3, 3, 5, 8, 12 and 21 working days: median latency 5 days; check the 21-day case’s decision rights. Of 24 decision actions due, 18 were done on time: follow-through 75%. Lab 3’s forecast is accurate (MAPE 3.5%), biased (+2.6%) and badly calibrated (10 beats in 12) at once.

Targets and traps. Set targets after two cycles of baseline data, never on the average OKR grade: in this page’s view that invites what Google’s guide calls sandbagging (OKRs met without the team’s full capacity).^[19] Vanity metrics: OKRs written, meetings held, dashboards built. Surveys are self-reported, and latency is only as honest as the log.

• Data quality. The KPI tree must reconcile to the books (Lab 1) and each KPI must come from one governed definition (see AnalyticsOps on two numbers for one metric).
• Inside information. In a listed company, forecasts, unreleased results and plans can be material non-public information. In the United States, Regulation FD addresses “the selective disclosure by issuers of material nonpublic information”;^[35] other jurisdictions have their own regimes. Give forecast files named readers, log access, follow the insider and disclosure policies, and ask counsel before sharing outside (this is not legal advice).
• People data. Headcount plans can name individuals, salaries and reorganisations: least privilege, and the rules of PeopleOps and PrivacyOps.
• Target-driven misconduct. On 2016-09-08 the US Consumer Financial Protection Bureau fined Wells Fargo $100 million. The bureau said employees, spurred by sales targets and compensation incentives, had opened roughly 1.5 million deposit accounts and applied for roughly 565,000 credit card accounts that customers may not have authorised.^[36] Controls belong in the cadence: a counter-metric per target (here, unused accounts and complaints), sample checks of how targets are met, a safe reporting channel, and rewards for shared success rather than fixed performance contracts.^[13] Programme-level risk belongs to RiskOps and ComplianceOps.

The cadence costs leadership time, the scarcest resource a company has. Worked calculation (illustrative):

The attendee counts follow cadence.yaml (eight in the weekly review; the FP&A lead joins the others). At an illustrative loaded cost of USD 150 an hour, that is about USD 151,000 a year before the BizOps lead’s salary. Cut or merge any forum that produced no decision or owner assignment in three consecutive sessions. Environmental impact is not material; the sustainability issue is people: Statoil listed the traditional budget as “Very time consuming”.^[15]

Twice a year the BizOps lead runs the health check on the cadence itself, adds a sample of hit targets checked against their counter-metrics, and reports the evidence to the leadership team. Internal audit or a non-executive director can review the same evidence.

1. Detect (day 0). The rule “a tree leaf outside its band for two weekly readings” fires for conversion and churn although the root is green. BizOps opens an exception per leaf, with owners (sales for conversion, customer success for churn).
2. Contain (days 0–1). Do not present the beat as momentum: mark the quarter’s forecast “under review” and do not extrapolate the price step as recurring growth.
3. Diagnose (days 1–5). Attribution: leads +5,000, conversion −11,000, churn −2,500, ARPA +21,260. The price rise is a step change in run-rate: it persists while the customers stay, but it happened once; conversion and churn compound. Owners test whether the price rise caused part of both; the pricing decision had no counter-metric to show it.
4. Decide (by the monthly review). Options: keep the price and fund a churn programme; roll back the price for one segment; or accept the trade-off and lower the customer-count target. One decider (the CEO, the CFO in an Agree role) chooses and logs the expected effect.
5. Re-plan and verify. Within 5 working days FP&A reforecasts the next two quarters: the new ARPA level stays in, no further price step is assumed, and conversion and churn run at current rates unless the decision changes them. The log records the observed effect one to three months later.
6. Prevent. Pricing decisions get counter-metrics (churn and conversion in the affected segment); leaf-level bands stay in the weekly review; the pre-read template asks whether a beat is a one-time item, a step change or a trend.

• “Cascade every objective to every team.” Beyond Budgeting warns against “fixed and cascaded targets”;^[13] Google’s guide says not every organisational OKR needs to appear in every team’s OKRs.^[19]
• “OKR grades decide bonuses.” Google’s guide says OKRs “are not synonymous with performance evaluation”, though they can summarise what someone worked on;^[19] What Matters calls OKRs “divorced from compensation”;^[8] Beyond Budgeting rewards shared success, not fixed performance contracts.^[13] Tie pay to grades and grades will be managed; if pay must reflect goals, use a holistic review of how results were achieved.
• “The annual plan is a contract.” Statoil’s list of budget problems includes “Assumptions quickly outdated”.^[15]
• “We followed the process.” Amazon’s 2016 letter calls this “process as proxy”.^[24]
• “The BizOps team will fix it.” A team that owns every problem becomes an errand service. One practitioner notes that “incubation” teams either become embedded teams or dissolve into the organisation.^[1]

Invest in a deliberate cadence, and later a BizOps role, when several functions must hit shared outcomes; leadership meetings reconcile numbers instead of deciding; managers cannot name the priorities; or the plan is stale by mid-year.

Do not build a BizOps team when:

• The company is small and already decides weekly. It needs a one-page scorecard and an owner, not a function.
• The problem is strategy. Without a choice of where to compete, a cadence only reviews the indecision faster.
• The problem belongs to a neighbour: conflicting numbers (AnalyticsOps), funnel leaks (RevOps), investment choices (PortfolioOps).
• The company is in a crisis. A cash or reputational crisis needs a crisis team deciding daily; restart the cadence afterwards.

Hidden responsibilities. A BizOps lead has influence, not line authority: without the CEO’s visible backing the cadence becomes optional, and the role can become a bottleneck.

flowchart TB
  Q1{{"Do several functions jointly own outcomes that are being missed?"}}
  Q1 -->|"no"| A1["No team: one owner and a one-page scorecard"]
  Q1 -->|"yes"| Q2{{"Is the root cause strategy, data or the funnel?"}}
  Q2 -->|"no"| Q3{{"Does an existing forum already decide weekly?"}}
  Q2 -->|"yes"| A2["Fix that first: leadership, AnalyticsOps, RevOps"]
  Q3 -->|"yes"| A3["Part-time owner: CEO office or finance"]
  Q3 -->|"no"| Q4{{"Do 3 or more leaders each need a dedicated partner?"}}
  Q4 -->|"no"| A4["One BizOps lead reporting to the CEO"]
  Q4 -->|"yes"| A5["Embedded BizOps partners per function, central lead"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class A3,A4,A5 core
  class A1,A2 neutral

The thresholds are judgement calls, not research findings. The embedded and single-lead forms follow a practitioner’s description.^[1]

This is this Atlas’s model, not an industry standard. Levels describe the company’s cadence, not a team’s size.

For a company of roughly 100–500 people starting at level 1 or 2, with a BizOps lead (or a part-time owner) and the CEO’s sponsorship.

Quick wins: a single published priority list; a decision log; cancelling one forum that decides nothing. Dependencies: governed KPI definitions (AnalyticsOps) and finance’s agreement to separate forecast from target.

Quick start

• Three to five company priorities, published, each with an owner
• A KPI tree that reconciles to the books, with one owner per leaf
• A written cadence: forums, inputs, outputs, decision rights, triggers
• A decision log that everyone in leadership can read

Before a business review

• Pre-reads circulated at least 48 hours before; numbers link to governed sources
• Each agenda item says what is to be decided and who decides
• One-time items, run-rate step changes and trends separated
• Last review’s decisions and their effects listed first

Before setting a target

• The forecast for the same measure exists and differs from the target only by choice
• A cap or counter-metric is named, with how it will be checked
• The target is not tied to individual pay without a review of side effects
• The owner can influence the measure in the period

Twice-yearly cadence health check

• Decision latency, follow-through and reversals reviewed
• Forecast calibration and bias (Lab 3); OKR grades (Lab 2), committed misses explained
• Priority recall survey repeated; result compared
• KPIs nobody used last quarter removed from the weekly view

Template status: illustrative; adapt the fields to your company.

REVIEW PRE-READ (max 2 pages; circulate 48 h before)
Forum / date:              Author:              Decider:
1. Decision requested (one sentence), or "for information only"
2. Where we are: KPI tree leaves vs plan and forecast (link to source)
3. What changed and why: one-time item (e.g. a one-time fee), step change
   (e.g. a price rise) or trend
4. Options (2-3): cost, expected effect on which KPI, risks
5. Recommendation and the counter-metric we will watch
6. Open actions from earlier decisions: owner, due date, status

DECISION RECORD                         ID: DEC-2026-041
Date:            Forum:               Decider (one person):
Recommend:       Agree (if any):      Input:            Perform:
Decision:
Options considered and why rejected:
Expected effect: KPI ______ moves from ______ to ______ by ______
Resource change: envelope ______ from ______ to ______
Review date:     Observed effect (filled in at review):

INITIATIVE INTAKE (cross-functional)
Problem (evidence, with the KPI tree leaf it affects):
Outcome KPI and target; counter-metric:
Why no single function can fix it:
Owner:            Team (functions, % time):         End date:
Stop rule (when we stop if it is not working):
Cost (people, money) and what is deprioritised to fund it:
Approved by:      Date:      Review forum:

KPI CARD (one per top KPI; the definition itself lives with AnalyticsOps)
KPI:                  Leading/lagging:        Tree node:
Owner (accountable):  Definition link:        Canonical source:
Plan:      Target:      Cap / counter-metric:      Band for weekly review:
Commit:    50/50:       Best case:                 Forecast date:
Who may see actuals:  Who may see forecasts:

We have strong SalesOps and MarketingOps teams. Do we still need BizOps? Perhaps not. Those teams run day-to-day operations; BizOps would advise their leaders on strategy.^[1] If the CEO already runs a cadence that decides and shared outcomes are rarely missed, a part-time owner is enough (see the decision framework).

Is BizOps just FP&A with a new name? It often sits in or next to finance, but FP&A owns the budget and financial forecast (the books belong to accounting, under the controller), while BizOps owns the operating rhythm, non-financial drivers and strategic projects. In small companies one person may do both.

Do we need OKRs? No. OKRs suit goals for change; a scorecard or KPI tree suits health measures. Many companies use both.

Does the BizOps Manifesto matter? As history, yes: it stated the aim of tying technology investment to business outcomes. As a method, no: it lists values and principles without practices, and its domain now redirects to Broadcom’s product pages.^[3][5]

When should we hire the first BizOps person? When leaders spend more time assembling and reconciling information than deciding, and no existing role can fix that. One attendee’s notes of the Biz Ops Con 2017 keynote panel record a first hire “at about 50–100 people”;^[17] that is one data point, not a rule.

• Event-driven cadence and rolling forecasts (established in some companies). See Statoil (Case 2); GitLab uses a “rolling 4 quarter forecast”.^[21] No source found for this page measures how common this is.
• Linking technology investment to outcomes (active, vendor-led). Flow metrics show where engineering capacity goes;^[31] BizDevOps argues for responsibility “from business over development to operations”.^[18] Attribution stays approximate.
• AI in planning (marketing ahead of evidence). Planning vendors advertise AI agents;^[29] this page found no independent evidence of their effect on decision quality. Use them for drafts and scenarios, with the controls in Automation and AI.

• One day: this page’s first three parts; Google’s OKR guide;^[19] GitLab’s KPI page.^[21]
• One week: the three labs on your own data; your company’s KPI tree, reconciled; a cadence contract for one function.
• Thirty days: one quarterly cycle with pre-reads and a decision log; the priority recall survey; a calibration review with finance.
• Advanced: Beyond Budgeting and the Statoil case;^[13][15] RAPID;^[23] hoshin kanri.^[9]
• Portfolio projects: a reconciling variance bridge for a listed company’s reported segments; a calibration study of its guidance against reported results.

Option A: one number. The plan figure is the target, the forecast and the basis for allocating money: simple, familiar, and it looks accountable. Option B: three numbers. An ambitious target; an unbiased forecast with commit, 50/50 and best-case values; and resource envelopes released in tranches at decision gates, with the approved budget as their ceiling. Statoil governs allocation through “KPI targets, mandates, decision gates”;^[15] sizing each envelope from the forecast, not the target, is this page’s addition.

flowchart TB
  subgraph A["Option A: one number"]
    N["Plan figure"] --> T1["Target"]
    N --> F1["Forecast"]
    N --> R1["Money allocated up front"]
  end
  subgraph B["Option B: three numbers"]
    T2["Target: what we want"]
    F2["Forecast: what we expect"] -->|"sizes (this page)"| R2["Envelope: released at decision gates"]
  end
  A ~~~ B
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class N,T1,F1,R1 risk
  class T2,F2,R2 core

How to decide. Option A fails predictably: an ambitious figure commits money against revenue that will probably not arrive; a figure negotiated down is a sandbagged forecast, and pay tied to beating it rewards the floor Lab 3 detects. Statoil’s slide puts it as “Same number – conflicting purposes”;^[15] GitLab keeps separate plan, commit, 50/50 and forecast values for one KPI.^[21]

Assumptions and uncertainty. No source found for this page compares the options in a controlled way; the evidence is case descriptions. Option B needs finance to run three processes and leaders who treat a forecast below target as information, not disloyalty. Lenders and boards may still require a budget, which is why B keeps it as the ceiling.

A defensible choice. Adopt B in stages: for two quarters, ask sales for a 50/50 forecast separate from the target and measure its calibration; keep the approved budget as the ceiling; release discretionary spending quarterly. Revisit after eight quarters, and treat the calibration result as indicative until there are twelve.

After this page you should be able to: explain the three meanings of BizOps and its boundaries; design a cadence with decision rights; build a reconciling KPI tree and bridge; grade OKRs; test a forecast for bias and calibration; scope a strategic project; and decide whether, and in which form, to staff BizOps.

“BizOps” is a label in search of a definition. Underneath its three uses is an old, real problem: strategies fail between departments, and between the plan and the quarter.

What fixes it is a working loop, not a team name. One accountable person and a spreadsheet can run that loop; a BizOps team earns its place when the loop, and the projects it surfaces, need more care than the leadership team can give. Judge it by its decisions, and by whether next quarter surprises you less.

All sources were opened on 2026-10-18; footnotes marked 2026-10-23 were reopened that day. Product facts are as of October 2026.

Further reading (books named by the sources above, not opened for this page): Doerr, Measure What Matters; Grove, High Output Management; Kersten, Project to Product.

Changelog. 2026-10-18, r0: first draft (research, ledger, three labs executed, six diagrams); not yet independently reviewed. 2026-10-19, r1: independent review (4 major, 16 minor findings) answered: price rise as a run-rate step; two-sided Lab 3 test; controller versus FP&A; strategic projects, skills and the X Ops boundary; attribution, source and diagram fixes. 2026-10-23, post-score polish: planning-year lifecycle diagram added; Metrics part links back to the Lab 1 driver model; manifesto, GitLab KPI, Emergence, ValueOps, re:Work and Viva Goals sources reopened (no change needed); repetitions cut to stay in band.