It's 10pm.Do you know what your AI is doing?

Every team is green through the whole quarter. Then hardware, firmware, and cloud meet at integration and months of hidden problems surface in a week.

Why it happens. Percent-complete is not a forecast. Status reporting is designed to roll up green and it does that job perfectly. It measures effort inside teams, not the state of the system between them.

Nobody lied to you. Each team honestly reported the work in front of it. What no one reported is the assumption mismatch across teams, because no report has a field for it.

Replace the roll-up with two things: an integration state that is demonstrated, not asserted, and a forecast that carries a range instead of a date. When a team says green, the question is not "how far along?" It is "what have you integrated against, and when did that interface last change?"

First move. Pick the next release and require one working end-to-end thread across all disciplines before the next status cycle. Whatever breaks is your real status.

The board approved a three-year strategy. Engineering is building something adjacent. Nobody noticed for three quarters.

Why it happens. Nothing traces a strategic theme to a sprint. Both sides work hard, in good faith, toward an outcome nobody has defined in the same words.

This is a translation problem, not a commitment problem. Themes approved in a boardroom die on the way to the backlog because no single person owns the decomposition.

Build the line explicitly: theme, use case, story map, sequenced backlog, and keep the trace visible in both directions so a board member can ask "where is theme two?" and get an answer from the actual work, not a slide.

First move. Take your top three approved themes and map every in-flight epic to one of them. The epics that map to none are your answer.

Teams are fully loaded, the roadmap barely moves, and nobody can say where the capacity went.

Why it happens. Work enters the system through side channels: sales promises, unvetted maintenance, escalations, pet projects. None of it appears on a roadmap.

You cannot prioritize what you cannot see entering. Most organizations have one visible intake path and four invisible ones.

Run intake as a single door with a monthly number attached to everything that came through it. The number is the argument: when leadership sees that a third of engineering went to work no one chose, the prioritization conversation changes by itself.

First move. For four weeks, tag every work item with how it entered. Publish the split. Change nothing else yet.

Each discipline has its own cadence, its own definition of done, and its own idea of the release date.

Why it happens. Teams are organized by discipline, so the product increment is nobody's job. Integration is the only place the pieces meet: at the end, when correction is most expensive.

Different cadences are fine; different truths are not. Mechanical spins, firmware sprints, and cloud deploys will never align, and forcing one cadence on all of them fails.

What works is a shared increment with a fixed integration rhythm the slowest discipline can meet, plus stand-ins (simulators, emulated interfaces, hardware mules) so nobody waits for silicon to find out they built to a stale spec. Where the silos themselves are the cause, reorganize around the product increment with end-to-end accountability.

First move. Name one owner for the increment across all disciplines and give them the integration calendar.

Leadership wants the company AI-native. Nobody can name the outcome, and pilots keep appearing without a business case.

Why it happens. AI is being treated as a toolbox for problems that were never defined. Bolt it onto a value stream you can't see and you accelerate the disappointment.

Your customers don't want AI. They want their outcome. AI is a prioritization problem before it is a technology problem: taxonomy of candidate use cases, value and feasibility scoring, then scoped backlog work, in that order.

There is a second-order effect worth planning for: AI-assisted engineering increases output upstream and floods code review, QA, and security gates downstream. If those gates are already your constraint, more output makes delivery slower, not faster.

First move. List every AI initiative in flight with the customer outcome it changes. The ones with a blank in that column stop.

Estimates are fine on paper, but the plan quietly bends around the availability of a handful of individuals.

Why it happens. Key-person dependencies never appear in a status report. They show up as wait time, which nobody measures.

Most cycle time in a program is not work. It is waiting. When you map the flow, the queues cluster around the same few names and the same few approval gates.

Fix the queue before you fix the person. Some of it is genuine expertise that needs deliberate transfer; a lot of it is an approval right that could sit with the team and never was.

First move. Measure wait time versus active time on your last completed feature. The ratio usually ends the debate.

You are asked for a date. You have percent-complete. The two are not related, and everyone in the room senses it.

Why it happens. Single-point dates hide the variability that actually determines delivery, so a miss looks like a failure of will rather than a failure of method.

Give the board a range with a confidence level and the assumptions attached, and re-forecast as reality lands. A defensible range beats a confident date that moves twice.

This is also the fastest way to rebuild credibility after a slip: the first honest forecast hurts, and every one after it is believed.

First move. Forecast the current release from historical throughput, not from the plan. Compare the two and show both.

Budget is spent, the gap is finally visible, and every remaining option is expensive.

Why it happens. The signals existed for months; nothing in the operating model surfaced them while corrections were still cheap.

It is recoverable. The re-plan will hurt, but it will be built on truth and the program ships. What has to happen is a single honest picture: what's done, what's left, and what scope, time, and cost have to become for this to succeed.

Then the decision is yours: cut scope, move the date, add money, or ship a smaller thing that customers actually want. All four are survivable. Continuing on a plan nobody believes is not.

First move. Stop the status meeting for one week and reconstruct the real state end to end. Restart it on facts.