Ask a program manager what is slipping and you will hear about their program. Read five months of their meetings side by side and a different picture appears: the damage is not coming from inside any one program. It comes from patterns that repeat across programs. A single supplier tooling item throttling two schedules at once. Escalations that stall at the same boundary every time. Shared wafers split between projects on the fly, with nobody holding the portfolio view. We call these systemic interrupts, and they are where the biggest leverage in project acceleration sits, because each one repeats. Fix it once and every program speeds up.
How we read five months of meetings
The dataset behind this article is new for us. For five months, Otter.ai recorded the weekly refresh and pull-in meetings of four project core teams, four meetings a week. We built an integration between Claude and the Otter database, and a skill that scrapes the right meetings and mines the transcripts. This first cross-section covers 42 recordings and 21 hours 33 minutes of core team meetings, corroborated against 314 rows of milestone cause-of-change logs from the portfolio workbook. Nobody sat through those hours twice. The transcripts were mined in minutes, and because the mining is a skill rather than a one-time analysis, it reruns as recordings accumulate. Not every meeting survived capture; the field analysis maps the coverage and its gaps, and one program’s meetings never recorded at all, which became a finding in its own right. That is the point of the setup: continuous monitoring of how teams actually run, not a snapshot audit. We wrote about the broader toolset in How lateralworks uses AI. Program and client identifiers are removed throughout; the projects appear here as Programs A through D.
What the meetings said
Seven patterns cleared the bar of appearing across programs, each with a one-line fix.
Three deserve a closer look.
The most expensive item nobody owned. A single supplier tooling item was the named critical-path driver in six meetings across two programs, and it drove a 100,000-unit sample commitment out by a quarter. Each program managed it separately. No cross-program owner, and no cost-of-delay case ever put against it, in a portfolio that had already built a cost-of-delay model pricing one program at roughly $9 million per day. The most expensive item in the portfolio was also the least owned.
Escalation stalls at the supplier boundary. Inside the company, the working level operates at Freedom Levels 1 and 2 on the freedom scale: engineers start mitigations unprompted, program managers record causes, nobody waits to be told. The moment the blocker crosses to a supplier, the same people drop to Level 3 and stay there: recommend, then wait. An expedite sat open “for the past two weeks.” A yield lead ended up personally flying to a supplier’s factory, which is heroics compensating for a missing decision. The cost-of-delay model that would force the decision was never cited in a single refresh.
Administrative latency sits on the critical path. An export approval waited on an approver who was out of office. A tooling purchase order would “sit for like a month.” Test hardware sat in customs with no ETA while builds queued behind it. Each item is trivial; together they are a recurring tax on the critical path. Reinertsen made the general point in The Principles of Product Development Flow (2009): product development delay hides in invisible queues, and his first rule of economics applies here word for word: if you only quantify one thing, quantify the cost of delay.
The language is a leading indicator
The sharpest finding was not in what the teams said about their schedules. It was in how they said it. One program manager proposed seven pull-in moves in a 31-minute meeting and decomposed a green indicator honestly. Another recorded slips diligently, typed causes live, and proposed zero pull-ins in 50 minutes, while adding padding twice and framing it as prudence. A third gathered updates and dated them: I’ll put it at the later date for now. Three grammars: acceleration, documentation, collection. Where the pull-in grammar is absent, the wigglechart trends red weeks later. The wording is the earliest warning the portfolio produces, and coaching the language (“what would make this start earlier?”) is cheaper than coaching the outcome.
The slips are external
Across every captured program, the recorded causes of change are supplier dates, tooling, and processing holds. Internal task slippage barely appears in the logs. Pushing the teams harder gains little, because their own work is not what slips. The leverage sits at the supplier interface: expedites, tie-outs, take-or-pay commitments, and the co-development relationships we wrote about in When the customer slips. That article looked at the boundary from the customer side; this portfolio shows the same boundary from the supplier side, and the same rule holds. You do not synchronize across a boundary by asking for dates.
There is a reward-system finding buried in here too. Nobody’s pay or recognition depends on forcing the supplier decision, so nobody forces it, which is Kerr’s folly wearing a supplier badge: we published Reward performance. Don’t incentivize it. this week, and this portfolio is that article in the field. Ownership expectations cannot outrun capacity either: one person carrying ten responsibilities was named directly in the leadership session.
The record cannot explain itself
One program left 94 percent of its milestone moves uncaused in the written log, including four moves of more than 90 days. Another logged all but one move in 28. Portfolio-wide, the written log runs 134 slips against 59 pull-ins, and a formal supplier corrective action appears in the log without ever surfacing in a meeting. The fix costs nothing: a cause on every move, and a weekly mining pass over the log. Un-recorded is not undocumented, and un-mined is not read.
Interrupts and provisioning
Step back from the seven and notice what they have in common: none of them is a process change inside the teams. They are all changes to the environment around the teams, and that is the point. Setting up the FTTM environment reduces to one sentence with two halves. Fast teams are provisioned with what they need, and fast organizations remove the interrupts slowing them down. Provisioning is the before-the-fact half: staff released to the team, tools, budget, decision rights, and supplier commitments in place before the team hits the wall. That is the job of the host, everyone outside the project team whose job is to help the team go fast; Provisioning Host covers the practice, and IBM once ran a steering committee dedicated to exactly this. Interrupt removal is the after-the-fact half: the host watching for whatever is slowing the teams down this week and clearing it, which is precisely the job this mining pass now does at portfolio scale. There is more on interrupts across the /ideas library. A team that has what it needs and is not being interrupted goes fast. Almost everything else is commentary.
One fix per interrupt
The full evidence sits in the field analysis (download below). The fixes fit in a paragraph. Put the shared blocker on an escalation log with a cost-of-delay case and one cross-program owner. Route any supplier blocker older than two weeks to the product-boss forum automatically. Make one modeled pull-in scenario a standing agenda line in every refresh. Run every review tier from the live schedule, critical path first. Stand up a weekly portfolio view of shared resources. Give admin items on any critical path a standing fast lane. Require a cause on every milestone move, and mine the log weekly.
The meeting was already telling you
The interruption literature studies the individual: Gloria Mark’s research group found that interrupted workers compensate by working faster and pay for it in stress. A systemic interrupt is the organizational version, and it is denominated in weeks, not minutes. Nobody experiences it directly. It does not ruin anyone’s afternoon. It quietly taxes every program at once, which is exactly why it survives: no single meeting ever contains enough of the pattern to name it. The pattern only appears when you read five months of meetings together, and no human can. The teams were already saying everything in this analysis, out loud, week after week. Now something is listening at portfolio scale, every week, and the interrupts have nowhere left to hide.
Related reading: Freedom to Act, Cost-of-Delay, How lateralworks uses AI, The weekly schedule refresh, Provisioning Host, What is the R.O.I. of fast decision-making?, When the customer slips, and Reward performance. Don’t incentivize it.