AI for engineering managers: walk in with the cause named, not the apology

Committed versus done went the wrong way again, and you know roughly why: a cross-team dependency, a late spec, two people on-call. The MT hears six reasons and files it as a pace problem. What you need is the dominant cause with its actual share, and the trail behind it (which tickets, which labels, which sprints), because the moment you name a cause someone else's team owns, you will be asked to prove it. Walking in with a narrative and no filter to show is how a real dependency problem gets recorded as your team underperforming.

Cloud spend creeps, the finance line says engineering, and the question lands the week before the budget review. The honest answer usually involves something untagged: a non-prod environment nobody owns, still running since a launch, billing the same again next month. You can find the total in the console in a minute. What takes the afternoon you do not have is the split by tag and environment, the euro amount, when it started and who turned it on, which is precisely what the CFO will ask for.

Planned work slipped because incidents took the capacity, and every engineer in the room knows it. In the MT it still reads as a missed sprint. To change that you need incident hours as a share of sprint capacity and an honest split across root causes, with the dominant one named and the rest shown rather than rounded away. A too-clean answer ("it was all one fault") loses the room faster than no answer, because anyone who has run on-call knows real incident data is messier than that.

Ask why the release slipped and you get committed versus done across the last several sprints, the dominant cause with the percentage of slipped scope it accounts for, the rest of the distribution rather than a single tidy villain, and the tickets and labels behind each bucket so you can open them before the meeting. Then the forward consequence: what happens to next quarter if the dependency is not escalated now. You still own the causality. What changes is that you can show the filter when the MT pushes back.

Point it at the cloud cost export by tag and environment and you get the concentration rather than the total: which environment drives the increase, how much of the month it explains, the amount in euros, when it was switched on and which owner or last committer is attached. That is an action with a deadline before the budget review, not an alarm. If the tagging is too thin to attribute a chunk of spend, it says so and names the untagged share, which is itself the finding to take back.

Ask what on-call cost the sprint and you get incident hours as a share of capacity, split across root causes with the dominant one named and its real percentage, the recurring label behind it, and the tie back to delivered scope so the MT hears business impact rather than an engineering complaint. It reports the distribution the log actually contains. Where the log is incomplete or the tickets are untriaged, it flags that instead of smoothing it, because a defensible 60% beats an unbelievable 100%.