Cooking is not cutting
And analytics is not SQL.
👋 Hello! I’m Robert, CPO of Hyperquery and former data scientist. Welcome to Win With Data, where we talk weekly about maximizing the impact of data.
A quick plug: if you’re looking for a data tool that can help1 with problems like the ones we discuss here, check out Hyperquery (or reach out to me directly on LinkedIn or Twitter). 🙂
Cooking is an interfacial discipline. It is not a domain in which your work directly achieves some end, but rather, success is contingent on happy reception by a second party. And value is not only predicated on, but realized through others. And so, you cannot excel at cooking without considering the nature of this interface. Cooking is not about honing exemplary culinary technique, after all, but about learning the rich language — the gastronomic melange of hunger, desire, flavors, and expectation — of the eating process.
In other words, chopping skills don’t matter if no one eats your food.
"Cooking well does not mean cooking fancy. It means mastering the fundamentals, understanding them and then forgetting them so you can create something new."
- Thomas Keller (French Laundry, Ad hoc2, Bouchon)
And analytics is the same.
In this post, I’ll try to convince you that technical chops are overrated. In short, analytics is a lot like cooking. And cutting is rarely the most important thing in cooking.
Technical skills are not sufficient: good chopping doesn’t mean people will eat your food.
Technical skills are a base requirement, but technical skills alone are not sufficient to have impact as an analyst. You can produce a technically elegant analysis, but if the connection to business impact is ambiguous, it’ll be a bedtime read for your PM, at best.
There needs to be an intimate connection to the business, or your independent projects won’t hit the mark. Writing a perfectly optimized query is negotiable. Alignment and a clear understanding of business objectives, however, are not.
Said another way: run your data team like a product team. Like good products, your work should be user- (business-) centric.
Technical skills are not as differentiating: it’s like getting better at chopping.
Technical skills are not only insufficient, but deep investment into them is not going to be as important as up-leveling your other skills. There’s a ceiling to technical work. Data is data — outside of the standard statistical traps, there’s little you can do to differentiate against the next person getting the same data. But which data you pull, how it’s commodified as knowledge, and how others are able to operationalize your insights — these are differentiators. And these mean the difference between getting locked into reactive decision support and advancing a data-driven ethos.
That said, I’m purposely leaving “technical skills” ambiguously defined here. I suppose when I say “technical skills”, I’m thinking the side of analytics work that involves direct implementation of a solution — the scripting. There are certainly instances where careful thought around how to go about doing the technical work can lead to leveraged impact. But I’m co-opting this to live on the non-technical side of analytics. You can’t optimize how you do your technical work without aligning it to an objective, after all.
Why does this matter?
Because we all want better business outcomes, no? Is that not why analysts exist? Are not our own intrinsic motivators seamlessly aligned with corporate value-add?
Sure — you nod along, but I’m sure you’re still itching to go back to creating that POC for a duckdb-powered warehouse. Technical skills have their appeal. The translation to value is more transparent, progress is straightforward and measurable, and, honestly, technical work is often just more interesting — the raw excitement of diving through dumpsters of data is what brought us to this domain in the first place.
So let me throw one last argument your way: your focus on technical work makes your job worse. A few weeks ago, I shared how an overzealous focus on technical chops can lead to us to be pigeonholed into a technical role, hamstringing our organizational impact. In short, we can’t be involved as thought partners if we’re perceived as purely technical workers. And you’re likely familiar with the repercussions: more quick questions for data pulls, less strategic involvement.
The core of this devil’s flywheel looks like this:
And so, even if you ignore what I’ve said so far and immediately go back to your SQL hobbit hole, perhaps the Machiavellian analyst in you will focus a little less on technical skill, if only to elevate your influence in your organization and enable you to do more of the Things You Love.
As much as I believe in our product, it’s important to remember no tool by itself can solve your problems.
The fact that his restaurant name is Ad hoc feels serendipitously appropriate. If you can find the joke, let me know.