Your mother just received 10 million dollars to start a B2B SaaS business. You want her to invest half a million into a modern data team as part of the growth.
How do you pitch the return on investment?
If you are a data professional, you may be tempted to do things like:
Invite her to accept dbt as personal Lord and Savior
Compare Snowflake’s JSON handling to the printing press
Attempt to define “data product”1
You will want to nerd out on these modern data stack topics because the modern data stack is awesome. It’s fabled that what took a team of engineers six months to build ten years ago can now be done in one week by a gritty data analyst.
But your mother isn’t trying to build what a team of engineers was building ten years ago. She is building her own business today, and she wants to know why you think she should invest a significant chunk of her cash influx into — wait for it — creating a bunch of dashboards.
In the absence of understanding, humans rely on heuristics.
For example, I don’t know how cars work. I just use a simple mental heuristic:
body + gas + engine ⇒ vrooooooom!
Here, stated plainly, I have three major points of failure to my vrooooming capabilities. If I have further questions, I turn to the professionals. Despite the automobile’s centrality to my life, I have a superficial understanding of it, am not that curious about it, and can boil its value down to a single nonsensical word.
The majority of data consumers, similarly, have a heuristic for data teams:
data + tools + team ⇒ dashboards
It is not wrong. Dashboards are still the most common thing built by data teams. (We sleep in graveyards of them, after all.) And they’re not worthless: dashboards consolidate spaghetti spreadsheets and replace rote data retrieval tasks. A great dashboard can become a beacon of consistency even as the business evolves around it.
But, in the modern data stack, the “dashboards” heuristic captures a diminishing slice of the data team’s potential impact. It leads to conversations like this:
Heuristics are not bad. In fact, they are usually quite useful. The tension here is that the predominant heuristic is misaligned with the emerging potential for impact that data teams can have.
Is there a better heuristic we can provide that stretches across all major data careers?
Is there common business pain that motivates the development of all sorts of data products — a great dimensional model, a certified dashboard, a reverse ETL pipeline, a custom Retool application, a badass Hex notebook, an (actually-useful) ML model endpoint, a comprehensive data catalog, a well-governed customer event framework?
I think there is a common thread: speed.
An excellent data team should push its peers to move faster and with more confidence.2 A key way they do this is by flushing out organizational debris as the company grows and ensuring new systems operate frictionlessly with the company’s core business model.
Any activity that doesn’t move the company forward is inefficient. There are technical inefficiencies: implementing software systems, developing a product, maintaining a CRM. There are organizational ones: meetings, consensus building, misalignment, arguments, human processing speed.
Young businesses have a clean slate, and they can skirt around many of these challenges. But just as engine oil becomes full of debris through continual use, so too does the organizational structure get “gunked up” as the company evolves. Systems that worked out of the box are now heavily customized. Responsibilities that were critical become vacated. Foundational business metrics take on new definitions.
Consider our poor dashboard again. The cry of pain that eventually forms into a dashboard requirement is often driven by a need for consensus and automation. A typical ask:
Julian is wasting time pulling these numbers every week, and on top of that, I think he’s doing it wrong. Can we get a dashboard in place so we can all be on the same page?
This is fundamentally a speed issue. The team’s initial iteration was useful, so they kept doing it. Then they realized it was too inefficient to scale, and the team was losing momentum. How can the team keep the value but remove the friction?
That’s the role the data team can fill. You can walk through any of the modern data stack applications and pick up on a similar “we are wasting time” or “this isn’t fast enough” theme. Machine learning itself — the most hyped of data capabilities if the least impactful — fits snugly into this framework. It reduces human inefficiencies by removing the humans.
Back to your mother. You will, of course, send her on a guilt trip for doubting you. But can we persuade her a data team is worth it on its own merits? Let’s try.
First, you tell her that you love her.
Then, you ask questions, starting from the top. The company’s destination in two years should serve as your anchor point.
What is your first big company milestone? What are the next two?
How will you track progress towards that first milestone? Will any factors change when thinking about the next two?
How many systems do you need to track to get visibility into your progress? Do you anticipate these systems or processes ever changing?
How important is it that everyone in the company is aligned on progress towards these goals? On progress towards new goals? Who is responsible for making sure this data is available two years from now?
Your mother will recognize these as critical questions, even though she is annoyed by them. The point you are making, beneath the interview, is that if the company is successful, a lot is going to change — but the destination is not. As those changes happen, there is going to be debris from old systems and ways of doing things that might get in the way of the bigger picture.
Someone needs to be able to step in, mediate consensus, flush out debris, connect the old and new, so that the company can focus on moving towards the future. That can be the data team.3
Finally — and before asking her what’s for dinner — you leave her with this simple heuristic, adapted to just the right level for a CEO:
data + tools + team ⇒ vroooom!
The greatest trick the devil ever pulled was convincing professional definers-of-things to define the atomic unit of defined things.
Benn offers a great argument that this is the case for analysts, but I think it extends more broadly.
I want to be clear that my aspirations espoused here are not the same as my track record in real life.