Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS
What’s up everyone, today we have the pleasure of sitting down with Julie Beynon, Head of Analytics at Augment Code.
Summary: Julie came into data sideways from content marketing and turned that into a 15-year career running lean data teams at some of the coolest martech startups in the landscape. In this episode she breaks down how they cloned their 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. There’s a spreadsheet test, a team of 2 that runs like 10, and a surprisingly hopeful take on AI making us more human.
In this Episode…
- Why AI Made Building Cheap But Maintenance Expensive
- How To Push Back On AI Projects Without Killing Momentum
- Building AI Agents That Multiply A Two Person Data Team
- When Not To Reach For AI At Work
- Running A Lean Data Team As A Force Multiplier
- The Spreadsheet Test For Keeping Your Data Stack Simple
- How To Prove The Value Of Invisible Data Work
- Why Data Analytics Is Becoming GTM Operations
- What Part Of The Data Analyst Job AI Is Replacing
Recommended Martech Tools and Agencies 🛠️
We only partner with products and agencies that are chosen and vetted by us. If you’re interested in partnering, reach out here.
🔌 GrowthBench: Twilio’s top-tier consulting partner, turning your Twilio investment into a customer engagement engine
🔄 GrowthLoop: The agentic, composable CDP that drives compound growth by uniting your cloud data + AI into one marketing engine.
🎨 Knak: Go from idea to on-brand email and landing pages in minutes, using AI where it actually matters.
📧 MoEngage: Customer engagement platform that executes cross-channel campaigns and automates personalized experiences based on behavior.
About Julie
Julie 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 Background
Most 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.
“I was writing content and the CEO only left the words ‘and’ and ‘the’.”
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.
Back to the top ⬆️
Why AI Made Building Cheap But Maintenance Expensive
AI 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.
“It’s really fun to build. It is not fun to maintain.”
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.
Back to the top ⬆️
How To Push Back On AI Projects Without Killing Momentum
Ops 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.
“Instead of me having to sit in a meeting and take that from his brain, I just took that from his code.”
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.
Back to the top ⬆️
Speaking of using AI tooling… are you still operating like it’s 2013 and you haven’t updated your chatbot? We recently started collaborating with the Docket team and what they are building with their Inbound Demand Agent is super cool. Check it out.
Building AI Agents That Multiply A Two Person Data Team
Ask most data leaders what AI unlocked and you get vague answers about speed. Julie has a specific one, and it starts from a specific pain. Her team is 2 people, she has an analytics engineer named Jim, and for years her fantasy was simply to hire 100 more of him. So they built one.
“I just wanna hire 100 Jims. With AI, Jim created this expert, and we aptly named it JimBot.”
JimBot is a junior analytics engineer that carries Jim’s brain and Jim’s logic and follows Jim’s rules. It matters because their engineering team ships roughly 10 times faster than 2 people can keep up with. When new data lands, Julie drops a line in Slack asking to add it, and JimBot builds the entire pull request, runs it, and tests it. She doesn’t open dbt. She doesn’t write code anywhere. The data gets into the semantic layer, modeled and optimized, without her building the pipeline by hand.
The second agent is Mimi, an AI analyst she built in her own image. Mimi holds the way Julie structures data questions, her context, her skills. Anyone in the company can call Mimi in Slack and get an answer, which retired the single most draining part of the old job. The ad hoc question used to mean stopping your work, reading the request, answering it, auditing your own answer, then clawing back into what you were doing. That whole loop is gone. The company self-serves off clean dbt models that Julie and Jim keep tweaking almost hourly, and she means it when she says she never wants to answer an ad hoc question again.
How The AI Agents Are Built On An Internal Platform
The build itself runs on the company’s own product. Julie has always been a believer in dogfooding wherever she works, and Augment Code has a tool called Cosmos that gives her a unified layer for building these experts. Cosmos has access to all of their code, which makes it a cross-departmental context engine rather than a chatbot bolted onto a warehouse. The proof that it’s working is quiet. She built the analyst, and their CEO started using it without knowing it existed, because the system is integrated enough that it just routed him there. Agents that live inside the code base and the company’s real context beat agents you have to go find.
Key takeaway: Turn your best analyst’s logic into a reusable agent instead of trying to hire copies of them. Give it your real models, rules, and context so it can build and test pull requests or answer questions in Slack, and wire it into the tools people already use so adoption happens without a rollout. Start with the task that drains you most, which for most data teams is the ad hoc question queue.
Back to the top ⬆️
When Not To Reach For AI At Work
There’s a version of efficiency that’s actually decay. You reach for AI to do something you could do in your sleep, tell yourself you’re saving time, and slowly lose the instinct that made you fast in the first place. Julie caught herself doing exactly this, and instead of calling it efficient she called it a problem.
The trigger was almost petty. Hex started charging for its AI agent, so every lazy prompt now had a price tag attached to it. She’d been asking the agent to write SQL filters she’d written 100 times, things where she already knew the answer was where X equals Y. Writing a full sentence to prompt it, then correcting what it missed, was slower than just doing the work. The cost forced the reflection.
“I pride myself on being efficient, but I was actually just being lazy in that moment.”
The rule she landed on is simple. If you already know how to do something, just do it, no prompt. The uncomfortable part is what happens when you don’t follow it. Every rep you outsource is a rep you don’t bank, and the skills atrophy quietly enough that you don’t notice until you need them. Treating a paid AI agent like a running tab is one accidental way to feel that cost, but the principle holds even when the tool is free.
What Junior Analysts Lose When They Skip The Reps
Julie’s own instinct came from 15-plus years of boring work, the exact work AI now does for her. So the harder question is what happens to the analyst who’s early in their career and never gets those reps, the Julie from 10 years ago who reaches for Mimi before building the muscle. She thinks about it a lot, and her answer reframes the whole worry. The reps that matter were never the SQL. If a filter is quicker with AI, fine, you don’t need that rep. What you need is to understand the problem deeply enough to operate the machine.
“You need to know what wrong looks like, and you need to understand the problem.”
What she sees juniors do is throw the question straight at AI and hope. The muscle they skip is knowing where to point it, what to ask, and what a wrong answer looks like when it comes back. QA never goes away, so she builds it deliberately by handing her own work to a junior and asking them to check it. That flips the usual dynamic. Instead of only reviewing their work, she makes them review hers, because you can’t catch what wrong looks like until you’ve had to look for it.
Key takeaway: Set a personal rule that anything you already know how to do, you do without prompting AI, so you keep the instinct sharp. For anyone junior on your team, stop measuring them on syntax and start building the judgment muscles, understanding the problem and knowing what a wrong answer looks like. Hand them your own work to QA so they learn to spot errors before they trust an agent to avoid them.
Back to the top ⬆️
Running A Lean Data Team As A Force Multiplier
The common fear about AI and junior talent is that companies will lean on tools instead of mentoring people. Julie runs a data team of 2, and she’s led far bigger, so she’s a useful person to ask what a leader actually builds into a team when the headcount is thin. Her answer starts with a stat that surprises people.
“We’re not a service center. We are a multiplier. When we become a service center, we’ve lost a lot of our value.”
The biggest team she’s ever run topped out at 4 people. She’s had the budget and the approval to grow bigger and chose not to, because her whole model of the job is leverage. The goal is to make the data team a multiplier so it doesn’t have to grow at the rate the company grows. Even years ago, when Census and Hightouch first arrived, she saw reverse ETL as a way to multiply her work by pushing data into Salesforce and Marketo so the sales and marketing teams could act on it without her in the loop. Sometimes you still do the admin work and just answer the question, because sometimes you have to. Most of the time, though, the mentorship is an ideology more than a curriculum. You keep asking what outcome you want and what work makes the people around you 2 or 3 times more productive.
How To Escape The Service Center Label
Knowing you should be a multiplier doesn’t stop people from lining up with 3 more dashboard requests. So how do you actually break the pattern where every conversation about leverage ends with “great, but can you just do these 3 things first”? Julie’s honest about the order of operations. Her first 6 or 7 months at Augment Code, she was a service center, full stop.
“If you are building the data team from scratch, you are building out foundations while also flying.”
You can’t multiply on top of foundations that don’t exist yet, and in the first year of building a data team from nothing, you’re laying track while the train moves. That means building the dashboard and the report and wearing the service-center label for a while. The trick is holding the multiplier vision in your head the whole time. There’s real value in getting someone their answer, so she’s fine being seen as a service center early, because delivering that first answer is the stepping stone that buys her the room to build the leverage layer in the background.
Key takeaway: Treat your data team as leverage rather than a request queue, and measure work by how much more productive it makes everyone else, aiming for a 2 to 3 times multiple. Accept that a brand-new team has to earn that position by answering the early one-off questions first, so deliver those wins while quietly building the foundations underneath. Keep the multiplier vision explicit so the service-center phase stays a stepping stone instead of the whole job.
Back to the top ⬆️
The Spreadsheet Test For Keeping Your Data Stack Simple
Open Scott Brinker’s martech landscape and you feel it immediately, that low hum of unease at how many ways there are to do the same thing. Julie’s written that the best data people are the ones who know what to leave out, and she’ll happily fix a broken pipeline with a Google Sheet while someone next to her ships a custom Kafka to Airbyte to BigQuery to dbt to Dagster monstrosity. The nerve to choose boring is its own skill. It’s also getting harder to hold onto, because AI turned the volume on how fast you can build up to 100.
The devil’s advocate is obvious. AI now builds the impressive version in an afternoon, so why not let it? Because the build getting cheaper never made the maintenance cheaper, and the only thing that keeps you out of trouble is understanding the problem well enough to know what you actually need.
“You don’t need a pipeline to a Google Sheet. You need what those five things in the Google Sheet are.”
Her mental model is X and Y. X is what the company needs. Y is the cool thing you can build. She watches people race to build one version of Y, then another version of Y, then a third, everyone feeling more productive while the company gets nothing new. 6 people build Y 2.0, one’s green and one’s red, and they’re all secretly the same thing. Then leadership wonders why the AI productivity gains never showed up. The math is brutal. Each person feels faster, and as a whole the team just did the same thing 6 times. Staying hyper-focused on X is harder now precisely because you can build anything, so the discipline of asking whether a thing lines up with the goal is worth more than the ability to build it. She’ll admit to building a Y now and then just because it’s fun, but the job is X.
Key takeaway: Before building anything, ask whether a spreadsheet could hold the 5 things you actually need right now. Separate X, what the company needs, from Y, the impressive thing you could build, and kill the Y projects even when AI makes them cheap. When a team feels productive but ships nothing new, check whether several people have quietly built the same thing in parallel.
Back to the top ⬆️
How To Prove The Value Of Invisible Data Work
Foundational data work has always had a marketing problem. You can’t screenshot an ontology for a board slide, clean definitions don’t demo, and nobody claps for a well-modeled revenue table. It’s the eternal ops and data-team bind, doing the work that only gets noticed when it’s missing. Julie is unusually good at getting companies to fund it anyway, and her method has changed with AI.
She’s lived the failure version. She once built a lead score in her free time, thought it was genuinely cool, and watched it get zero adoption. The foundations her team builds now are the same kind of unglamorous work, and people weren’t buying in either. What changed is that AI gave her a way to translate the foundation into something people can use.
“AI has allowed us to create this bridge into our foundations in a way that translates it.”
Stakeholders don’t need to understand why the AI analyst returns the right answer or why the new data is modeled correctly. They just need to cross the bridge and get their answer in Hex. The feedback loop does the selling for her. People notice it keeps getting better, which is true, because she and Jim tweak the foundation constantly. The old job meant running enablement, teaching people, and marketing herself so leadership would grant time for the invisible work. Now the team hyper-focuses on building a good foundation and a solid bridge, and when someone shows up with a question, she keeps pointing them at the bridge until they walk across on their own.
How AI Becomes A Bridge Into Your Data Foundation
The bridge is a chat interface, but the interesting part is everything behind it. Julie monitors every question that comes in to confirm the answer isn’t wrong, and the experts carry observability so she can see everything that gets queried. The system won’t answer anything it shouldn’t, so PII and sensitive data stay locked, and every answer ships with a confidence score. Early on, building adoption meant she’d sit behind the analyst and confirm each answer with a simple “yep, that’s right,” over and over, until people trusted it.
“Now all of that enablement is inside of AI, and it sells our products for us.”
Compare that to the old marketing-ops playbook for a new lead score. You’d pick a few people, teach them, prove their success, then train and onboard and write documentation. All of that enablement now lives inside the AI. An auto-redirect catches any data question in their unified system and routes it to her analyst, so a new hire on day one gets answers without knowing the analyst exists. The constant selling of every internal Ferrari she used to build is gone, replaced by a system that sells the work while she keeps improving it.
The First Foundational Moves When Joining A Company
Getting to a working bridge took real groundwork first. Julie came in and brought the tools she trusts, dbt for transformation after 10 years with it, and Census for reverse ETL. Tooling used correctly is the first multiplier, but the sequence underneath matters more than the logos. Her order of operations when she joins a company is specific:
- Get revenue right first. If the revenue numbers are wrong, nothing else is worth modeling.
- Define what success looks like for each team, and model that in as the questions come.
- Watch for the repeated question, because the thing people keep asking about is the thing that belongs in the foundation.
That covered the first 3 to 6 months of systems work, which came easy because she’s stood up the same stack at many companies. The genuinely hard part was understanding how this specific business operates, plus learning BigQuery from scratch. Every time you land at a new company with a different warehouse, you feel like a beginner again, hunting for where things are and how to find X.
Key takeaway: Stop trying to sell your foundation work directly and build an AI layer that lets stakeholders self-serve answers off it, complete with observability, confidence scores, and PII guardrails. Route every data question to that analyst automatically so adoption needs no rollout. When you join a company, get revenue numbers right in month one, then model each team’s definition of success as the repeated questions reveal what belongs in the foundation.
Back to the top ⬆️
Why Data Analytics Is Becoming GTM Operations
Job titles in this world have gotten slippery. The same person might be called a data analyst at one company, a GTM engineer at another, and revenue operations at a third, doing roughly the same work under all 3. Julie has spent her whole career at startups where you get your hands dirty everywhere, so dropping her into an enterprise org is a fun thought experiment. There are 17 different functions she could plausibly own, from GTM systems to the whole data team to revenue operations.
Asked to name it, she doesn’t hesitate.
“If I had a list of items to do, the GTM ops category would be at the top.”
GTM engineer and GTM ops is where she feels she already is. The logic connects back to the multiplier idea. Once a data team starts multiplying, the work it does looks like GTM ops even when the source data or the tooling is different. The question underneath both is the same, how do you build ways for the company to move faster and get more answers, whether that means more leads or just more of the right numbers in front of the right people. She tows the line of operations and gravitates toward the go-to-market side because that’s where she started, and it’s where she’s steering her time and energy now.
Key takeaway: Stop defending a rigid job title and describe your role by the outcome you drive, which for most modern data and analytics work is GTM operations. Frame your work as building the systems that help the company move faster and get more answers, and you’ll map cleanly onto whatever the org happens to call the function. Steer your time toward the go-to-market problems where a data team’s multiplier effect is most visible.
Back to the top ⬆️
What Part Of The Data Analyst Job AI Is Replacing
For a long time the data analyst job was a ticket queue. A request comes in, you build the dashboard, you ship it, you gather feedback, you do it again. That version of the role is genuinely exposed now, because converting a plain-English question into SQL and standing up a visualization has gotten easy. Julie frames the change as a shift in where the value sits, and she’s upfront that her read is skewed, since the parts of the job disappearing are the parts she always hated.
“I can build a dashboard now with four or five prompts. It’s a morning task with my coffee.”
The ad hoc questions and the dashboard grind are the easy part now, a thing you knock out while the coffee brews. The catch is that you can build a dashboard with 100 metrics that answers nothing, so speed without judgment just gets you to the wrong artifact faster. Where the analyst gets more valuable is upstream and downstream of the build. You have to understand the problem well enough to recognize it in seconds, and you have to communicate and tell a story with the data once you have it. She describes the modern analyst as the data product manager of the storytelling, the person who decides what’s important and keeps the team focused. That means stepping into the stakeholder’s lane, learning their business and their definition of success, so the dashboard you generate in 4 or 5 prompts is the one they refresh daily because it actually helps. AI makes you a better analyst only if you spend the reclaimed time on figuring out what good looks like.
The Hiring Signal That Matters More Than Technical Skills
If dashboards are a morning task, what do you screen for when you get to add a person? Julie weighs the same things she always has, just with the hard skills dialed down in the mix.
“The questions they ask tell you a lot, how curious they are.”
Curiosity is a proxy for the work itself, because those are the questions the person will one day be asking stakeholders and the exec team. The other signal is willingness, the range to go broad or deep depending on where the team needs them. She can’t promise what the role will look like in 6 months, so she wants a utility player with openness, a hunger to learn, and enough resourcefulness to just go figure things out. She still wants technical competence and still tests for it. It simply carries less weight than it used to.
Key takeaway: Stop measuring analysts by how fast they build dashboards and start measuring how well they understand the problem and tell the story behind the data. Push yourself into your stakeholders’ world so the reports you generate in a few prompts are the ones they actually use daily. When you hire, weight curiosity, willingness, and resourcefulness above raw technical skill, since the questions a candidate asks predict the value they’ll create.
Back to the top ⬆️
The Data Skills AI Can’t Replace
Play it forward a few years, to the point where the tools and the stack are commoditized and everyone can build the same things. What’s left for the human in the seat? Julie points to the vantage point that ops, rev ops, and data people have always had. You see everything, and that lets you catch problems before they turn into problems.
“Success looks like somebody who weaves the company a little bit tighter together.”
No amount of AI removes the communication problems between teams. Her example is small and familiar. Someone named Ange has questions about a sales dashboard, and the real issue sits underneath it, in what Ange doesn’t understand and how nobody trained her on it. That lands in data land because the questions arrive at the data team, even though the root cause is a process gap. When the building work stops eating your day, you finally have time to act on the problems you always saw coming and quietly stepped around because they weren’t fully yours. The durable skill is being the person who holds the whole picture and ties it together through process and communication. Management gets vague here because the problems are broad, but the point is that you now see all of them and can act or at least advise.
She takes it one step further into something surprisingly hopeful, that the underrated truth about AI is its potential to make us more human. The example is almost mundane. She was at the gym, got a time-sensitive question, and instead of driving home to answer it, she used AI to get the answer, validated it, and went back to her workout. She sees her life getting easier this way, more time for the things that matter, more time with family and friends, less of it tied to a computer. The gains from freeing up your time aren’t only professional. They give you room to just be a human.
Key takeaway: Build your durability around the one thing AI can’t do, seeing across every team and catching process and communication problems before they surface. Use the time AI frees up to act on the friction you always noticed but stepped around, and set up the processes that weave the company tighter together. Let some of that reclaimed time land in your actual life, since more of it back is the point.
Back to the top ⬆️
How To Decide What Deserves Your Energy
Every episode ends on the same human question, how you decide what deserves your energy and how you stay aligned with what actually makes you happy. Julie is a returning guest who came on so early in the show’s life that she’d never been asked it, so this was her first turn. Her answer got simpler with age.
Years ago the honest answer might have been a weekend trip to Martinique. Now it’s the small stuff, and the mechanism she describes is less about chasing energy than about not leaking it.
“As I get older, it’s the simple things. It’s doing what I say I’ll do.”
Doing what she says she’ll do gives her energy mostly because it stops taking energy away. The drain comes from the gap between who you say you are and how you actually behave, the healthy person who keeps skipping the gym, the quiet fight with yourself that runs in the background all day. Close that gap and the fight stops. She figures the person she wants to be is fun and happy, so the things that keep her aligned tend to be fun and happy too, and every kept promise makes life a little easier for future her. She calls it boring and simple, which is exactly why it works.
Key takeaway: Audit where you’re leaking energy by fighting the gap between who you say you are and how you act, then close it by simply doing what you said you’d do. Treat kept promises to yourself as an energy source rather than a chore, because the relief of not fighting yourself frees you up for the things that matter. Keep the system boring and simple so you’ll actually stick to it.
Back to the top ⬆️
Episode Recap
Julie Beynon makes one central argument across the whole conversation. AI knocked down the SQL wall between a question and an answer, so the bottleneck moved underneath it, to the data model, the definitions, and the governance nobody sees. The data team’s job used to be getting the number. Now it’s making sure every number in the company can be trusted, which is knowledge architecture rather than SQL engineering, and it’s boring, invisible, and suddenly the whole game.
The tactical thread that connects the chapters is leverage through restraint. She clones her best analyst into agents like JimBot and Mimi so a team of 2 can serve a whole company. She refuses to build the impressive thing when a spreadsheet holds the 5 items that actually matter. She pushes back on AI projects by letting people run first and productizing their prototypes rather than blocking them. And she reframes the analyst role as a data product manager of the storytelling, someone who steps into the stakeholder’s world and decides what’s worth building in the first place.
The bigger-picture implication for practitioners is that speed is now table stakes and judgment is the moat. Anyone can generate a dashboard with 100 metrics in an afternoon, so the value shifts to understanding the problem, knowing what a wrong answer looks like, and seeing across teams to catch the friction before it becomes a fire. For rev ops, marketing ops, and data folks, that vantage point has always been the quiet superpower, and AI finally frees up the time to act on it.
Julie is honest about the tensions too. She admits her read on the analyst role is skewed, since the parts of the job disappearing are the parts she always hated. She concedes that a brand-new data team has to grind as a service center before it earns the right to be a multiplier. And she cops to occasionally building the fun, unnecessary thing anyway. The through-line she keeps returning to is that clean foundations come first and trust in AI comes second, never the other way around, and that the most valuable AI skill is knowing when not to reach for it.
Connect with Julie on LinkedIn and read her essays on data and GTM analytics on her personal site.
Full episode ⬇️ or Back to the top ⬆️
✌️
—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)
Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS
Related tags
<< Previous episode
Next episode >>
All categories
- AI (109)
- career (66)
- customer data (67)
- email (64)
- guest episode (185)
- operations (127)
- people skills (34)
- productivity (10)
- seo (6)
See all episodes
Future-proofing the humans behind the tech
Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS