The Modern Data Stack Has A Hiring Problem
We need more semi-technical data talent
Software engineering is a mature practice with a clear set of roles one needs to hire for to build a piece of software.
Setting up a data practice is a lot less straightforward and unless you have a strong understanding of all the moving parts of a data stack, you can spend a ridiculous amount of time and effort trying to figure out the skills you’re looking for in your first data hire.
When people talk about data talent, they typically refer to technical roles in data — analyst, engineer, or scientist. However, there are a few data-adjacent roles that are less technical in nature but are quintessential to the successful implementation and adoption of a data stack.
Technical Data Talent
Hiring for a technical role in data is challenging for two reasons, the obvious being that the demand for data talent has never been higher and companies are competing fiercely to hire experienced professionals.
The less obvious reason is that a majority of companies, especially the ones in the early stages of figuring out how to go about building a data practice, have little idea about the people they need to hire.
Companies often use the titles Analyst, Engineer, and Scientist interchangeably to attract candidates to apply for data roles with unclear, often unreasonable expectations. I’ve even heard people say that using the Data Scientist title is a proven method to attract a ton of applicants — whether they’d be relevant for the role or not is a different story.
Even if you know what you’re looking for in an early data hire, it’s not easy to describe the role in a manner that will attract a decent number of relevant candidates.
Most people gravitate towards hiring a data generalist — often referring to them as a data scientist — and hoping that this one person alone can solve all data woes and make the organization “data-driven” (a term I have come to dislike for a variety of reasons; data-led makes more sense to me).
In any case, hiring technical data people is not enough and organizations of all sizes need semi-technical data talent — more than they ever have before.
Semi-technical Data Talent
I dislike the term non-technical because everybody, especially if they work in tech, has some level of technical aptitude. Referring to a product/growth/marketing person as non-technical because they don’t write code is, in my opinion, naive.
And now that a growing number of non-data folks are learning how to write SQL, does it even make sense to call them non-technical?
Why not start referring to these people as semi-technical instead?
Semi-technical data people play a crucial role in the process of making data available to go-to-market (GTM) teams in the tools they rely on.
Semi-technical data people often carry ops in their title and act as a bridge between the data team and the rest of the organization.
Product Ops, Marketing Ops, Sales Ops, Revenue Ops, or Data Ops — these are bridge teams that essentially enable the rest of the organization to utilize or consume data across a bunch of different tools.
Bridge teams don’t orchestrate pipelines or write SQL — instead, they set up processes that enable data and GTM teams to collaborate effectively and understand each others’ priorities, constraints, workflows, and goals.
Needless to say, folks who make all this happen are definitely not non-technical and are not easy to find. The requisite skills are acquired by working at the intersection of data, engineering, and GTM, and the number of people who’ve been fortunate to have that experience is relatively small.
That said, a shortage of ops talent also presents a unique opportunity for data-inclined GTM folks to become ops pros by making sure that tools are implemented properly, integrations follow best practices and are well-documented, and the right data is collected and made available in the tools used by GTM teams.
Therefore, a solution to the problem of finding semi-technical data talent is to foster data literacy among GTM teams.
Data Literacy Is The Key
I have played the role of that GTM person at a fast-growing company without a dedicated data or ops team where I helped set up the customer data infrastructure — everything I do to bridge the gap between data people and non-data people can be attributed to this experience.
If you happen to know GTM folks looking to gain data literacy, I’m available to answer questions about customer data infrastructure on my astorik community.
Simon Späti, an accomplished data engineer, is also building his community on astorik and is open to answering questions about data engineering tools and best practices.
And then there’s Luke Ambrosetti, an early proponent of warehouse-native apps (data apps) who is standing by to answer questions and help folks learn all about data apps as the future of SaaS.