My manager vaguely remembers that Sarah from an adjacent group did something similar last winter. He looks through his email and forwards me a deck. I discuss the topic with a few peers, and apparently, John from product had a comparable report last year.

I’m sizing an opportunity for a department head, and it turns out I’m not the first person to look into this space.

So I review the deck and the report. Sarah and John are clearly veterans: polished deck, clear story line, an appropriate level of detail for leadership, and a clear call to action. This is great work, and I’m sure they helped move the business in the right direction. There’s something missing from my perspective though: why and how did they come to these conclusions? After all, I need to do the work needed for my department head, not the same audience as theirs.

So I reach out to John for more information about the analysis that he did. Oh no, John left. The report he created is the only thing left behind. Too bad. I reach out to Sarah, and after some hesitation (I haven’t worked with her before), she shares with me her code. It’s not in a repository, not under version control, but at least there’s some trace of the “how” she came to her conclusion. I can use some materials here, at least the source tables. Hmm, wait, why was it done this way, why did she add an extra condition on the join to this table? I reach out to her again for clarification, but receive no further response. I get it, people are busy, and can only afford that much time in explaining why they do things a certain way. I have to make an educated guess on why she approached the work that way and adjust to fit my use case.

Analysts don’t start from nothing. Usually somebody has attempted something similar. They create an artifact from it: a briefing, a report, and maybe a polished deck. These are the conclusions of the analyses. But as a fellow analyst, you need something more detailed: the reasoning behind the conclusions. These are often fragmented - on someone’s laptop, in a repository if you are lucky, or buried in an email chain. When the threads are disconnected, you need to hunt down the clues in people’s memory, which is partial at best, and sometimes nonexistent.

And it’s not just you. We are all doing this. When you start a project, you drill through the previous ones, and every time you find something through these layers, you lose a bit of fidelity. It’s not drastic, it’s incremental. Over the years, as many layers of old and new analyses get excavated, the analytics foundation gets built on sediments of partial reconstruction. And you, an analyst who wants to do the job right, know that you’re doing something that has already been done before, but you can’t tell how much you’re missing.

The analytics foundation gets built on sediments of partial reconstruction.

Why? I think it’s in the design of the system. We set up our infrastructure and workflow to optimize the outcomes, but not to preserve the reasoning behind those outcomes. Spreadsheets produce calculations instantly, viz tools render charts in real time, and slide decks tell stories and persuade. But what in the stack helps the next person understand how those decisions were reached? Remember the last time you scratched your head to trace the logic behind a calculated field in Tableau? Nobody designs the system to help the next person follow the logic.

But maybe data products like core suites of tables or data blocks can solve the problem? It does lend a more credible lens to the analysis, but it comes with its own challenge, which I’ll write about in another piece.

Every organization builds their own analytics sedimentary layers differently, but they all build them. What’s your story?