Do our tools mould our outcomes and decisions?


Day zero of being a #CDO is probably not the best day to ask difficult questions; however, sometimes, there is no better day.  The first question to ask the executive leadership team as you walk around being introduced might be: “What is the one thing that we, as a team and organisation, want our data to drive, deliver or provide?”

You might want to wait to ask this question and first determine what tools are being used. This will frame what outcomes and decisions are being supported.  The question and answers allow you to determine if there is an alignment or gap between “What is the one thing that we, as a team and organisation what our data to drive, deliver or provide?”  and what will happen anyway because of tools, processes and legacy.  One critical aspect of being a #CDO is determining how our processes and methods only enable certain decisions to be made, but we have to unpack legacy.

Legacy within this framing is threefold. Decisions. Decisions. Decisions. These are:  

  • Decisions that created processes, methods and rules which were created by previous incentives and power games; and are now ghosts in the systems. These decisions were taken so long ago that no one knows why, how or when it was decided.  It is the way we do it; it is our IP, our brand.

  • Decisions that created “information and technology debt” included embedded and baked-in systems, hidden, and no-longer supported code, and automation based on tools and data biased when created. 

  • Decisions that created noise in the hierarchy to lose or filter signals that someone did not want to hear.  It was the creation of layers, reports, practices, structural regulation and unchallenged assumptions.

Unpacking legacy questions will take time, and you will not be ready on Day-0. Therefore any responses you get have to be framed within such understanding when it arrives.  It is worth asking the question and then verifying before becoming blind to the tools that mould you. 

“What is the one thing that we, as a team and organisation what our data to drive, deliver or provide?  Well, it could be:

  • Evidence-based, actionable insights

  • What should we automate?

  • How do we know we are doing the right thing?

  • Where are there efficiencies to be gained?

  • What do customers really want?

  • How to manipulate customers to increase margin and revenues?

  • Where are risks that we cannot see?

  • What is being hidden that we cannot see?

If you look at this list in the context of what tools and decisions already frame the response, are these what we are looking for data to answer or are we looking to data to affirm/ justify what we have already decided.  A different response that no one will say “to justify what we are already doing!”

Data has bias because of previous decisions. Therefore, a #CDO has to find non-data tools to check what decisions from the past are biasing the current data, processes and tools. We cannot usefully answer the question we have set ourselves “What is the one thing that we, as a team and organisation what our data to drive, deliver or provide? without understanding the situation.

The CTO knows that they have to build a new platform when the bug list, new feature development and maintenance costs are bigger and will take more time than developing a new platform - this is the technology debt question.  As the #CDO, you have to understand what is your information debt. The CTO will struggle as there is no clear path from policy to code. Similarly, the CDO, we struggle with no clear path from policy (what one thing) to better data for the decisions we require.  You inherit and are now accountable for previous decisions, which constrain what is now possible as the biased tool has created what we have. The costs of collecting, labelling, holding, sorting and creating training data continually increase, creating a more significant gap and misalignment in values and expectations from data.

We become what we behold. We shape our tools, and then our tools shape us”  is often mistakenly attributed to Marshall McLuhan (as in the image above) and called McLuhan Law. The quote was actually written by Father John Culkin, SJ, a Professor of Communication at Fordham University in New York and friend of McLuhan. Such is the problem with data. 

Perhaps the opening question is the wrong one? Perhaps we should reflect on these questions as a leadership team.

  • What do we want to become, and what tools and data will help us?

  • What tools do we use, and what will they enable us to become? 

  • What is the minimum viable data set required to give the best value? 

  • Do our tools and data trap us?