Paige
Paige is the incident and on-call expert on your team — she runs incidents as a job. Zimac is a chief-of-staff for an engineering leader, and the leader is usually not the one holding the pager. Paige is: she owns command, comms and hygiene — who's IC, what the exec update says, whether last quarter's postmortem actions actually got done, and how hard on-call is chewing up the team. Her favorite question: "what's the customer impact, and who's running this right now?"
Paige commands; she doesn't debug. Mid-incident, "what broke, which deploy, what's the metric doing" is Cody's job — the observability and root-cause work. Paige runs the incident around that: severity from customer impact, roles, the exec update, the cadence, the follow-through. She consults Cody for the telemetry and leads with the decision — declare a SEV1, page the on-call DBA, first exec update goes out in ten minutes — not a diff or a dashboard.
⚑ Commands incidents
Severity from customer impact, the IC / comms / ops / scribe roles, declare-or-not, and a war-room checklist.
⚑ Writes the comms
Internal and status-page scaffolds, cadence by severity, stakeholder lists, and a 3-line exec summary.
⚑ Scores postmortems
Blameless scaffolds with a completeness score, 5-whys structure, and action-items flagged for owner and date.
⚑ Reads paging live
With a paging tool connected: who's on-call now, open alerts, current incidents — acting only with approval.
Who Paige is#
Paige is a staff-level incident commander and reliability program lead who thinks in terms of customer impact, who owns what, and what happens after the page clears. Her audience is an engineering leader who is accountable for reliability but rarely the person typing in the channel — so she leads with the decision ("this is a SEV1: checkout is down for all EU customers; declare and page now"), separates what needs a call from what can wait, and keeps the incident moving instead of narrating it.
The boundary she's careful about: Paige commands the incident; Cody investigates it. The moment the question turns to "what actually broke, which deploy shipped it, what is the error rate doing," that's Cody's observability and root-cause work — Paige pulls him in for the telemetry rather than guessing at it. She does not read diffs or dashboards. Historical "why did this break last quarter" archaeology is Cody's too, and the observability stacks (Datadog, Chronosphere, Grafana) are his — she consults him mid-incident and keeps her hands on command, comms and follow-through.
Working with Paige#
Bring her the situation and ask for the call. Describe what's happening and she'll classify it, tell you whether to declare, and name the roles to fill — or paste a rough timeline and she'll turn it into a postmortem. When she's missing the one thing that changes the answer — the actual customer impact, who's already responding — she asks that single question rather than guessing. Connect a paging tool in Settings and she reads the live rotation instead of asking who's on-call.
Incident command#
When something is on fire, Paige runs the command layer. She classifies severity from customer impact through the leader's lens — how many customers, which surface, is it degraded or down, is there data loss or a security angle — not from how loud the channel is. She names the incident roles and who should hold each: IC (incident commander, runs the response), comms (owns updates in and out), ops (drives the technical work with Cody's investigation feeding it), and scribe (keeps the timeline). She gives you a clear declare-or-not decision and an escalation path — who to pull in, when to wake someone, when to page the next tier.
Status & exec comms#
Half of running an incident is telling people about it. Paige drafts the comms that leaders dread writing under pressure: internal status updates for the channel and public status-page scaffolds for customers, both structured so you fill in specifics and go. She sets the update cadence by severity — a SEV1 gets an update every 30 minutes even when there's "nothing new," a SEV2 less often — so stakeholders never wonder if it's still being worked. She builds the stakeholder notification list (who hears about this, at what severity — support, leadership, legal, the affected customer team) and writes the 3-line exec summary: what's impacted, what we're doing, when the next update lands.
Blameless postmortems#
The incident ends; the learning is where most teams drop the ball. Paige builds a blameless postmortem scaffold and scores it. She gives it a deterministic completeness score across the dimensions a good postmortem needs — timeline, customer impact, detection, response, root cause (from Cody's investigation), contributing factors, and action items — so you see at a glance where it's thin. She structures the analysis as 5-whys / contributing factors that stay systemic: the gap in the alert, the missing runbook, the review step that didn't catch it — never naming an individual as the fault. And she runs action-item tracking that flags any follow-up with no owner or no due date as not-yet-real.
On-call health#
On-call is a tax on the team, and Paige does the math on whether it's affordable. She looks at page load — how many pages per rotation, how many after hours, how many actually actionable versus noise — and the night-page count that quietly burns people out. She checks rotation fairness (is one person absorbing most of the pages), coverage gaps (holes where nobody is clearly on the hook), and escalation-policy sanity (does the second tier actually get reached before a page goes unanswered). The question underneath all of it: is on-call sustainable, or is it quietly costing you the team?
Incident metrics#
Paige tracks the program-level numbers that tell you whether reliability is getting better or worse. MTTA and MTTR (how fast you acknowledge and resolve), the severity mix (are SEV1s trending up), and the recurring themes across incidents — the part that catches real problems. Ask "what did the last three SEV1s share" and she looks for the common thread — the same subsystem, the same class of change, the same missing guardrail — instead of treating each incident as a one-off. She also does the error-budget and reliability math: how much budget an incident burned, whether an SLO is at risk, what the trend implies.
Live paging#
Connect a paging tool in Settings — PagerDuty, incident.io, Rootly or Opsgenie — and Paige stops asking and starts reading the real thing. Read-first, she'll tell you who's on-call right now across every schedule or one rotation, the open alerts and current firing state, and the current incidents with their severity and responders — grounded in what the tools return, never guessed. She uses this to answer the questions command actually needs: who do I escalate to, is this already paged, what's open.
Action with approval. Paige can also act — acknowledge an alert, escalate to the next tier — but every consequential action runs through the app's one-time approval: she shows you the exact action she'd take and it happens only when you confirm. Reads are live and free; writes stop for your click.