Monthly engineering update for leadership

I'm preparing my monthly engineering update for the CEO and the leadership team. ## Context - Scope: [all squads | squad names] - Period: [last month], compared with the month before it. Use exact calendar dates for both months. - Audience: non-technical executives. They care about four things: are we shipping, are we stable, where is the effort going, and what needs their decision. - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats (both months, same filters) 1. Throughput — PRs merged, for delivery volume 2. DORA Metrics — deploy frequency, change failure rate, MTTR, PR cycle time 3. Deploy — deploy count 4. Allocation — roadmap vs unplanned vs maintenance 5. Engineering Investment — new things vs improve vs keep the lights on 6. Sprints and Planning Accuracy — predictability. Skip if the squads do not run sprints. 7. Benchmarks — where we stand against industry tiers If scope is "all squads", run org-wide first, then per squad only where something moved more than ~20%. ## How to analyze - Lead with what changed month over month, not with raw numbers. Executives remember direction, not values. - Connect signals. Unplanned work up plus planning accuracy down means interrupt-driven teams. Pickup time up with review time flat means reviewer availability, not review rigor. Deploy count up with change failure rate up means we are shipping faster than we are testing. - Translate every metric into a business consequence: speed, predictability, risk, or cost. A cycle time in days means nothing to this audience; "features reach customers a week earlier than in June" does. - Benchmark tiers are context, not a grade. Use them to say "this is normal for teams our size" or "this is where we lag", never to rank squads. - Be direct. Name the two or three things going well, the two or three that need attention, and the single decision or support I need from leadership. - Flag data gaps explicitly instead of working around them. A missing month of deploy data is a slide note, not a guess. - A stage that comes back blank in one period (deploy time is the usual one) was not tracked; it did not take zero time. The totals of the two periods are then not comparable: compare the stages both periods have, and say so. - In one month, change failure rate and MTTR rest on a handful of incidents. Give the count next to the rate, and do not build the headline or the ask on a move of two or three incidents. A flat 0% means incidents are not being recorded, not that nothing failed. - Two squads with identical PR, deploy or DORA numbers share a repository, and DevStats cannot split them. Show those numbers once for the pair, and tell the squads apart with the issue-based reports (Allocation, Issue Cycle Time). ## Deliver A six-slide deck (.pptx): 1. Headline — one sentence on the month 2. Shipping and stability — DORA plus throughput, with benchmark tiers 3. Where engineering time went — allocation and investment chart 4. Predictability — sprint delivery and planning accuracy (or the reason this slide is absent) 5. What needs attention — two or three items, each with the evidence and my proposed action 6. The ask — the decision or support I need from leadership Plain language, one chart per slide, no table with more than five rows. Add speaker notes on every slide with the supporting numbers.