5 ways leaders and analysts can try thinking differently to be data-led
In previous posts I have shared resources to help you educate your leaders in data literacy, but beyond knowledge this also requires thinking differently. So, we need to thinking about our thinking.
Helping leaders get their heads around thinking styles can be a challenge. Most of us spend most of the time in unconscious automatic thinking patterns. Responding to similar problems or stimulus with repetitive thoughts or mental models. Being data-led also requires this aspect of cultural & leadership change.
To take on this topic I am delighted to welcome back guest blogger Harry Powell. Readers may recall that Harry is Director of Data and Analytics at Jaguar Land Rover. He has shared with us before on the how leaders need to behave when being presented to & the need for less predictive models.
5 ways of Thinking Differently
This post is a slightly different style to our normal guest blog posts. Below I have collected together what were previously 5 separate micro-posts from Harry. To help you achieve this aspect of data literacy, I think it’s helpful to see the diversity of different thinking styles.
As you read through them, I challenge you to consider which thinking style you could practice. Bring to mind a current problem you are working on. Recall how you are approaching thinking through that problem. What have you tried already? Now imagine, for each of the thinking styles that Harry outlines, approaching it that way. Could it work? What fresh insight might it offer?
Over to Harry now, to challenge us with 5 different thinking approaches. Helpfully for each he shares a real life case study of how his team applied that thinking style (in green text). Here’s Harry…
Thinking style 1: Using existing data sources in unusual ways
Sometimes you can learn a lot from data that isn’t meant to have anything to do with the problem space you are working in. In fact we have made good use of data that is just plain wrong.
This is because while the function that records the data may care about the numbers themselves, you might only need to care about a pattern in the data, or about how it co-varies with some other factor. The fact that it is inaccurate for its original purpose may not matter.
For example, we wanted to show how delaying raising issues during the new vehicle engineering programme was causing quality and production issues. To do this we had to normalise the issues data by how much work was being put into the programme. But the labour data was notoriously bad – most people didn’t bother to fill in their timesheets. We were told that there was no point in even looking at it.
It turns out that while the labour data was completely wrong, it was wrong in an independent and unbiased way. So it was fine to use for our purpose, and we were able to show that engineers were raising issues too late and that this drove quality problems.
Thinking style 2: Working back to front
Sometimes a problem can only be solved by working back-to-front, starting at the end and going back to the beginning.
When we wanted to calculate the daily sales in each country, we found that, during the month, each market used different rules to determine when a “sale” is recorded (although they did reconcile at the end of the month). There was no easy way to contact the markets to ask them about their logic. So we had to start with the historic output data and infer the sales logic from that. We were then able to apply that logic to the intra-month vehicle sales information and calculate daily sales easily for the first time.
Even if it’s not 100% right, it gets you to within a couple of % and that is a lot better than trading blind. It certainly helped us when lockdown hit and we needed to reduce inventory fast.
Thinking style 3: Super-simplification
It is always tempting to think that complex problems can best be solved by complicated solutions, but you often find that super-simplification gets you even better results. By this, I don’t just mean building parsimonious models by eliminating insignificant variables (you should always do this). I mean radically changing the approach, answering the question in a completely different, perhaps even naive way.
We needed to build a model to select a set of cars to build and sell. Now there is a very complex logic which determines what cars can be built, and a similarly involved logic of what cars will sell in what markets. People had tried to code it up a number of times, and tied themselves in knots. Then one of the team suggested just sampling from the vehicles that we had built in the last 2 years. It is a shockingly simple approach and although it doesn’t sample the full distribution, it gets you 99% of the way there in 1% of the time. And then you can use the time you save overcomplicating something else! 🙂
Thinking style 4: Abstract problem solving
You can create a lot of value by thinking about your problem in abstract terms. Computer scientists are often better at this than data scientists. The first question they ask is “what data structure is this?” or “is this process equivalent to an algorithm I already understand?” or “what design pattern should I use to represent this?” Abstracting the problem often enables you to see common patterns, apply well understood analytical frameworks and to simplify radically, giving profound and generally applicable results.
When my team at Barclays were asked to build a general engine to extract Insights from customer transactions, we were able to show that there were 5 common archetypes of insight. Plus, relevance could be thought of as a form of local ranking, and that a couple of mathematical abstractions (called monoids and monads – very different things even if spelled similarly!) could be used to simplify and streamline distributed calculations. That left us with a very generalised Insight Engine. One which would run very fast and could be configured to address lots of different types of problems.
Abstracting a problem back to its bare essentials is hard. But it is probably the most valuable thing that a problem-solver can do.
Thinking style 5: Don’t be constrained by other people’s limitations
Perhaps the most obvious tool in the original thinker’s toolbox is ignoring people who tell you what can and can’t be done. At university I once asked a maths professor for a hint as to how to solve a problem set. He said, “Here’s my hint… It can be done.” Things are much easier when you believe they can be done.
A big win for the team at JLR was when we found a way of working out what parts go into a car. You’d have thought that this would be straightforward, but it isn’t. We could always do this at the point the car was actually built (obvs) but to do it in advance wasn’t possible because it is done in a proprietary system where we don’t have access to the ruleset. To do so we had to parse a 56 million line xml file where the rules are hidden. And we were told there was no point trying because it couldn’t be done.
Turns out it can (thanks to my brilliant team!). We can now simulate millions of cars a day, when the base system could only do a few thousand for use by the factory alone. And this allows us to optimise and simulate all sorts of scenarios around how to build cars better.
It is an error to assume that just because you haven’t observed something in your sample, that it doesn’t exist in the population. There’s a risk in pursuing something that “can’t be done”, but if the prize is big enough, it’s worth having a go. And don’t expect people to believe in the truth just because you prove them wrong. It takes a while for the impossible to sink in, so stick with it.
Hat tip to James WatkinsonMartin BrettMatt CollinsStephen Halil and all the other great people that built the “impossible”.
So, how will you try thinking differently?
What ideas has that post given you? Which thinking style appeared? Which case study reminded you of a problem that you are facing? I’d love to hear your feedback on that.
Of all the examples of thinking differently that Harry shared above, my favourite is super-simplification. Too often I or those I’ve worked with are just too close to a problem to step back and see this. It is too tempting to add more complexity to our thinking or code as we seek a solution. Yet, some of the best solutions I’ve seen in practice are simple ones. Those that came from stepping back, generalising and accepting “good enough“.
I hope this post inspires you to think differently and to challenge your leaders to do the same. Once Harry shared 5 more ways of thinking differently, I will being those to you too. In the meantime, can you guess them?