Show notes
What's up everyone, today we have the pleasure of sitting down with Julie Beynon, Head of Analytics at Augment Code.(00:00) - Intro
(01:07) - In This Episode
(04:13) - Breaking Into Data Without A Computer Science Background
(06:05) - Why AI Made Building Cheap But Maintenance Expensive
(09:25) - How To Push Back On AI Projects Without Killing Momentum
(12:28) - Building AI Agents That Multiply A Two Person Data Team
(16:29) - When Not To Reach For AI At Work
(22:23) - Running A Lean Data Team As A Force Multiplier
(27:28) - The Spreadsheet Test For Keeping Your Data Stack Simple
(31:49) - How To Prove The Value Of Invisible Data Work
(39:14) - Why Data Analytics Is Becoming GTM Operations
(41:47) - What Part Of The Data Analyst Job AI Is Replacing
(47:15) - The Data Skills AI Can't Replace
(52:07) - How To Decide What Deserves Your Energy
Summary: Julie Beynon came into data sideways from content marketing, got cut down to 2 words by a CEO, and turned that into a 15-year career running lean data teams. In this episode she breaks down how she cloned her best analyst into an AI agent named JimBot, why she pushes back on AI projects without ever saying no, and how she gets companies to fund the invisible foundation work nobody claps for. She makes the case that AI knocked down the SQL wall, so the real bottleneck moved to the data model underneath, and that simple is now the hardest skill in the room. There's a spreadsheet test, a team of 2 that runs like 10, and a surprisingly hopeful take on AI making us more human. Stick around for the part where she explains why the boring option takes the most nerve.About Julie BeynonJulie Beynon is the Head of Analytics at Augment Code, an AI coding assistant company, where she runs a lean data team and builds AI agents that let the whole company self-serve trusted answers. She's spent roughly 15 years in data and go-to-market analytics, previously leading data at Census and analytics at Clearbit, with earlier stops at Customer.io and other startups.She's self-taught and came into data sideways from content marketing, with no computer science background. Alongside the day job she writes a series of short essays on data, AI, and the discipline of knowing when not to reach for a tool.Breaking Into Data Without A Computer Science BackgroundMost people assume the path into data analytics runs through a computer science degree or at least a few years buried in SQL. Julie's route looked nothing like that. She started as a content marketer, and by her own account she was bad at it. Her CEO once edited a piece of her writing down to 2 words.That kind of feedback breaks a lot of people. It did the opposite for her. Getting cut down that hard built a habit of raising her hand for whatever nobody else wanted to do, and the thing nobody wanted to touch was data. The real turn came at Customer.io, where a new tool called dbt showed up and someone offered to train her on it. She figured saying yes would be silly to pass up, and within a few sessions the whole job changed shape.The moment she describes is the one every self-taught analyst recognizes. You take a pile of raw rows nobody trusts, run it through a model, and suddenly you're holding something a whole company can use. She calls it realizing what power she had just yielded. The intuition that makes her good now got built out of the failures that came first, then an open door she was willing to walk through. Coming at data from content rather than engineering is why she reads the business side so well, because she learned the questions before she learned the syntax.Key takeaway: Volunteer for the messy, unowned work on your team, especially the data nobody wants to clean. Pair it with one modern tool you can learn hands-on, like dbt, and get a colleague to walk you through a real project rather than a tutorial. The reps you build on work nobody else will do become the skill set that's hardest to replace later.Why AI Made Building Cheap But Maintenance ExpensiveAI has made it trivial to spin something up. A dashboard, a workflow, a scrappy internal tool, all of it now takes an afternoon and a few prompts. The problem is that the fun part and the expensive part were never the same part. Julie's been making this argument since before AI showed up, in a build versus buy post she wrote 5 years ago, and the tooling change only sharpened it.Here's the trap she watches teams fall into. Someone builds a slick dashboard because they can, everyone's impressed, and then 6 months later sales walks up asking why a number moved. There's data drift, nobody remembers how the thing was wired, and the person who built it isn't the one who has to answer for it. She's the one who answers for it. So before anything gets built on her watch, she runs it through a short set of questions:Is this mission-critical, or just fun to make?, Who owns it and who maintains it when it breaks?, Is there an off-the-shelf tool that costs less per month than the tokens it takes to build and run this?That last one lands hard. You can burn $1,000 building something that replaces a tool costing $5 a month, and feel productive the whole time. The cheap build is a real cost hiding as a win. Maintenance never got cheaper, which means the discipline that matters now is refusing to build the thing you're perfectly capable of building.Key takeaway: Before you build anything with AI, price the maintenance, not the build. Ask who owns it in 6 months, whether it's mission-critical, and whether a paid tool would cost less than the tokens you'll spend building and running your own version. If the honest answer is that you're building it because it's fun, buy the tool instead.How To Push Back On AI Projects Without Killing MomentumOps and data people carry a reputation as the team that says no. Every shiny new tool, every "we should build this," runs into someone whose job is to point out that you already own 2 things that do the same job. That instinct matters more than ever now that anyone can build anything. It also curdles fast into being the person nobody wants to bring ideas to.Julie's answer is to almost never say no at the door. There's a real constraint underneath her patience, since on the data side you have an actual duty to protect the data and the security around it, so some requests genuinely can't fly. Outside of that, she lets people run.That quote comes from a specific win. One of her engineers built a proof-of-concept dashboard for a new product. It worked. Instead of telling him to stop, she treated it as a starting pad and let him take the first pass as far as he wanted. AI helped him productize and visualize what he was thinking. Then, when the question became how to make it sustainable, she stepped in and rebuilt it as a stable dashboard in their BI tool with observability and role-based access control baked in. The engineer knew every data point and how it was tracked, so she pulled the context straight out of his code instead of extracting it from him in a meeting. She calls it one of the most productive data cycles she's had. Letting someone go a few steps before you take the wheel turns pushback into a handoff, and the person feels seen instead of shut down.Key takeaway: When someone brings you an AI-built prototype, resist the reflex to kill it. Let them take the first pass all the way, then offer to productize it yourself, pulling the logic and context out of their code rather than dragging it out of a meeting. Reserve your hard no for genuine security and data-protection lines, and treat everything else as a draft you can finish.Building AI Agents That Multiply A Two Pers...