Building got cheap. Maintaining didn't.

I wrote a build vs. buy post about five years ago. The principles are still the same. AI just accelerated the ability to build.

It's really fun to build. It is not fun to maintain. And once you're past that dopamine hit of building, somebody still has to own the thing. That's the part people skip.

So when someone wants to build something, I push back. Is it mission critical? Who's owning it? Who's maintaining it? Six months from now when sales asks about that number on the dashboard you built, are you answering it? Am I? And what happens when there's data drift?

It's really easy to spin up that cool dashboard. It's really easy to spin up that cool workflow. But when it breaks in six months, we're actually worse off.

And there's a cost to AI, right? You can spend $1,000 in tokens on something a $5 a month tool already does. That is a reality. The ROI isn't actually there.

Letting people run with it

I try not to say no to everything. Although with data there's a layer where you have to protect it, right? So the security side is part of the calculation too.

There's a really great example from recently. One of our engineers built a proof-of-concept dashboard for one of our new products. And it's great, it works well. So instead of saying I don't want you to continue building that, I let him run with it.

Then it's okay, this is an amazing starting pad for me to go productize. I turned around a stable dashboard that's maintained in our BI tool, with all the observability and the role based access control.

It was one of the most productive data cycles I've had. He knew every data point. He knew how it was tracked. He knew everything about it. So instead of sitting in a meeting taking that from his brain, I just took it from his code.

There's a bit of watching people go where they want to go. Instead of saying no immediately, it's okay, show me what it is you're thinking. And then you work off of that.

Jim, Jimbot, and Mimi

We're a team of two. Me and Jim, our analytics engineer.

I've always thought I just want to hire more of this. A hundred more Jims. And with AI, Jim created this expert and we aptly named it Jimbot. So now we have this sort of junior analytics engineer with Jim's brain and Jim's logic.

Our engineering team is working significantly faster now. There's 10x of them compared to us. So Jimbot just gets the data in and works with the brain, follows the rules. I don't have to think about what Jim set up. I just say hey, add this data, right in a Slack message. And it builds me an entire PR, runs it, tests it. I don't have to go into dbt. I don't write code anymore.

Then we have Mimi, which is the analyst I've created. She has the way I think about structuring data questions. She has all the context I have, all the skills. And whenever anybody calls Mimi in Slack, I don't have to do ad hoc questions.

That was a lot of our time. Stopping your work, looking at the question, addressing the question, auditing the question, and then going back. A lot of those questions are pretty straightforward. Mimi does the triage.

I've always been a proponent of dog fooding where you work, so both are built on Cosmos, our own unified layer. It has access to all of our code. It's that cross-departmental context engine. Our CEO uses Mimi and he didn't even know it existed, because the system is so integrated it just points him to it.

I monitor every single one of the questions that come in and make sure it's not wrong. We've added observability into our experts. I can see everything that's queried. It doesn't answer questions it's not supposed to, anything PII or sensitive, it's locked in. And it has a confidence score. Especially when I was trying to build adoption, I'd come in and go yep, that's right. Yep, that's right. And that's the building of the trust.

We have our company self-serving data now, off the dbt models. We keep that house really, really clean.

When I caught myself being lazy

Do you want the honest answer? Hex started charging for their AI agent.

I had gotten kind of lazy. I was asking it to do things that would have taken me less time to write. And so there became a cost to that. There became a cost to my laziness.

These are things I know how to do. These are things I know how to do better than the agent. And I was writing a sentence-long prompt, twice, to get where x equals y.

I pride myself on being efficient. Lazy smart. But I was actually just being lazy lazy in that moment, and I felt like I was losing the muscle and the instinct of when to just go to your own skills.

The rule now: if I already know how to do it, I do it. No prompt.

Understanding the problem is the muscle

I think about juniors a lot. If writing the SQL filter is quicker with AI versus you doing it, no worries, that's okay. You don't need to have those reps in.

What you need to understand deeply is the problem.

What I see sometimes with junior folks is they'll just throw the question immediately to AI. And it's that muscle of, I need to be the operator of this machine. I need to understand where things are. I need to understand where to point it. I need to understand what questions to ask. I need to understand what wrong looks like.

If you don't understand any of that, you're just consistently prompting it and hoping.

And QA is never going to go away. Something I like to do is throw my work to somebody junior and say, can you QA this for me? So it's not just me QAing their work. They need that muscle, because you need to know what wrong looks like.

