Reinventing How Analysts Work | Barry McCardel
How AI is reshaping how teams explore and communicate with data.
Welcome to the Data Analysis Journal, a weekly newsletter about data science and analytics.
If you’ve been reading my newsletter, you know I’m a fan of notebooks. I’ve used them since the early Jupyter days and tried almost every notebook out there. It’s been interesting to watch how they keep reshaping data science and what it means to be an analyst.
For a long time, Deepnote was my go-to (Data Portfolio Done In Notebook). A few months ago, I switched to Hex, and it completely changed my perspective on what notebooks can and should do. Hex is setting the bar very high.
Before diving into my own analyses and projects in Hex, I wanted to start with a conversation with its founder about what Hex is, why it was created, how its vision has evolved, and what skills the next generation of analysts should build.
Hex is one of the most well-known applications in analytics today. It’s a notebook that seamlessly combines SQL, Python, and interactive visualizations, allowing data scientists and analysts to explore data more effectively. They don’t call it a “notebook,” though - it’s a “connected platform for using AI to work with data.” Whatever you call it, more than 1,500 teams worldwide use Hex, and a few months ago, the company announced $70M Series C round to fuel the era of agentic analytics.
A few weeks ago, I stopped by Hex’s office in San Francisco - the one with a framed BlackBerry 8130 (because apparently nostalgia is part of their brand?). At first, I was a little intimidated - if you Google the Hex founders, it’s giving “classified government project, but make it SaaS” vibes:
Turns out, they’re actually fun. Though, to be fair, I can only vouch for Barry.
So, everyone - meet Barry McCardel, co-founder and CEO of Hex.
How did it all begin? What is the Hex story?
I’ve been a builder and lifelong user of data tools. My co-founders and I all met at Palantir. Every job I had, the pattern was the same: the stack existed - warehouses, BI tools, but 80-90% of our time went into maintaining dashboards, while real analysis lived outside them.
Then, at a healthcare startup, the first question leadership asked was, “How’s enrollment?” - something a dashboard could answer. The next question, “What happens if we change X?”, required chaos: running queries, exporting CSVs, opening Jupyter, generating charts, taking screenshots, and pasting them into decks. Totally inefficient.
I started out looking to buy something better. I couldn’t find anything - none of the open-source tools or commercial products really solved it. My friend said, “Maybe you should build it.” I laughed, then realized he was right. I hadn’t planned to found a company, but we, my co-founders Caitlin and Glen, had the right experience and taste to build the kind of tool we always wanted, so Hex was born.
We raised seed funding in 2020, once we had early users and a working product. The biggest early challenge for us was focus. Data is infinite. The hardest part is deciding what not to build. It’s very easy to spend years building something no one will use. Customers don’t always know what they want - follow every request and you get a Frankenstein product, but ignore them and you lose relevance. Balance is key. I wrote about this balance in a post called Commitment Engineering. It’s about making deliberate product tradeoffs.
We built Hex selfishly, the tool we always wanted. I still use it daily. Our 150-person team does too.
Why a notebook?
In our early VC pitch decks, I wrote: “There’s no standalone market for notebooks.” The notebook is a format, not a product. The goal is an integrated environment - analysis, visualization, and collaboration in one workflow.
Other industries solved this - Figma integrated design workflows, Notion unified docs and databases. Data deserves the same: one environment instead of a separate BI tool, notebook, and AI assistant.
We even printed notebooks embossed with “Not Just a Notebook.” Ironically, by rejecting that label, we built the best one.
There isn’t a single “notebook market.” VS Code’s notebook serves engineers. Jupyter serves researchers. Hex serves analysts and data scientists - people moving between SQL, Python, and visualization.
Like dbt defined “analytics engineering,” we’re defining a space for integrated analysis - where exploration, modeling, and storytelling happen in one place.
Most Hex users never touched Jupyter. The barrier was too high: local setup, package management, broken environments. We didn’t commercialize Jupyter like others tried, we solved a broader problem: letting anyone who asks questions of data work productively. We made notebooks usable for analysts. SQL cells, chart cells, and reactive DAGs were our core innovations. We turned a developer tool into an analyst’s environment.
Any comment on the Hashboard acquisition? That was quite a surprise.
I’ve known Carlos (Hashboard’s founder) for years. Hashboard focused on BI, made thoughtful architectural choices, and punched above their weight with a tiny team (like 8). We began talking about working together about a year ago. Integration has gone exceptionally well. Their team is contributing to recent releases, and Carlos now has a larger product role here at Hex.
I met Carlos and the Hashboard team, and agree - they’re great. After seeing the demo, I was impressed by how well they handled version control and how straightforward they made dashboard maintenance. Really well done.
How does AI fit in notebooks?
We launched our Notebook Agent a few weeks ago, and the adoption has been explosive. The notebook itself is an amazing format for iterative, deep analysis – and agents work into that pattern really well.
You can ask a question, and watch as an agent builds you the first draft of an answer using all the cells and context in Hex – it’s really amazing.
Once you start working this way you just can’t imagine going back. And now there’s a whole new frontier of techniques and methods for working with the agent in Hex – it’s so fun.
We also just launched Threads - a conversational UI interface built on the same framework as our notebook agent, but simplified for non-technical users. It’s the world’s best way to do self-serve. It’s more “on the rails”, without access to Python, restricted to endorsed data, and a preference for semantic models. For charts, it uses Explore cells, so users can drill in. If you send a thread to the data team, they see the notebook behind it. This bridges non-technical users and analysts.
And of course, you want to trust all the answers you get – so we have a semantic modeling agent. It isn’t a GPT wrapper, it’s built into workflows. You can point it at a Hex project to bootstrap a model, ask “what should I build next,” and it will propose and draft additions based on your warehouse and projects. You review, fix minor issues, and publish.
This forms a virtuous cycle:
Editor (data team): notebooks for new/gnarly work.
Curator: publish models and apps as a curated context.
Explorer: self-serve answers draw first from existing models/projects; escalate back to editors when needed.
Our product org mirrors this: Editor team, Curator team, Explorer team, plus a platform team (agents, infra). We also dissolved a separate “AI team.” Now every team is an AI team.
Is Hex evolving compared to the team’s initial vision?
BI itself is evolving. AI hasn’t really changed data work yet. There are lots of demos, but little durable workflow. With our Notebook Agent, we aimed for workflows that actually work, not a thin GPT wrapper.
Our approach remains the same - build workflows that actually work, not gimmicks. That’s our north star: make analysis powerful and accessible.
So evolution is to bridge notebooks, BI, and AI in one collaborative workflow.
Exactly. We want to make data analysis both powerful and accessible, for everyone from SQL analysts to decision-makers.
We get requests for classic BI features (new charts, drilldowns). We’re building some, but the wrapper, how answers are created, audited, and consumed, will change. Hashboard accelerates this through their expertise, not by grafting their product on top.
Do data scientists need to learn SQL and Python today?
Memorizing syntax matters less. Understanding systems, modeling, and debugging matters more.
AI can write code, but not reason about data. Analysts should learn by building projects over courses. Employers care more about thinking, prioritization, and communication than knowing every function name.
Syntax memorization matters less. Conceptual understanding matters more: systems, data modeling, how pieces fit, how to debug when AI-written code breaks. Learn by building projects and using tools, not by rote. Employers value how you think, prioritize, spot problems, and communicate with stakeholders over trivia about language syntax.
Thank you, Barry!
Find Barry:
Learn more about Hex:
Hex - https://hex.tech/
Hex product guide - What is Hex?
Hex blog - https://hex.tech/blog/









Nice piece, love the product. Super important tag at the end: context > syntax. I think about this everyday: how tomorrow’s winners will be deep generalists: those who know the systems best.
Applications for analysts: know the business, how value is created and destroyed within the org. Know the market behind the business. We’re all GMs now, with Agentic technical capabilities.
I've just noticed your cross-post on Linkedin and deleted my comment here. Let's move the discussion there.