Half of a dev team's meeting decisions could not be found later
One month, 26 recorded meetings, 45 engineering decisions, four systems of record. Here is where each decision ended up, and why half of them are gone.
I spent a month as a contract developer inside a senior engineering team, building a new section of their site on WordPress and Next.js. Near the end I ran an experiment on my own engagement. I had recordings of 26 meetings, from daily standups to architecture sessions. I pulled every decision out of them and checked each one against the places the team actually searches when they want to know why something is the way it is.
Just over half of the decisions could not be found by anyone on the team.
This is the method, the numbers, and what I think a team should do about it.
What counts as a decision
A decision is a call that changes what gets built or how. "Search uses this engine." "The publish flow is one way, test to production, never back." "That button comes out for the MVP." Not a status update, not an opinion, not a to-do.
I took the decisions from the meeting recorder's summaries, not from the full transcripts. That makes the count a floor. Summaries drop detail, and I did not go hunting for decisions the summary missed. Forty-five decisions about my part of the project came out of 24 meetings with usable summaries.
Where a decision could live
The team runs on four systems. Jira for tickets, Confluence for pages, GitHub for pull requests, and Slack for talking. Meetings are the fifth place, and they are where most decisions are made.
I treated Jira, Confluence and GitHub as systems of record. If a decision is written there, a developer who was not in the meeting can find it. I treated Slack as conversation. A decision that exists only in a chat thread is findable in theory and lost in practice, because nobody searches chat for why a piece of code exists.
For each of the 45 decisions I searched all three systems of record by keyword, then read every hit by hand. The Jira side was 118 tickets with every comment. The GitHub side was 229 pull request descriptions across two repos. Confluence was one space searched by text.
The result
| Where the decision lived | Count | Share |
|---|---|---|
| Written in Jira, Confluence or a PR, with the reason | 9 | 20% |
| Visible as an outcome, a field, a label, the code, but the reason was nowhere | 12 | 27% |
| Only in my own private working notes | 22 | 49% |
| Nowhere at all | 2 | 4% |
The explicit bucket is the healthy one. A reader finds the decision and the why. Most of those nine exist because of one habit: when I moved a ticket to QA, the comment said what changed, what to check, and what was deliberately different from the ticket. Those comments are where the reasons live.
The implicit bucket is the quiet failure. The fix version is set. The label is on the ticket. The code does the thing. Nobody wrote down why, and six months from now someone will undo it because it looks arbitrary.
The private bucket is the embarrassing one, and it is mine. I write more down than most contractors. I keep decision records with context and consequences. I keep a running state file. Twenty-two of the missing decisions were in that folder, in good shape, on my machine. They were in the wrong place. A decision on my disk is a decision the team does not have.
Two decisions were nowhere. Both were process rules someone said out loud and everyone nodded at.
What else fell out
Four decisions had been reversed or changed later, and in no case was the change written where the team could read it. One architecture choice was reversed within two days, correctly, and the ticketing system carries only the final outcome. Anyone reading it would assume the first choice was never considered.
Two whole clusters were missing. Every decision from the search design session and every decision from the content sync session existed only in my notes. Those are the two areas most likely to be rebuilt wrong by whoever picks them up after I leave.
One piece of agreed work had no ticket at all, a month after it was agreed in a meeting with the people who would build it and the people who would use it. Everyone remembered agreeing. Nobody had filed it.
Why this happens on a good team
The team is good. Review is fast, releases are regular, the ticket workflow is cared for. The gap is not carelessness. It is a shape problem.
Decisions get made where people talk. Systems of record are where people file. The distance between the two is a context switch that happens after the meeting, when the next meeting has already started. Everyone intends to write it up. The person most likely to write it up is the person who argued for it, and that person is also the one who already knows the answer and feels no pain from its absence.
AI tools make this worse before they make it better. An assistant that reads your codebase can tell you what a function does. It cannot tell you why the function exists if the why was said out loud on a Tuesday and never typed.
What I would do
Measure it first. One afternoon with a month of meeting summaries and your ticket export gives you a number nobody on your team has. The number is the argument. Without it, "document decisions better" is a resolution that lasts a week.
Post the decision to the ticket the day it is made. The team already accepted that form from me. Every ready-for-QA comment had a what-to-check section and nobody pushed back once. The habit closes most of the gap. A tool can draft the comment from the meeting summary and hand it to a person to approve, which removes the context switch, and the person still owns the words.
Record reversals as reversals. A decision record that supersedes another is the single most useful kind, because it carries the thing a reader cannot reconstruct: that the obvious choice was tried and why it lost.
Treat the implicit bucket as the real target. The explicit bucket grows on its own once the habit exists. The implicit bucket only shrinks if someone goes back to every unexplained field and label and asks who set it and why, while that person still works there.
What I am doing with this
This measurement is the first published experiment from MaxtDesign Solve, the fixed-scope engineering practice I am building out of exactly this work. The next experiment tests whether a linked decision ledger, built once from the tickets, pages and PRs and read by an agent inside a normal subscription seat, answers "why is this here" better than plain retrieval over the same sources. It has a pre-registered success number and a kill rule, and the result gets published either way.
If you run a small software team and want the number for your own meetings, the measurement is the first thing I offer, and it is the cheapest. The method above is enough to do it yourself. Either way, do it before the person who knows why leaves.
Need help putting this into practice?
MaxtDesign builds the AI web stacks the articles describe, from agentic workflows to performance-first WordPress + WooCommerce. Talk to us about your project.