Stop Letting the Tail Wag the Dog

If your teams spend more time maintaining reports than building product, your reporting system isn’t supporting delivery—it’s competing with it.

Every Monday morning, the release lead pulled data from Jira, reshaped it in a spreadsheet, and built a slide deck—all to describe work that Jira already knew about. One week, the deck didn’t match a Confluence tracker maintained by another team. The conversation didn’t start with “let’s reconcile.” It started with “why isn’t this done?” Two hours later, she’d proven that finished work was finished—time that came straight out of the sprint.

The work was done. The system just couldn’t see it.

Asana’s Anatomy of Work Index puts a number on this: 308 hours per year—nearly eight work weeks—lost to duplicated work or work that’s no longer relevant.

This isn’t a tooling issue. It’s an information architecture problem—the flow of data between the system where work happens and the systems where work gets reported has split in two.

The Anti-Pattern: A Second System for the Same Work

Someone needs visibility into delivery, so they build a report. Instead of deriving it from the existing workflow, they create a parallel layer—extra fields, labels, naming conventions, or documents that sit outside the day-to-day work.

Now, engineers aren’t just doing the work. They’re maintaining a second system that describes the work.

Over time, the reporting layer becomes the thing leadership sees. The workflow becomes something teams use locally. When the two drift—and they always do—the report wins. Work that’s finished shows up as missing. Teams are asked to explain gaps that don’t exist.

Why It Happens (And Why It’s Predictable)

Workflows evolve over years. Fields get added and rarely removed. Reporting needs change faster than the underlying system can adapt. Integration and plugin options get constrained by cost and governance. And the people who need visibility often aren’t the same people who know how to extract it from the system.

So they build something they can control—documents, decks, and dashboards outside the workflow. A Confluence page that mirrors what already lives in Jira. A recurring slide deck that takes hours to manually assemble by reshaping data that already exists in the system of record.

Each workaround makes sense on its own. Together, they create a reporting layer that is manual, delayed, duplicative, and easy to get wrong.

Then the direction of effort flips. Instead of reports reflecting the work, the work starts bending to satisfy the reports. Engineers context-switch to maintain metadata that exists solely for a downstream consumer. The cognitive tax is real. The accuracy drops. The trust erodes.

Two systems. Two truths. One credibility gap.

The Principle: Reports Follow the Work

The reporting layer must be a read-only projection of the system where the work actually happens.

If a report depends on data that isn’t in that system, the answer isn’t to create a parallel process. It’s to fix the system so the data exists where the work is already being done.

Everything else is a workaround—and workarounds accumulate.

From that principle, a few practical shifts follow.

Treat metadata like a contract, not a suggestion. If a field is required for visibility, it should be part of the workflow itself—not something people are expected to remember. When labels are invented ad hoc for a single dashboard, you get fragile reporting and false signals.

Stop copying data into documents. If a report requires manual transcription, it’s already out of date. Native dashboards and filters within your workflow tool can surface most of what teams manually replicate in static pages—in real time, from a single source. The barrier is usually familiarity, not capability.

Generate recurring reports instead of rebuilding them. If something gets assembled the same way every cycle, it should be produced directly from the underlying data. If that’s not possible, either the data structure or the report format needs to change—not the amount of manual effort engineers pour into maintaining it.

Teach the people who build reports how to query the system that has the answers. Most shadow reporting exists because extracting the right view from the workflow tool feels harder than recreating it manually. A few focused working sessions on what the system can already surface will eliminate more duplication than any process change.

The Conversation Worth Having

This isn’t about one function getting it wrong. Everyone involved is trying to create visibility. The question is whether that visibility is generated from the system where work is planned and completed, or maintained alongside it.

If it’s generated, it stays aligned by design. If it’s maintained separately, it will drift—and people will spend time reconciling differences instead of delivering outcomes.

If your reporting layer has to be updated alongside the work itself, you don’t have one system. You have two. And two systems describing the same reality will eventually disagree.

Start with the work. Make it observable. Let everything else follow.