Every status meeting is theater. Ask your CTO for results and you get heroes: who fought hard, who stayed late, what got in the way. You had asked about money, dates and commitments.

This is how we took manual reporting out of a company with about 100 engineers and 70 projects in flight, what the system looks like, and what the numbers say after two months of running it.

Where the facts live

When you need to know where a project really stands, you open a hundred chats, replay the last three calls, and ask two team leads who give you two answers. The information exists. Finding it is the job at your level, and it makes you a very expensive search engine with a seat at the table.

The decisions that matter are never made in Jira or GitLab. They are made in chats, on calls, in meetings. That is where a scope changes, a date moves, a priority flips. The tracker learns about it later, if at all. A dashboard that reads only the tracker shows a world that no longer exists, in bright colors.

So reporting runs the way it runs in most companies. Dozens of meetings. People spend hours collecting, wrapping and passing information one floor up, where it gets rewritten. By the time it reaches the top it is old, reshaped by every hand it went through, and often no longer true. Nobody lies. Information changes because it passed from one person to another.

The architecture

We built an operating system for running the business. It reads the sources on its own, writes what it finds into registries, and assembles the report for each level of management on schedule. The whole thing fits on one picture.

From sources to the leadership report without a human in the chain
From sources to the leadership report without a human in the chain

Sources. Everything where work leaves a trace: the tracker and CI, monitoring, test reports, team chats, customer and support chats, meeting recordings, the headcount sheet, project descriptions and statuses, budgets and financial models. Compliance and treasury are next. The important ones are the human ones. That is where decisions are made.

Two clocks. Information has two speeds, and the system treats them differently. The fast clock is hourly: new messages go into a feed of the day, and every morning a scanner reads the escalation channels and monitoring signals and files incident candidates with quotes and a confidence level. The slow clock is daily: the tracker, CI, tests, monitoring and the people sheet go into a daily log for each of the 70 projects, with the quotes it was built from. Weekly and biweekly reports sit on top of the daily data.

Registries, with provenance. The registries are the center of the system, and the reports are only views of them. An entry in the incident or project registry carries the quote it was built from, a confidence level, and a list of what the source did not say. A project with no trace in any source that day gets an explicit “quiet” entry with a date. Silence is a fact, written down. One thing is kept by hand: the list of projects, with the chats, the Jira keys and the folder of meeting transcripts that belong to each. Once that list exists, the machines know where to look.

Rulebook. The engineering handbook is where the company is written down: the org structure and who owns what, the processes, the release train, on-call and incidents, and the system itself, what gets recorded where, what is stored where, how to work with it. It is a git repository, 56 pages, open to everyone from a line engineer to the top. The rules live in a document, so nobody has to carry them in their head or learn them from the person who left last month. A new hire reads the handbook and knows how the company works on day one. The same document feeds the machines: the daily audits are coded against it, and each finding names the page it enforces. A project manager who disagrees with a finding argues with a document, and when the document changes, the audit changes with it. Metrics are plain code with tests, and they stay silent when a period has fewer than eight issues or two periods cannot be compared.

Reports, on schedule. The leadership report every two weeks opens with last period’s commitments against fact, then projects, releases, quarterly goals, delivery, people, hiring, finance, product metrics, budgets. A weekly Jira report per project space for the project managers. A weekly goal snapshot per team lead. And the same registries for everyone, any time: an engineer on a team sees the company the way the top sees it, from the same sources.

The fence. Agents write and run the code. They get less access than they ask for. When the language model reads text written by other people it runs without tools that reach the web. Writes to systems of record are off by default. Outgoing text goes through a linter for machine-written phrasing. Every substantial piece of work is attacked by a second agent with a clean context whose job is to break it.

Two months of net time from an empty folder to a system that runs every day.

What changed

Manual reporting is gone as a thing. Nobody writes a status for anyone anymore. The top sees what the floor sees, in real time, with almost no loss and almost no distortion on the way, because no person rewrites anything.

I always see the source. Any line in the report opens down to the first message, the meeting where it was discussed, who said it, who committed to what, and why it took the shape it did. That has done more for trust in the numbers than any process we tried before.

You also see what your own priorities do. When a team gets pulled onto a second project, the first one stalls, and the stall shows up on the timeline with a date and a cause. We traced every idle stretch in our epics back through GitLab. Idle time is a third of every epic’s life. Where the developers could be identified by their commits, in 57% of the idle days they were committing to other work. They had switched. Nobody needs to explain that to the owners anymore. It is the result of a decision somebody made, with a price on it, and the people who made the decision see it themselves.

And silence became visible. In September and early October, 60% of project-days had no trace in any source. Some of that is projects waiting on a partner. Some of it is a project with a team assigned and nobody working on it. Before, silence read as good news. Now it is a list, and the list is the agenda.

The numbers

  • Reports that used to be written by hand for three levels of management: zero. All assembled on schedule.
  • Age of data in the leadership report: under 24 hours. Before: days to weeks, depending on who had time to write.
  • Sources behind a status answer: 8 systems, every incident and project fact traceable to a quote. Before: memory and a few chats.
  • Projects with a daily log: 70. Before: status for the top 10 or so, by memory.
  • Of 8 top-priority projects last period, 6 closed at least one issue. The other 2 went to the owners as a question.
  • Delivery: waiting at 55% of a task’s life, QA queue at 30% of cycle time. Both were invisible before.
  • Idle time: a third of every epic’s life. Where developers could be identified, 57% of idle days were spent on other work. Switching, with a date and a cause next to each stall.
  • Build: two months of net time, one person plus agents.

What we paid

There is more information now, and someone still has to read it, the leader included. The hours moved from collecting to analysis. Far fewer of them, but they did not disappear.

The system makes mistakes, and we check it. It checked this article too: a reviewer agent compared the first draft with the raw data and found 14 claims that did not hold. A second review found seven more. All fixed.

There is an open question we are still working through: who gets to see what. The same registries now hold incident timelines, project logs, people data and, step by step, compliance and treasury. Some of that must be visible to everyone, some to a few, and some to one person. Today the separation is coarse: one-on-ones live apart from project material, raw chats never leave the laptop, and the display server is read-only. Finer rules are being written as each new source comes in. We add sources one at a time, and each one brings its own access rules with it. That is the price of seeing more of the company, and we pay it deliberately.

And one rule came from a mistake of mine. For a few weeks the system corrected Jira directly, 642 changes across 322 issues, and project managers asked me to stop it. They planned by those dates and found out afterwards. Half of the changes followed sprints, and our own handbook says sprint decisions need a human. I switched writing off. The rule now reads: agents find, people decide. The same findings go to the people who own the plan, and they act on them.

What is next

Cost per project. The system knows which team owns each project’s work, how many people are on it, and which days it moved or sat quiet. Add one table from finance, what a team costs per month, and every project in the report gets a price next to its status, and every quiet week gets a price too.

Meetings. Recordings are filed by calendar event into project folders, one-on-ones kept apart. How that works, what happens to personal data in recordings, and how statuses are pulled from transcripts is the next article.

If your status meetings are theater

Start with a registry where every number has an address. Read the chats and the meetings, because that is where the decisions are. Let agents find and people decide. And try it on one project before you try it on the company.