Work On The Analytics Function, Not In It.
There’s a gas station near my house that I frequent because the owner is nice, has decent prices, and it’s on my way home. Every time I go in, he’s reliably inside somewhere. Usually behind the counter, but sometimes in the back, sometimes doing inventory, sometimes cleaning, sometimes restocking.
The point is, he’s always there. In fact, I’ve never been there when he’s not. I’m sure even after they close he’s there catching up on the things he wasn’t able to get done.
…Probably because I interrupted him 10 minutes before he closed to buy a bottle of wine.
The point is he’s a great operator.
There’s also one store, and there’s been one store for as long as I’ve been going. No second location, no delivery, no arrangement with the office park down the road to stock their break room. Every hour he has goes into running the place, which leaves no hours for building anything on top of it.
His business isn’t in trouble. Far from it – He’s making money he sends back to his home country, his customers like him, and he’ll probably still be there in ten years to sell me the wine I forgot to pick up earlier. It’s just the same size it was, and it’ll be the same size next year, for the same reason.
Michael Gerber’s E-Myth calls this the technician’s mistake: assuming excellence at the work is the same thing as building a company. Gerber’s version usually ends in failure. This one ends in a perfectly decent gas station that will probably never be more than a gas station. Same cause either way, which is an owner who can’t stop operating long enough to work on the thing he owns. Gerber’s fix is to work on the business instead of in it.
The data version of that myth is the analytics leader who believes a better model, a cleaner pipeline, or one more well-built dashboard will fix low influence. It won’t. You can be the strongest analyst in the building and still learn about next year’s pricing strategy from the same all-hands deck everyone else gets.
Working on the business means treating the analytics function itself as the thing you’re building. How it creates value, how work flows, and whether it produces useful stuff without you touching every project.
What “on the business” work looks like
We covered most of this across the internal and external leadership issues, but it’s worth seeing it stacked together.
External leadership is the biggest chunk. Earning executive sponsors who will defend your headcount request in a planning meeting you’ll never hear about. Tying your team’s work to strategic goals in the language the business uses, framed as problem, decision, upside/downside, timeframe. Building the business case that gets you that headcount: with today’s team we can keep revenue reporting running and take on one strategic project a quarter, with one more analyst we can ship the group pricing model by Q3, worth roughly $1.8M in incremental room revenue.
Then there’s the operating model. Deciding whether your team leans artisanal or factory, defining how intake works, setting the standards that mean you don’t rewrite every deck before it goes out. Work that lets your team decide for themselves what to drop when the CFO and the VP of Ops both want something by Thursday.
And there’s relationship architecture, which sounds abstract until you need data engineering to prioritize the dim_reservations rebuild and realize you don’t know who sets that roadmap or what they’re measured on.
None of that shows up in a commit history. All of it determines whether your team is solving problems that matter.
You still need to be in the business
Eliminating all hands-on work is both a fantasy and a mistake.
Staying close to the craft on a small slice of work keeps you sharp. You notice the reservation data is landing two days late before a stakeholder escalates it. You feel it when a migration takes four weeks instead of one, which tells you more about your process than any status report will.
The goal isn’t escaping analysis, but you should be deliberate about which analysis you still touch. Usually that’s the ambiguous, high-stakes work where your framing and judgment matter more than the SQL, not the recurring RevPAR variance report you’ve been personally refreshing since 2023 (or that report you took over during the pandemic which you still can’t unload).
Both extremes have a cost
Spend too much time “in the business” and you turn into the bottleneck with every request of any consequence routing through you. The team stays busy, work gets delivered, but if you asked anyone what changed, you’d get a list of dashboards rather than an answer about commercial results. Nothing about that is a crisis, which is part of why it persists. You’re just the data person instead of a thought partner, and the ceiling on what your team gets asked to do stays where it is.
Spend too much time “on the business” and you drift the other way. You’re in the steering committees and the strategy conversations, but your commitments start to outrun what the team can deliver, and the roadmap you framed so well stops matching anything they can ship. That gap shows up slowly… then all at once, usually in a meeting where someone asks for a date and you don’t have one.
The right ratio moves with the business. Enough hands-on work to stay credible and informed, enough system work to change how your team and stakeholders operate over quarters rather than days.
A ratio you can test against
Aiming for one to two days a week “on the business” is a reasonable starting point for a data leader.
Those blocks include executive 1:1s and strategy conversations, budget and headcount planning, operating model design, intake reviews, standing time with IT and data engineering, and story reviews with your senior ICs where you talk about how they framed the problem rather than whether the query was right. The rest of the week runs as hands-on work by default, but you audit that too, looking for the BAU tasks you’re doing personally that could be delegated, templated, or automated.
I’ll admit I’ve protected these blocks less aggressively than I protect deep-work analysis time, which tells you something about what I valued for a long stretch.
Four levers to shift the ratio
Put a lightweight intake system in place that captures the problem, the decision, the owner, the delivery date, and the rough impact. Sort the work into the buckets from the internal leadership issue: urgent and important goes near the top, important but not urgent gets scheduled deliberately, urgent but not important gets challenged, and the rest goes to a backlog nobody will ever work. Teach the team to apply the rules without you.
Define your standards and hold to them. Shared templates for analysis (context, question, method, findings, recommendation, next steps) and approved sources for core metrics so you’re not relitigating the ADR definition every month.
Delegate recurring analysis on purpose. Take the monthly forecast variance deck or the quarterly channel mix review you own, document the judgment calls rather than just the steps, and transfer ownership to a trusted IC. Review the story and the recommendation, not the method.
Book the relationship time. A standing half hour each month with whoever sets the data engineering roadmap and the finance lead who builds your budget, held in their language, about their decisions. That’s where the relationships that lead to sponsorship get built.
A little assignment
Take last week’s calendar and mark each block “on” or “in.” Two colors, fifteen minutes.
Then look for three things:
Where were you doing work someone on your team could own?
Where did you skip system or relationship work you’d claim is important?
What percentage of the week was “on”? If it’s under 20, that’s your answer.
Then pick one recurring analysis to stop doing yourself. Hand it over, coach through the first two or three cycles, and accept some wobble. You’re building a team that ships without you, not a reputation for fixing everything personally.
Block a two-hour slot next week for system design, stakeholder mapping, or budget planning. No tickets, no ad hoc requests. Protect it the way you’d protect your best analysis time.
If you’d like more detail on how to implement some of these systems, check out “Your First 90 Days As A Data Leader” or “90 Day Data Leader Reset” in the Penguin Analytics store.