Data leadership: what I learned building analytics teams from the ground up

Fifteen years across retail, e-commerce, and loyalty programs taught me that the hardest part of data leadership is rarely the data.

I did not start with a roadmap. My first analytics role was closer to archaeology than strategy -- digging through transactional data, writing SQL late into the night, trying to find signals in noise that no one had bothered to look for before. What I did not realize then was that those early years of individual contribution would become the most important credential I would ever carry into a leadership role.

Over fifteen years, across retail giants and fast-scaling e-commerce companies, I built and led analytics organizations that influenced billions in revenue -- not by having the best models, but by learning, often the hard way, how to make data actually matter inside a business.

Structure follows strategy, not headcount

Early in my career, I watched analytics teams get built the wrong way: a data scientist here, a BI engineer there, reporting into whoever had budget that quarter. The result was siloed work, duplicated effort, and insights that died in slide decks.

When I built my own teams, I started with a different question: what decisions does this business need to make, and who is currently unable to make them confidently? Centralized data teams work best not because they consolidate power, but because they create a shared language. When every part of the business defines a metric differently, trust in data collapses. Centralization solves that.

The real unlock was not better tooling. It was getting everyone to agree on what a customer even was.

Pick the metric that changes behavior

The most dangerous thing in analytics is a metric that looks right but drives the wrong behavior. I have seen teams optimize email open rates while quietly destroying customer relationships through over-communication. I have seen conversion rate improvements that masked a long-term erosion in customer quality.

At one point, I created a metric we called NSPAC -- net sales per active customer -- because revenue alone was hiding a dangerous trend in customer base quality. That one number changed how leadership evaluated growth for years.

When to push back -- and how

Data people are often too deferential. We present findings with caveats, hedge our conclusions, and then watch a decision get made on gut feel anyway. The rule I gave my teams: push back on the metric, not the business goal. No one wants to be told their strategy is wrong. But most leaders will listen when you show them that the measurement they are using cannot actually tell them whether the strategy is working.

Pushing back during planning is influence. Pushing back after a decision is friction.

Building a culture of extreme ownership

The shift that changed everything for my teams was moving from a service model to an ownership model. In a service model, analytics answers questions. In an ownership model, analytics asks them first. I pushed my teams to own outcomes, not outputs -- not "here is the analysis you requested" but "here is what I found, here is what I think you should do, and here is how we will know if it worked."

AI is a force multiplier, not a replacement

I have used AI to automate reporting that once consumed entire weeks of analyst time. I built a self-serve system that gave non-technical marketing teams direct access to customer targeting insights, reducing dependency on data teams and cutting decision timelines significantly. The analysts who were spending 70% of their time pulling data suddenly had capacity for the work that actually required judgment.

The leaders who will get this wrong are those who deploy AI as a cost-cutting measure before they have invested in data infrastructure and data literacy. AI amplifies what is already there. If the foundation is weak, you move faster in the wrong direction.

For those who never had formal training

My path into analytics leadership was not linear, and it was not credentialed in the ways that people assume it should be. The technical skills are table stakes, and they are learnable. What is harder to learn -- and rarer -- is the ability to sit in a room full of executives and translate uncertainty into a clear recommendation.

The best data leaders I have seen share one quality: they are deeply curious about the business, not just the data. The data is just how they express it.