Two Teams Cleaned The Same Data Twice
This page comes out of a change programme covering nine product and technology teams at a research and advisory group with global reach, inside one of the largest units it operates. This dimension carries no scored question. It surfaced entirely from what the leadership interviews volunteered: a data estate where the same source gets normalised twice.
Start with the words
9 meaning units (9 from the leaders stream); nothing on the scored questionnaire touches it, so the words carry the whole measurement. 9 of the 9 came up unprompted, with no question asking for them.
Coded sentiment, 1 (very negative) to 7 (very positive): the same density-strip grammar as every scored chart on this site, fed by sentiment instead of a score.
What we didn’t score
Duplication/Inefficiency carries no scored question on this assessment, because nobody was ever asked to rate it. Everything here is qualitative: 9 from the leaders stream, 9 meaning units altogether. Everything below is read straight off what people chose to say, not off a distribution of scores that was never collected.
What the words said
9 coded mentions in the qualitative record here: free-text signal, standing in for no score at all.
Where it lived
9 of 9
Sailboat-retrospective coding of the leadership interviews: Anchor (what’s holding us back), Wind (what’s pushing us forward), Sun (what we want more of), Reef (risks ahead). No per-team breakdown: these units all carry the leadership interview’s single placeholder team, not real per-team spread, and a one-row team facet would claim precision the data doesn’t have.
What it kept showing up next to
Not one unit coded to Duplication/Inefficiency names a different measured dimension in its own words. There is no cross-topic link claimed on this page: a qual-only dimension has no shared per-unit key to join the leadership and team-survey streams, so no computed co-mention count exists to report, and none is inferred.
What happened next
The leaders named the mechanism themselves, in the same breath as the symptom:
“Between teams, I know of 2 teams that receive and normalize the data the same way we do it. Why would you do that? It’s coming down to ownership.”
Two pipelines built to do one job, kept alive because no one owned the shared version. Every format change downstream bills every copy separately:
“Lots of data duplication – when the source data changes, lots of other downstream teams are affected (being kept busy).”
“A significant amount of time is spent transferring data between systems just to maintain access to the latest information.”
“The data sources are inconsistent across teams.”
It is the same missing-owner pattern the intake case study found deadlocking new requests, and the technical-debt piece found deadlocking capacity, here appearing a third time, in the data estate. No new mechanism to diagnose: the fix is the one the leaders already named. Someone has to own the shared copy, or every consumer keeps building their own.
A note on the data
Qualitative-only evidence: This dimension surfaced with no scored question attached to it, so there is no distribution chart on this page. Every count and chart here is pulled fresh from the leaders stream, entity-extracted into meaning units and checked back against the source workbook each time this page renders. A real engagement; an unnamed client, and it stays that way. Team names and identifying details are removed, and quotes are lightly edited for anonymity. Every quoted phrase is provenance-anchored to its workbook row. One organisation, and this is one reading of what its leaders volunteered.
Read Next
- the intake case study
Same missing-owner pattern the intake piece measured at the front door: no request owner there, no data-product owner here.
- the technical-debt case study
Third appearance of the same ownership motif: no capacity owner there, no data-product owner here.