Data Leadership #1 Why being a Head of Data isn't what you think it is
Articles on Data Leadership from from the executive team at Orchestra plus resources on #dataleadership from around the ecosystem
Weekly Bites
👉 A good podcast from Kyle Winterbottom at Orbition who interviewed the CDO at Bentley Motors, Dr. Andy Moore (link). Nice to get a Chief Data Officer on a podcast!
Why being a Head of Data isn't what you think it is
And what it actually is. Until very recently I [Hugo Lu] was in charge of the Data function at London-based Fintech Codat. There we scaled the team from 2 to 4/5 heads before cutting back like many tech companies. Here is what we learned.
This article first appeared on Medium in April 2023.
Being a Head of Data comes with the promise of solving interesting problems by building cool infrastructure. The fact is, though, stars need to align for that to ever happen. An oft-quoted example:
Your finance team engages the data team to build a revenue report
You do some time scoping, and realise you can ingest all the data on a daily cadence and clean the data easily using dbt
You present the report to the finance team and the job is done
Even this requires so many things to be right!
Aligning the stars
In the example above, the Finance Team knows what they want. Often, this will not be true. The data is also readily available and clean — often this is not true either. Finally, there are no weird edge cases that delay the implementation of the report. There are lots of other things you need too:
Engaged stakeholders who know what they want
Clean data
Robust processes around how stakeholders interact with data resources
An understanding and appreciation of how data can add value
People who are willing to use BI tools
Teams that do similar roles working together and not in silo
Budget for tools, and for team members
Senior buy-in
To name but a few.
This changes the role of the Data Team, and of the person leading it.
Responsibilities
At Codat, we took 1–8 for granted. It meant we built an enormous self-service infrastructure that was poorly used initially. There was more data and capability flying around than people knew what to do with.
In reality, we had a bit of (2), (5), (7) and (8). It meant that as the Head of Data, I was spending loads of time doing these things:
Acting as an evangelist for BI and Data tools
Convincing Senior Leadership to invest in a Data Strategy
Acting as an “embedded analyst”, importing loads of domain knowledge to fix deeply-engrained business problems
Writing SQL
Not:
Fine-tuning robust data engineering infrastructure
Cultivating analysts in their SQL abilities / outsourcing dbt
Building “data mesh” or “democratisable” data functionality e.g. the roll-out of cloud-based reverse ELT tools
There are quite a few things I wish I had done differently, if given the chance again.
V2
The level of data literacy was relatively low, and we should have identified that from the beginning. There are only a handful of people comfortable building a dashboard in Looker, for example.
The level of understanding with respect to how data can inform decision-making was also relatively low. The use-cases that would resonate most would be relating to reporting, maybe a bit of reverse ELT. There was a low appetite to explore how we could be using data science to advance our Product and our operational capabilities (this has changed since Chat GPT came out, unsurprisingly).
Therefore, rather than spend time building out advanced capabilities and ingesting as much data as possible, I would have done what Linkedin is saying (remarkably!) and found some stakeholders, found the most pressing problems, and just done those. Perhaps combined with a bit of basic BI and data-serving.
It’s far better to hit a few use-cases for data really really hard in an organisation that isn’t going to self-serve well if there is low data maturity.
And in keeping with that
If there isn’t huge self-serve demand, don’t create needless work by ingesting loads of unnecessary data. Keep data models to the bare minimum.
Finally, I would’ve been an evangelist to senior leadership a lot more a lot earlier. Having built loads of infra and ingested loads of data, it was difficult to argue for more headcount when we didn’t actually have many tangible examples of making anything better. We’d ingested and cleaned loads of data — people weren’t doing much with it apart from make dashboards.
After smashing your use-cases, go straight to your key stakeholders and make the pitch for continued investment in your data strategy
Finally, something I feel is under-appreciated in Data is how Product centric it is. Whether you’re literally building Data Products, are going for a more centralised / service model, you’re building something for people to consume. With it, comes additional product responsibilities, like marketing. Internally marketing and explaining the capabilities of the data team is so fundamental, particularly when there is so much noise! In practice, this means:
Regularly updating the company on what the Data Team are doing and how it can help them. This can be via slack or email. Slack is easiest.
Personal marketing; spend time getting senior leaders on side. Without them, you’ve got nothing
Marketing collateral: build out docs and resources people can use to self-serve
Self-serve flow: make this as easy as possible, just like if you were designing a free software product / software free trial
Cut through the noise: there will always be people who are skeptical of what you are doing. These typically start sentences with “When I worked at XXX” and are good at generating problems but not solutions. Get these people onside or get them out of your company immediately. They are extremely damaging to progress, as identifying problems without solutions erodes trust, which is an important currency for Data teams
Conclusion
There are some high level-takeaways for anyone building out a Data function in a company that is relatively immature on the data front. These obviously dont apply to larger companies with large well-established data teams, or companies where the level of sophistication is high.
I recently heard that at Adaptavist, which is a company where pretty much everyone knows SQL, they are only just doing “Data Products” (where the analytics engineering team’s responsibility is maintaining some core data tables, but individuals in different teams are largely expected to write their own dbt and build their own dashboards). They’re a pretty big company (300+ employees I think) and have only been doing this for 2.5 months. So the above may be more relevant to you than you think.
As part of my Data Work, I am building Orchestra, a no-code platform for lean data teams to monitor, debug and fix their data pipelines. The vision is this makes the Data journey for companies like Codat significantly easier. Check it out here.