Eng Status Rollup

Eng Status Rollup

Execs do not need a feature list. They need three answers: are we on track, what might go wrong, and what do you need from us? A rollup that buries those answers under activity logs trains leadership to skim it - and then the one week the update contains a real red flag, nobody reads it. Everything in this skill defends the 90-second scan.

Operating procedure

Step 1: gather inputs

• The raw material: standup notes, sprint board, incident log, whatever exists for the period since the last update.
• The last rollup sent, so claims stay consistent - a risk that silently disappears without a resolution line destroys credibility faster than the risk itself would have.
• The audience (direct exec, VP group, company-wide) and the milestone or date the team is publicly committed to.
• Anything the manager knows but hasn't written down; ask directly "what are you worried about this week?" - the real risk is usually in the answer, not the ticket system.

If a claim is unverified ("I think the migration is on schedule"), label it as unconfirmed rather than rounding up to green.

Step 2: write Progress - outcomes, max 4 bullets

Lead with outcomes, not activities. "Auth service is live for 20% of users" beats "we finished the auth service work." Translate internal metrics into milestone language - velocity numbers require context an exec doesn't have. If nothing shipped, say so in one sentence with the reason; a padded progress section reads as exactly what it is. Hard cap: 4 bullets. The fifth-most-important thing this week is, by definition, not exec-relevant.

Step 3: write Risks and Blockers

Every risk gets four fields on one or two lines: description, likelihood (high / medium / low), impact if it materializes, and the current mitigation. Do not soft-pedal to look in control - the rollup's entire credibility budget is spent on raising real issues before they blow up. A status report with no risks is almost always missing something; if the week genuinely has none, write "No new risks; [previous risk] resolved by [what happened]" so the empty section is visibly deliberate. Any risk from last week's rollup must reappear as either still-open (with updated mitigation) or explicitly closed.

Step 4: write Asks - max 2

An ask is a specific decision or resource, with a named decider and a response-needed-by date. "We need more headcount" is not an ask. "Approval to hire 1 senior backend engineer in Q3 to hold the platform migration date - decision needed from [name] by July 1" is an ask. More than 2 asks per update means prioritization hasn't happened yet - do it before sending, not in the exec's inbox. If there are no asks, write "No asks this week."

Step 5: decide on Looking Ahead

Add a fourth section only when a significant decision point, launch, or external dependency lands in the next two weeks, and cap it at 2-3 bullets. Do not add it by default - a standing Looking Ahead section becomes the place where the real news hides in future-tense optimism.

Step 6: pressure-test and send

Read it as the busiest recipient: scannable in under 90 seconds? If not, cut - don't compress. Replace jargon and undefined acronyms. Send in writing before any verbal sync so recipients arrive having read it; the meeting is for discussing the asks, not for narrating the update.

Template

ENG ROLLUP - [FILL: team] - week of [FILL: date]
Status vs. [FILL: committed milestone]: ON TRACK / AT RISK / OFF TRACK

PROGRESS (max 4)
- [FILL: outcome, not activity - what changed for users/systems]
- [FILL]
- [FILL]

RISKS & BLOCKERS
- [FILL: risk one-liner] - likelihood: [FILL: H/M/L] - impact: [FILL: what breaks
  or slips] - mitigation: [FILL: what we're doing about it now]
- Carried from last week: [FILL: risk] - [FILL: still open + change / CLOSED: how]

ASKS (max 2)
- [FILL: specific decision or resource] - decider: [FILL: name] - needed by: [FILL: date]

LOOKING AHEAD (only if a decision/launch/dependency lands within 2 weeks; max 3)
- [FILL]

Worked contrast

Bad progress bullet: "Team continued working on the billing migration and made good progress; several PRs merged."

Good progress bullet: "Billing migration: 40% of invoices now generated by the new system (target: 100% by Aug 15); zero discrepancies in reconciliation so far."

The bad version reports effort and forces the exec to ask the follow-up. The good version reports position against the committed date and pre-answers the only question that matters.

Deliverable

Produce a written rollup containing: a one-line status against the committed milestone, at most 4 outcome-phrased progress bullets, every risk with likelihood/impact/mitigation plus the disposition of last week's risks, at most 2 asks each with a decider and a date, and Looking Ahead only when the two-week trigger applies - the whole document readable in under 90 seconds.

Do NOT

• Do not list activities ("worked on", "continued", "made progress") - every progress bullet states an outcome or a position against a date.
• Do not omit the risks section or leave it vague to look in control; a no-risk rollup reads as a no-look rollup.
• Do not let a previously reported risk vanish without an explicit close-out line.
• Do not send more than 2 asks, and never send an ask without a named decider and a date - undated asks are FYIs, and FYIs get ignored.
• Do not include velocity charts, story-point counts, or sprint burndowns; they demand context the reader doesn't have and invite the wrong conversation.
• Do not deliver verbally first. The written version leads; the sync discusses it.

Quality bar

• Scannable in under 90 seconds by someone with zero project context.
• Every claim is either verified or labeled unconfirmed - no rounding up to green.
• Section caps respected: 4 progress bullets, 2 asks, 3 Looking Ahead bullets.
• Each risk has all four fields; each ask has a decider and a date.
• No acronym or internal codename appears without a plain-language gloss.