Service center or multiplier

My first maybe six, seven months at Augment, I was a service center. I was operating as that, because there wasn't anything in place. And because the foundations weren't in place, I couldn't multiply. It was hard to push back, because there wasn't anything built.

In the first year or so, if you're building a data team from scratch, you're building out foundations while also flying. So you are going to have to build that dashboard. You are going to have to be the quote unquote service center. And that's fine. There is value derived from getting someone their answer.

But long term the goal is the multiplier. Fun fact, the team at Augment was at 1.4, and that was the biggest team I've ever run. I've had budget and I've had approval for bigger teams.

So it's always been, how do I make the data team a multiplier? How do we multiply ourselves so we don't need to grow at the rate the company grows? Because when we become a service center, we've lost a lot of our value.

Making invisible work visible

Foundation work is invisible. Nobody gets excited about a clean data model.

Before, I had to do enablement. I had to teach people how to use it. I had to market and sell myself in ways so they could understand why I was putting time and energy into this work. That's how you got more time and more allowance to do it.

Now we just hyperfocus on building a good foundation and building a solid bridge into it.

The AI analyst is the bridge. They may not understand why the analyst is giving them the right answer, or why their data is so correctly modeled. But they understand that they can. The feedback we get is oh, it's getting better, because we're constantly tweaking the foundation.

We have an auto-redirect, so any question inside our unified system goes right to my analyst. You can be a new hire on day one. Nobody needs to know it exists.

All that enablement is inside the AI now. Historically you had to do it manually. Now it sells the work for us, and that's what buys us the room to keep building foundations.

What AI actually replaces

I probably have a skewed opinion, because the parts of being a data analyst that I hated are what's going away.

All those ad hoc questions. Building dashboards. I can build a dashboard now with four or five prompts. It's a morning task with my coffee.

Where the analyst gets stronger is understanding how to communicate effectively, how to storytell with data, and how to keep the team hyperfocused. Because now I can build a dashboard with a hundred metrics. That has never been the right answer.

You're almost like a data product manager. Your job is more about talking to the stakeholders and really getting their process, versus taking their request. You step into their lane a little bit. You understand what their business is and what they think of as success.

Then you build the thing in four or five prompts and you give them something truly valuable. Versus a dashboard that took six months to build and doesn't really answer the question.

Simple is the harder skill

Explaining that adding a third or fourth layer to your data pipeline is not a good idea is usually all I have to say. And anyone who's worked with me knows I love a Google Sheet. Could a spreadsheet handle this for now?

It comes down to really understanding the problem. If you understand the problem, the solution becomes a lot easier.

AI has turned the volume up to like 100. And I see a lot of people going, look how cool this is, I built this. Then somebody builds another version of it. And I'm like, yeah, but that's not what we needed.

A lot of companies right now have six people building the same thing. One's green, one's red, but they're all kind of the same thing. And they're wondering why they're not getting the productivity gains from AI they expected. Each individual feels more productive. As a whole, it's done the same thing six times.

When you stay focused on what you need, you don't need the pipeline. You need those five things in the Google Sheet.

I'd be a liar if I said I didn't occasionally build one of those just because it's fun. But most of the time I'm trying to stick to what the company needs. Does this line up with the goal?

Where the job is going

If I had a list of items to do, GTM ops would be at the top. That's where I spend my time and that's where I'm moving my energy now.

Data kind of lives in this place where we see everything. And you can see problems before they happen. We all saw these problems. You're just like, that's not totally my problem, so I won't jump into it.

Now I have some time. Someone has questions about the sales dashboard. It's not a data problem, but it lands in data land, because the questions are coming to you. So okay, what is it they don't know? How do we communicate that? How do we train it?

Success looks like somebody who weaves the company a little bit tighter together, through processes and through data. It's vague, I know. It's vague because the problems can be broad. But now you see all of them, and you can act on them, or at least advise.

What deserves your energy

If you'd asked me this five years ago, it would have been a weekend trip to Martinique. Now, as I get older, it's the simple things. Doing what I say I'll do.

It's not so much what gives me energy. It's what doesn't take it away. You're not fighting yourself, like I'm a healthy person and yet I'm not going to the gym. Those drifts between who we are and how we're behaving are what cost you.

It's very boring, very simple. Just doing the things you say you're going to do. I'm making life easier for future me.