In short
The best-run chip programs I have seen are still decided on information that is one to two weeks old, because that is how often a review happens. In those weeks the cheap fixes disappear. Nothing about this is a failure of engineering; it is a failure of seeing, and it is fixable.
The review is the problem, not the people
I have spent fifteen years building data and AI systems for industries that run on programs: healthcare, mobility, manufacturing, and now silicon. The pattern is the same everywhere, and it is sharpest in chips because the stakes are. A program is run by its reviews. Status is collected, slides are built, a meeting happens, decisions are made. Then everyone goes back to work for a week or two until the next one.
In between, the program moves. A coverage curve flattens. A supplier's email says the drop is four weeks late. A firmware team keeps working to a samples date that changed on Tuesday. None of this reaches the people who could act on it until the next review, by which point the fix that would have cost two days costs two weeks, and the fix that would have cost two weeks is no longer available.
Why organisations cannot see themselves
In 2024 my co-founders and I published two working papers on what we called Autonomous Organizational Intelligence: the premise that an organisation, properly instrumented, can be observed and reasoned about as one system rather than a collection of tools. The observation that started the work was simple. Companies track everything except themselves. They have more data about their own operations than at any point in history, and the people running them still find out what happened at a meeting.
The reason is structural. Each tool knows its own facts. Jira knows the tickets, the regression farm knows the coverage, the ERP knows the purchase order, the inbox knows the vendor moved. No tool knows the date, and no person can read all of them at once. So the organisation's knowledge of itself is reassembled by hand, on a cadence, and it is always behind.
What changes when a program is read continuously
The alternative is not a better dashboard. A dashboard is still a picture of the past that someone has to look at. The alternative is a layer that reads the tools all day, holds every commitment against the date it serves, and does something when one of them drifts: traces what it breaks, works out the fix, and puts the decision in front of the person who owns it, that hour.
When we built that for silicon programs, the first thing that changed was not speed. It was the kind of decision people were making. Instead of deciding how to recover from a slip, they were deciding which of three small corrections to approve before anything had slipped. Those are different jobs, and the second one is the one program leads were hired for.
The question I would ask any program lead
If something on your program moved this morning, how would you know, and when? If the honest answer is a review, your program is being run on old information, however good your team is. The engineering is not the problem. The seeing is. And seeing, unlike engineering, can be fixed for every program at once.