Are your data initiatives someone else’s horror story?
There’s a build-up of bad practices, so what can we do about it?
I recently came across two rather sobering -but also really good- reads about the state of data science in industry. One was a personal post of a data scientist explaining why they’ve very happily switched to data engineering, and really not beating around the bush, citing reasons like “shitty management” and “insane projects”. The second article, from
, echoed very similar ideas in discussing “the thin line between DS and BS”. Many of the points made by both authors rang true, even though I’ve generally been quite lucky with the teams and work I’ve been involved in over the past few years.For me, these two articles were a bit of a wake-up call. Not in that they pointed to issues I was previously unaware of (see e.g. my previous article on here, or this LinkedIn post). Rather, it was a wake-up call on the urgency and scale of the problem, and a reminder to be vigilant and take active steps to not become part of a horror story in some data scientist’s blog post two years from now.
I would recommend reading both articles. For the less patient, I’ve written a summary of the main points below, followed by my thoughts on the matter. You can skip ahead if you don’t want to go through my summary.
My selective summary of the two articles
In the first article, @ryxcommar shares several grievances. A few that stood out for me:
Lack of DS expertise amongst leadership: “Nobody knew or even cared what the difference was between good and bad data science work. Meaning you could absolutely suck at your job or be incredible at it and you’d get nearly the same regards in either case”
Lack of domain expertise: “Insane” ideas rooted in a lack of understanding of customers, the business, macro environment, or accounting.
Datawashing: Management green-lighting DS projects as a way to make their “insane ideas” appear grounded in objective truth (side note: “decision-driven data rather than data-driven decisions” is a turn of phrase I will be using for many years to come)
VC-inspired calculus: Try 100 things knowing most will fail, because a handful succeeding will be good enough. Business soundness aside, ryx observes that it’s pretty awful to be one of the employees working on the stuff that’s very likely to flop1.
Skill gaps among data scientists: Several root causes, including lack of mentorship for more junior data science hires, lack of senior/experienced DS leadership (“where is the adult in charge?”), a general talent shortage in folks who are good at both data science and software engineering, and many data scientists taking the wrong approach to self-directed learning, going for superficial or irrelevant topics instead of mastering the fundamentals first.
All of the above ultimately led the author to feel like their work didn’t matter, add value, or fulfil them. Not a good mix! At least they seem to be happy and fulfilled now that they’re in data engineering. But what about everyone else who’s still in DS, and the businesses that employ them?
In his article,
takes a more systematic/impersonal view of data science, but there is a lot in common between the two articles. In fact, Vin starts off with the same premise as ryx:The motto of most data science teams should be, 'You can't be doing it wrong if nobody knows what you're doing.' Pull back the covers on most models, and you'll find deeply flawed methods. But no one in the business knows enough to call it out.
Similar to ryx’s article, Vin’s criticisms are distributed across both business/leadership and technical/data science teams:
Criticisms on the business side:
Dangerously inadequate training: The sort of data literacy training business people tend to get (e.g. a 6-8 week bootcamp) is not just inadequate for training them to be leading data teams, but also gives them a false sense of competence. Models are not evaluated, requirements are not articulated well, and statistical rigour is an afterthought, if that.
Decision-driven data: Leaders asking data scientists to fudge the numbers when their beliefs are challenged, rather than vice-versa.
Poorly-built data teams: Lack of specialist roles like ML engineer, MLOps engineer, data engineer, and data analyst (and either data scientists forced to be all-in-one, or data scientists hired with the promise of DS work but then forced to be the data engineer of the team).
Criticisms on the data side:
Who will guard the guards? When data science teams are the ones that instruct the business on how to measure the success of their initiatives, they become their own QA and QC, and shift blame to MLOps rather than their own models’ reliability.
No UX considerations: DS teams, like technical teams on transformation programmes more generally, will blame users for not adopting their solutions (“they don’t get it”, “they’re not technical enough”, “they’re set in their ways”)
There is a big interplay between the above (which Vin calls out as well): If your leaders don’t know what they need from the data teams, or what good looks like, they will hire the wrong people, for the wrong roles, structure their teams poorly, and make those hires work on the wrong things. And when you tick some or all of those boxes, you get all the bad DS outcomes from the bullets above.
My rapid-fire thoughts on how to address these challenges
Each of the points made below could (and in the future, probably will) be an article in its own right. Before I get to that, though, I wanted to share the tl;dr for each one. Do shout if you’re especially interested in me expanding on specific bits from the below!
Data science, data products,should be a solution to a problem, not a solution in search of a problem.
Senior leadership needs to shift from a buzzword-driven, FOMO-induced “we need to become data-driven” approach to a deliberate exercise of identifying opportunities for data and technology to add value. A decision being backed by data of some variety is not automatically better, nor is building ML models left, right, and centre going to automatically lead to value for your business.
One of the books I’ve been reading over the past few weeks around this has been Teresa Torres’ Continuous Discovery Habits, which I’d really recommend to any data product manager, data scientist, or data leader working on data products.
To be data-driven, you need rigour.
Evaluating the success of a project using “A/B testing” is meaningless if that A/B experiment has been set up poorly, because it literally means that you might be seeing a positive uplift when in fact there was none, or even worse when your “data-driven” intervention actually makes sales worse.
For example, suppose you’re launching a new customer loyalty scheme, and you invite your already-engaged customers to join. In that case, comparing their engagement against that of your least-engaged customers who haven’t joined the new scheme is obviously going to show that the new scheme is a massive success, even if it’s anything but.
And remember: Being rigorous means being ready to accept ‘no’ for an answer.
I’m not gonna suggest a stats textbook, nor do I think everyone needs to become a statistician to work on data projects and products, but you should certainly have a meta-understanding of what’s at play, otherwise it’ll be in “unknown unknowns” territory: Ben Goldacre’s Bad Science is an excellent read in its own right, but also specifically relevant to the topic of data science’s un-scientific tendencies.
If you’re a leader and don’t know how to evaluate for statistical rigour, you need to be mindful of that and make sure someone in your team will cover that base for you.
If you’re a data scientist worried about the rigour of your experiment or modelling approach, find a way to raise that point to the business by appealing to the things that matter to them: “Statistical rigour” will likely be meaningless to a business team, but the business outcome your experiment is helping build towards is very much something they care about.
If you’re in a situation like this right now and want to bounce ideas on getting your business stakeholders onboard, give me a shout - I’d love to jump on a call and help you out.
UX and user adoption are really important considerations, not an after-thought for version 2.0.
In orgs that aren’t already on the top end of the digital and data maturity curve, data science initiatives usually involve getting some not-so-data-savvy part of the business to embrace data. These initiatives are (sometimes rightly, sometimes wrongly) met with distrust by the business, often because they don’t see the value data can bring, because they feel threatened, or because what’s been built is simply not fit for purpose.
The key idea here is to build with your users, not just for them - both because that’ll be the key to securing their buy-in and adoption, but also because your data team probably doesn’t have all the context and domain expertise needed without close collaboration! This, incidentally, is one of the key reasons why I favour delivering data products over ad hoc ‘insights’ or one-off projects.
My #1 content recommendation here would be Brian T. O’Neill’s Experiencing Data podcast. Brian and his guests talk through lots of examples and best practices for how to build data products that are simple, usable, and ultimately valuable.
Do you know what is good, or just what good looks like (in someone else’s context?)?
You can’t make ‘data-driven’ decisions (or even the more modest milestone of ‘data-informed’ ones) by simply trying to copy+paste what you see out in the wild. It’s nice learning about what Big Tech does through their tech blogs and conference presentations, and sometimes it can inspire great ideas to bring back to our own orgs, but these are absolutely not blueprints for your own org. Besides the fact that the challenges, resources, and skills they might have are probably vastly different to your own, these things are often snapshots taken at one particular point in time and may have also been sanitised heavily before making their way to external audiences.
It’s important to remember that data science and its related fields and sub-fields are all still very nascent. Even IT is a toddler of a profession when you compare it to fields like accountancy, medicine, or law, so it’s hardly a surprise that we’re all still figuring things out (and often re-inventing or unnecessarily changing stuff). For me, this sort of wake-up call and healthy debate about what’s working and what’s going poorly is all great - after all, how else could we make things better?
PS: Like with my last post, I used Stable Diffusion to generate the image. This time, I even used ChatGPT to help me think of a few prompts (though this was definitely one of those uses of GPT-3 where you need to take 5% of what it’s given you as inspiration, instead of do the last 5% on top of what it’s done automatically…)
I also hear these sorts of horror stories when talking to civil servant friends, who sometimes have to work on projects because some minister with zero expertise in their field has decided they want to do something dumb