stonewall.dev
Back to Blog
decision-tracking product-management tool-sprawl

Modern Ownership Means Owning the Decision Trail

Stonewall · Updated: | 6 min read

A designer asks whether the export still includes CSV. You own that task. You don't know.

So you go looking. Slack first — #product, three weeks back, where someone wrote "let's cut CSV for v1." Then the ticket, where a comment from the following week says CSV is back in. Then the pull request, where a reviewer asked why the CSV branch still exists and never got an answer. Then a Figma comment. Then an email from sales, promising a customer that CSV shipped in March.

Twenty minutes. Five tabs. Three contradictory answers and no two timestamps that settle it. You pick the one that sounds most recent and you reply with more confidence than you actually have.

That is the job now. Not the work. The reconstruction of the work.

The second job

Ownership used to mean one thing: you are accountable for the outcome. Somewhere in the last decade it quietly became two things. You are accountable for the outcome, and you are accountable for the archaeology.

Nobody assigned the second one. No job description says "reconstruct the decision history of your own task from six systems that don't know about each other." The tools assigned it. Every product that shipped a comment box created a new place where a decision can be made and then stranded.

The cost is measurable. Atlassian's State of Teams 2025, a survey of 12,000 knowledge workers and 200 executives, found that leaders and teams waste 25% of their time just searching for answers. A quarter of the week. Not deciding — locating what was already decided.

You own the outcome and you own the archaeology. Only one of those is in the job description.

Where the trail scatters

Feedback goes wherever the person giving it already was. That is the only rule anyone follows, and it is a completely reasonable rule.

  • The staff engineer leaves the real objection in a PR review, because that is the window that was open.
  • The designer leaves it on a Figma frame, attached to the pixel it concerns.
  • The CEO leaves it in a DM at 11pm, one sentence, no context.
  • Support leaves it in a ticket comment, quoting a customer verbatim.
  • And someone leaves the most consequential one out loud, in a meeting nobody recorded.

Five people, five surfaces, one task. Each of them thinks they gave you feedback. Collectively they handed you a research project.

The spec is worse, because the spec is where the scatter accumulates. Google Docs and Notion both have version history, and version history tells you the text changed. It does not tell you which decision changed it. It is a diff with no commit message — you can see the paragraph about CSV disappear on a Tuesday, and you cannot see who argued for that or what constraint made them right.

So twice a week, someone asks the same question in a different channel: what did we actually agree?

The switching cost, measured

The reconstruction is not one context switch. It is a chain of them, and the answer only exists as the sum.

Researchers at Harvard Business Review instrumented 20 teams, 137 users, across three Fortune 500 companies. Workers toggled between applications roughly 1,200 times a day. Reorienting after those toggles cost just under four hours a week — about 9% of time at work. They called it the toggle tax.

Meanwhile the baseline attention span keeps shrinking. Gloria Mark, Chancellor's Professor of Informatics at UC Irvine, has tracked screen focus since 2004, when people averaged two and a half minutes on one screen before switching. Recent studies put the average at 47 seconds.

Now stack those. Reconstructing one decision means five deliberate switches, each carrying a reorientation cost, performed by an attention system that already breaks every 47 seconds. You are not paying the toggle tax as background noise. You are paying it on purpose, to answer a question your own team already answered.

Why it got worse

Building got fast. DORA's 2025 report, based on nearly 5,000 technology professionals, puts AI adoption among software development professionals at 90%. A feature that took two weeks takes two days.

The decision trail did not speed up. It is still humans typing opinions into whichever box was nearest.

DORA's own framing is the useful one: AI acts as "a mirror and a multiplier." In cohesive organizations it improves efficiency; in fragmented ones it highlights the weaknesses. Tool sprawl is a fragmentation. So the multiplier lands squarely on it. The number of decisions per feature did not drop when the build got faster — the window in which they get made compressed. Same scatter, less time to notice, and now an agent is writing the code, which adds one more participant who needs the decision trail and cannot read your Slack.

What good looks like

Three properties. Not a product — properties you can check for in whatever you already use.

Decisions attach to the artifact they change. A comment about the CSV export lives on the CSV section of the spec, not in a channel that scrolls. The unit of storage is not the message, it is the thing the message changed. If the only way to find a decision is to remember which app it happened in, it is not stored — it is buried.

Spec history reads like git history. Author, timestamp, diff, and a message saying why. Engineers have had this for twenty years and would riot if you took it away. Product specs, the documents that decide what all that code is for, still ship with worse provenance than a one-line CSS fix.

Removals are as visible as additions. This is the one that burns people. Additions announce themselves; someone shows up with a new paragraph and a Slack message about it. Removals are silent. A scope cut made in a hallway shows up as an absence, and absences do not generate notifications. Six weeks later a customer asks about CSV and nobody can say who cut it, or whether it was cut at all — the same rationale that never survives the meeting it was formed in.

The test is simple. Ask your team what was agreed about one specific piece of scope. If someone can answer it as a lookup, you are fine. If it starts an investigation, you are paying for archaeology whether or not you budgeted for it.

The honest close

This is the problem we work on. Stonewall keeps the spec as a living document with real history — decisions attached to the section they change, additions and removals both on the record, and the same trail readable by the agents doing the building. It does not eliminate the scatter. It gives it one destination. If that framing is interesting, the manifesto is the shorter version of why we think the spec, and not the ticket, is where this has to be fixed.

Owning a task should mean owning the outcome. The archaeology was never supposed to be part of it.

Related Posts