Give analysts their thinking time back

“How are you so fast?”

People at work ask me some version of this a lot. The honest answer is that I’ve never worked anywhere before AI. I’ve only known startups, and I picked up AI tools as soon as they were good enough to trust. So to me, my pace isn’t mystical. It’s just how the work gets done now.

Here’s what that looks like. The two biggest systems I’ve built (a workforce quality assurance pipeline and a billing integrity pipeline) each had a working prototype within a week or two. Work that used to take me a week now takes a day. I’m not typing faster. AI writes the code, and I spend my time on the decisions.

To be clear, a two-week prototype isn’t the finished product. Both systems took months of iteration, feedback and hard edge cases to become what the company runs on today. But the starting line has moved. When a working version takes two weeks instead of two quarters, the year after it goes to making it great instead of making it exist. I used to work at NASA, so I don’t use the word “moonshot” lightly. But give a team a year with these tools, and the ceiling is a lot higher than most people think. That’s the outlook I want my team to have.

That’s the whole idea of this essay: give analysts that same trade. AI handles the grunt work, and the analyst gets their thinking time back.

Humans own the validation layer

Here’s the workflow. AI builds a model in seconds. The analyst doesn’t go line by line troubleshooting syntax. They check what actually matters: the major logic decisions, the grain, the conventions, and whether the answer makes sense for the business. The AI builds. The human owns the validation layer.

That doesn’t mean analysts don’t need to know how to code. I think it’s like math. Every mathematician spent a year doing long division by hand in grade school. No PhD mathematician gives up their calculator, but you also wouldn’t trust one who never learned division. They checked that box early, so they know when the calculator’s answer is wrong.

Analysts are the same. An analyst who has never written a join can’t spot a bad one. Learn to write the code first. Then stop writing it, and start orchestrating the AI that does.

The analyst who matters is the one at the table

The point of the time saved isn’t more tickets. It’s getting analysts into the rooms where product and business decisions get made. A data-led voice in those rooms is rare and very valuable: the person who asks “how would we know if this worked?” before launch, who sees that a proposed metric would misclassify half the population, who notices a dashboard is measuring the reporting process instead of the outcome.

Some of my most useful work came from having room to think, not from writing more code:

• I noticed that a proposed pilot could only detect a very large effect. That let us redesign it with a holdout and a pre-registered plan, and showed that the real constraint was hiring volume.
• A capacity problem everyone read as “not enough people” turned out, when I modeled it, to be a distribution problem. That reframing became the team’s top priority.
• A program’s detection numbers looked weak. I traced it to how they were counted, and fixing the measurement changed how leadership read the whole program.

None of that took clever code. It took slack in the week. The goal is to make that slack normal for every analyst.

How to give it back

• Self-service on governed data. When definitions live in a semantic layer and the team’s knowledge lives in a context layer, routine questions get answered without a ticket. (How I built those layers is in The data layer is three layers now.)
• Standards inside the tools. Verifying queries, scoping tickets, preparing pull requests and reviewing work are built into every analyst’s AI assistant, so a newer analyst’s work meets the team’s bar from their first week.
• Protect the saved time. Freed-up hours fill with more tickets unless you point them at stakeholder work: sitting with the requester before the build, asking what decision the analysis is for, getting the right people into the room.

The human side is the hard side

The tools are the easy part. The shift in how people work is the hard part.

We’re in a strange transition. A lot of good analysts take real pride in solving and troubleshooting code by hand, and that pride is earned. Asking them to hand that to an AI can feel like being asked to give up the part of the job they’re best at. Willingness to work this way varies a lot from person to person.

What works is a fast first win. I seeded our team’s context layer with months of prior work, so an analyst’s first AI session already knows their projects and their traps. The aha moment, when the assistant does in minutes what used to take an afternoon and gets it right because it knows the team’s history, does more than any announcement.

I directly manage two analysts and coach others less formally. With all of them, I review reasoning more than code: why this grain, why this filter, what would make this answer wrong. One of the analysts I coach went from new to the team to the second-biggest contributor to our context layer within a few months.

Measure the right thing

When AI does the building, ticket counts stop meaning much. A day’s work can be one hard problem or twenty trivial ones. Measure the complexity of what the team takes on, and how often their work changes a decision. That’s the output that matters.

If you lead analysts

• Go first. Change your own workflow before asking anyone else to.
• Make sure analysts can write code, then free them from writing it.
• Put the human on the validation layer: logic, grain, conventions, business sense.
• Build self-service on governed metrics, never on raw tables.
• Engineer the first win. Adoption follows the aha moment.
• Measure complexity and impact, not ticket counts.