In every single one of those meetings, I felt like I needed to have all the answers. As the day went on, my answers got less and less specific and more and more confused. When people were asking for a specific number, what I was remembering was a number from a different project. Somewhere in my head, I knew that it was wrong, but I couldn’t for the life of me figure out what the right answer was.

I managed to avoid giving the wrong answer, but I had to punt and follow up after several meetings. That, of course, wasted another hour at the end of the day, trying to follow up on all the things I couldn’t answer during the meetings.

This is the part of leadership people don’t warn you about. You’re expected to know a lot. You’re expected to keep track of dozens of unrelated projects and be ready to answer any question from any senior leader at any time, no matter what the context. Trying to do that is exhausting.

Subscribe now

Nobody told you the standard changed

As an analyst you were rewarded for depth. You had one subject area, you took care of one or two problems at a time, you understood them deeply and you could talk them through with people who wanted to poke holes. The rule most analysts live by is, don’t answer the question unless you’re certain of the answer, and honestly, it’s a good rule. It’s the reason we’re trusted.

There’s a particular promotion, though, that drives your list from four projects to forty. In addition to all of the analysis, you’re now responsible for organizational planning, collaborating with engineering, working with vendors and all sorts of other things you might need to remember at a moment’s notice.

Oh, and you’re also the only person that remembers why we did that thing in 2022 that looks weird, but is, in fact, critical.

Your thinking doesn’t get an upgrade. At least no one mentioned it to my brain. So you apply the analyst rule to a director size list of things. One of two things happens. Either you understand five things properly and you let the rest get completely lost, or you have a shaky understanding of all forty things where you’re never quite sure you’ve got the latest or the full picture.

You think you’re doing the first one, but you’re probably doing the second.

Everything at the same resolution

Most advice for this is about volume. Do less. Say no. Protect the calendar. I’ve written about intake and WIP limits before and I stand by all of it, and if you don’t have a prioritization process yet, go build one, because everything after this gets easier once you do.

You’re still not getting down to five things, though. A director’s list is always long, and cutting it much further means handing back scope you probably want to keep.

What you have to change is how deep you go on each one.

By default, most of us try to understand everything at the same depth. At the director level that’s deep enough to feel responsible, but nowhere near deep enough to be useful. You probably haven’t made a conscious choice to do this, but it’s where you’ll end up. Jack of all trades, master of confusion.

Deep, medium and shallow

Change how you think about depth and put all your projects into one of three buckets.

You go deep on a few important things where you need to really understand the specifics. If someone senior to you asks a question in a meeting, you need to understand the numbers, the trade-offs, the assumptions and the rest of the important stuff. It takes a lot of time and effort to understand things at this level of detail, so you’ve probably only got room for five or six. These should be the ones where your judgment is most important. Good examples are organizational changes, those pieces of analysis where the math is simple but the framing is critical, and those metric definitions that people often misinterpret.

An awful lot of things are going to live at a medium depth. You can explain the status, what happens next and who’s working on it, but beyond a certain level of follow up, you’re not going to be able to go deeper. It’s a complete answer to say “Sarah owns that, we’re waiting on IT for the field mapping, decision expected first week of October.”

It might feel soft while you’re saying it, but it rarely sounds soft to the person hearing it.

Shallow is knowing the thing exists, knowing whose it is, and getting it there. What takes the most discipline is not having a crack at it anyway, even when you probably could.

None of this is a one-time sort, either. Things move. Earlier this year I had a piece of analysis sitting at medium depth. I knew what the status was, but not the details. One of my team went on paternity leave, and all of a sudden the updates fell to me. Guess what I went deep on?

Share

The volunteering problem

One thing will absolutely wreck your deep column. It’s something I do very frequently, and 99% of the time, it’s why I end up working late, over the weekend or stressed out. It’s also well intentioned, and you often justify it by saying it’s “for the best.”

Volunteering.

You’re in a meeting about a project you’re loosely attached to. There’s a gap in the plan. Somebody needs to help build the thing that moves it forward. You have a vision, you’ve shared the vision during the meeting, and nobody picks it up. The silence goes on a little too long. You can see the whole shape of it in your head already, so you say you’ll take it.

You haven’t just bought the deliverable. You’ve also given yourself the opportunity to learn the context, hunt down the data, work out who the audience is, and reverse engineer what decision this thing is supposed to feed. The deliverable is easy. Figuring out what the deliverable should be is always more time-consuming than you think.

I do this more than I should. It’s fast, it’s generous, it makes me feel helpful, and it’s a habit that got rewarded when my list was four projects long and volunteering was how you got noticed. Old instincts are hard to shift.

The trade-off is awful. You’ve moved something from shallow to deep on impulse without really thinking it through. All of a sudden your capacity has to shift, but none of the other projects are going away. Something will give, but you won’t find out what it is until someone inevitably asks a question you struggle to answer.

What works better is naming the gap and naming a person. “This needs someone with the context already. I’d suggest Priya, and I’ll sit down with her to frame the question before she starts.” You’re still solving the problem. You’re just not solving it personally, which is the whole yes-to-the-problem, no-to-the-work thing we’ve talked about before.

Make maintenance proactive

Sorting the list will work for a few weeks.

The deep stuff looks after itself, because you’re in it constantly and the details stay fresh. Shallow doesn’t need anything from you at all.

Medium is the bucket you have to watch. It’s easy to let your understanding go stale. You figured out where things were last month, but they’ve moved on since then, and all of a sudden you’re confidently telling your leaders something that’s no longer correct.

Find somewhere to write down everything in the medium bucket, then find half an hour a month to make sure the statuses are up to date. What is it? What’s the next step? When is it due? Who owns it? Those four columns will give you what you need.

Don’t be like me and tell your boss a project is stuck in a security review when it’s actually stuck somewhere else. It’s a good way to look silly when they go and chase down the wrong person.

Subscribe now

A little assignment

Write down everything you’re carrying. Everything, including the stuff that only exists in your head and has never appeared on a project list. Twenty minutes. It’ll be longer than you think.

Mark each one D, M or S.

Then count the D column. If it’s over six, you’re overcommitted and something in there is going to fall over while you’re looking at something else. Move the two weakest down to M. It’ll feel bad, but do it anyway.

Last thing: look at next week’s calendar and find the meeting where you’re most likely to volunteer for something. Work out now who you’d name instead.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

Penguin Analytics Newsletter Feedback Form

You can also email me at John.Cook@PenguinAnalytics.io or reply to this email. I read everything and respond much slower than you want me to.

Anyway, onto this week’s content!

When I was a young, ambitious analyst, I would regularly corner my boss for a career chat to understand what I needed to work on to advance my career. A couple of years into my career, at one of these chats, I asked when I would get a direct report or a team so that I could learn how to lead. She had a small giggle, and told me that leading has nothing to do with who reports to you. In fact, most times when you lead throughout your career, you’re not leading people who report to you.

This might be truer in analytics than in any other function. You need IT to set up your data and deliver it regularly, but you can’t direct them to do it. You need to influence the business to make the right decisions, but none of the teams report to you. Even at the individual contributor (IC) level, if you’re not a leader, you’ll get nothing done.

If you’re waiting to be given a team before you start to lead, you’re doing it the wrong way around. If you think you have no opportunities, think again.

Subscribe now

Leading is becoming a thought partner for your stakeholders

The easy way to be an analyst is to have a service desk mindset. You get asked a question, you answer it, and you move on to the next thing. If the question might need answering again, you build a dashboard. There’s nothing wrong with it, but it’s not leadership, and it will cap your influence.

The shift is another thing that my old boss used to say – Says easy, does hard.

It starts by realizing that the person bringing you the request hasn’t fully worked out what they want. Before you open a query editor or start playing around with Excel files, your job is to work with them to refine exactly what they’re looking for. What decision is the request supporting? Who is the audience? When do they need it?

Once you understand what they’re looking for, bring a recommendation instead of just the data. Here’s the great thing about bringing a recommendation… it’s never wrong. One of two things happen:

1. They think it through and thank you for saving them time.

2. They don’t like the recommendation and they explain why.

When you hand them something they can act on, they appreciate it, even if they don’t use it. And if they don’t use it, they explain to you why and you learn a little more about their thought process, or their role, or whatever.

I bet you avoid recommendations because “the data speaks for itself” or you “led the horse to water.” Bullshit. The leap of logic (or faith) is never as obvious as you think it is. Spell it out, listen to their response and learn from their feedback. You’ll be better off next time and in the long run.

Leading is influencing people outside your team

The things that stop you from being as impactful as you want to be don’t live within your team. Pipeline reliability, budget, whether anyone adopts what you build, all of it depends on teams you have no authority over: data engineering, IT, product, finance.

I’ve written before about the difference between stakeholders, people who need something from you, and partners, teams you depend on to deliver. This is where that distinction matters most, because you can’t manage a partner relationship the way you manage a stakeholder ask.

Start by understanding what the other team is measured on. An engineering lead who’s judged on reducing technical debt is going to hear your request differently depending on whether you frame it as new work or as debt reduction. A finance partner protecting margin cares about a very different story than the one you’d tell your own VP.

Speak to their incentives directly, and work to be wherever their priorities are decided. Showing up after the roadmap is set and approved means you’re negotiating for scraps. Showing up while it’s still being drafted means you’re shaping it.

Share

Leading is mentoring others

You don’t need to manage someone to develop them. Frankly, some of the best mentoring relationships are with people who have some distance from the work you’re doing.

Some of the best mentors I found in my career weren’t people I reported to. They saw me stumble in a meeting and offered help. They were people I reached out to when I needed a new perspective. They were people who were candid and honest, but not necessarily close.

I tried to do the same thing. When I see someone struggling in a meeting, I’ll check in with them first, and if they’re ready to hear it, I offer some advice. When you have more experience, you have lessons to offer.

I’ve found a few things really work.

Coach the framing and structure of someone’s work rather than rewriting it for them. Helping someone use something like the Pyramid Principle to organize a deck teaches them a skill. Fixing their deck yourself teaches them nothing except to bring it to you next time.

Set standards by example. Document your definitions clearly, build templates other people can use and share them generously, run your intake process the way you’d want everyone to run theirs. People copy what works without being told to.

Run informal post-mortems with peers after a rough project. What broke, what worked, and what you’d do differently next time. None of this requires a manager title, just a willingness to have the conversation.

When I asked my boss about getting a team, I assumed mentoring was something you did only for your direct reports. Looking back, she knew I’d already been doing it for years.

Leading means building trust

The common thread across all of these buckets is trust, and trust behaves like a bank account. You can’t make a withdrawal you haven’t earned, a point I’ve made before and one that applies sideways and upward as well as with stakeholders.

Deposits are things you do well: delivering what you said you would, being honest about what the data can’t tell someone, and calibrating urgency so that a real problem doesn’t get lost in a pile of things you flagged as a crisis.

Save the alarm for the important stuff. People stop listening to whoever cries wolf, no matter how technically correct the wolf sighting was.

Leading a team gives you authority, and authority gives you compliance… Sometimes. Trust earns you buy-in and respect. People welcome your input, listen when you speak, and choose to do what you ask.

Sometimes there’s a need for authority and compliance, but it’s not leadership.

Leadership isn’t something you get handed with a title. The titles go to those who are already leading.

Subscribe now

This week’s assignment

Pick one partner or stakeholder you work with regularly, someone outside your reporting line.

Answer:

• What are they measured on or worried about this quarter?

• When did you last frame a request or a piece of analysis in terms of their goals instead of yours?

• What’s one small thing you could do for them this week, unprompted, that would make a decision (or just their lives in general) easier?

Trust is like retirement savings. Invest early and it compounds.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

It wasn’t sympathy, and it wasn’t permission to complain longer. It was a redirect. The easy version of my problem was solved years ago by someone else. What’s left on my desk is left because it’s not easy.

My team has been working on a project that’s basically analyzing groups of things to determine their effectiveness. On the face of it, it’s an extremely simple ask. Except those groups overlap with other groups. Oh, and add another dimension, and there are other things impacting how both the first and second set of groups behave. Even when you’ve controlled for that, there are sub-groups within the first set of groups that are behaving differently enough it’s messing up anything that might be clean.

“Basically” was doing a lot of heavy lifting in that sentence.

Subscribe now

That’s not a sign we scoped it badly. It’s what the work looks like once you’re past the version of the problem someone described in a single sentence in a meeting. The gap between how complicated a thing sounds when a stakeholder asks for it and how complicated it turns out to be is the painful norm of being an analyst.

Unfortunately, nobody on the other side of that gap cares.

They don’t want a tour of the definition mismatch, the edge cases, the groups that overlap almost entirely, so you can’t find the signal. All of this on the bold assumption the data you pulled in the first place matches what you expected. They want an answer they can act on. They asked “should I do X or Y?” and they want one of those two things back, not a explanation of why the real answer is neither, both, or something you’d have to invent a third option to describe.

Delivering that answer is harder than it sounds, because your instinct is the other way. You did the work, you found the nuance, and some part of you wants credit for it. Complexity makes things INTERESTING, and when we don’t give a binary answer, we can OPTIMIZE.

Even when you explain that, people still don’t care. And even if they did, optimization past a certain point stops paying for itself, because the business can’t execute what you’re recommending.

I’ve handed over recommendations that were both correct and completely unusable. The analysis says this segment responds to one thing and that segment responds to something else, so treat them differently. Sound advice, right up until you find out the system that has to deliver it can only handle one rule. Or the process I recommended that ran to twelve steps and had to be explained to someone, who would explain it to someone else, who would hand it off again to actually execute.

The recommendation that survives the gauntlet of execution is often much blunter than the one your analysis supports. Developing the judgment to get to that blunter version faster, without spending three more weeks refining precision nobody can act on, is worthwhile work. Precision you can’t execute is like a broken pencil - pointless.

Two ways to handle it

Sometimes the right move is to build something simple on a few stated assumptions and move on. You’re not computing the exact number, you’re establishing direction: is this worth pursuing, is it roughly the right size, does it deserve more of anyone’s time? State the assumptions plainly, keep the analysis light, and don’t apologize for it being rough. Rough and fast is the correct tool for a lot of decisions.

Other times, detail is critical. If a decision is hard to walk back, sets a precedent, has regulatory exposure or is something you’ve been burned by before, those details might save your ass. As I’ve written before, trust is built in deposits and lost in withdrawals, and the moment someone catches a detail you skipped, they stop trusting the next number you hand them.

Knowing which one you’re facing before you start is what separates a useful analyst from a busy one.

Share

Simple, but no simpler

I like Einstein’s framing of this problem. Make everything as simple as possible, but no simpler. The choice isn’t depth versus honesty. It’s finding the simplest version of the answer that’s still true and impactful. A number that’s clean but wrong isn’t simple, it’s just wrong.

Two questions can help you decide.

First, is the decision reversible? If being wrong costs an afternoon to fix, build the rough version and move forward. You can always revisit later. If being wrong locks in a commitment nobody can walk back, the extra rigor is worth the time you invest.

Second, when reversibility doesn’t settle it, ask whether the room is deciding if they should do something or how they’re going to do it. If versus how usually ends the argument I’m having with myself. When people are still deciding whether to act at all, an assumption-heavy answer is enough, because the decision might not happen. Once they’ve committed and you’re helping them execute, the details you’d otherwise skip start to matter.

Take a seasonal discount. When we’re deciding IF we should offer it, a quick look at how similar discounts performed, and whether they were incremental (in itself a deceptively hard question), gets us close enough to make the call. When we decide HOW to execute, how deep the discount goes, when it runs, whether there are restrictions, the question gets much harder and needs a deeper answer.

I still catch myself over-explaining things nobody asked about, mostly because I find the caveats more interesting than anyone else does. I suspect people just think I like the sound of my own voice, though.

A little assignment

Take a look at your list of projects and upcoming meetings. Pick one thing you’re currently over-explaining to a stakeholder and run it through the reversibility test. If it’s cheap to undo and you’re still walking people through every caveat, cut it from your next update entirely and see whether anyone notices.

Absorbing the complexity is expensive. The hours in the rabbit hole, the patience to sit with an ugly edge case until it makes sense, the discipline to leave nearly all of it out of the final answer. It costs the person reading your summary nothing, and they’ll never know what you left out.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

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.

Subscribe now

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.

Share

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.

Subscribe now

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.

I used to treat my email like the start of a race. From when it arrived in my inbox, it was like a countdown timer started and I was trying to get an answer out as fast as possible. I was helpful, on top of things. It feels great… but being the fastest person to answer every question is one of the quickest ways to turn yourself and your team into a helpdesk.

A colleague of mine is absolutely great at this. When he gets a question that belongs to someone else – a revenue manager, a property GM, whoever owns that area – he doesn’t answer it. Even when he knows the answer cold and the rightful owner would have to dig it up. He forwards it over, sometimes with a quiet nudge about where to look, and lets them reply. It took me a while to understand why he was working the way he was working. It seemed so slow!

Subscribe now

You become the shortcut

When you answer first and reliably, you teach the whole organization something. Not “the data team is responsive.” They learn that you, personally, are the fastest way to get anything done. So they stop filling in the intake form. They stop emailing the shared mailbox. They email you, because you’re quicker than the process and you never say no.

That feels like a compliment right up until you realize you’re answering questions about things that have nothing to do with you, asked directly to you because you’re the only one who’ll answer. The average knowledge worker already loses more than a quarter of the workweek to email. Layer an unofficial help desk on top of that and you’ve built yourself a second job nobody assigned you and nobody can help you with, because they don’t know it exists.

The demand you’re hiding from your own leadership

This is the part that should bother you as a data leader specifically.

Intake forms, ticket queues, shared mailboxes: those systems are ugly, but they exist to do one thing you should care about deeply. They make demand visible. They turn “everyone’s slammed” into a number you can put in front of a VP when you ask for another team member.

Every question that routes around those systems and lands in your inbox is a data point that never gets recorded. Your official queue looks reasonable. Leadership looks at a calm queue and concludes the team is appropriately staffed, maybe even a little underworked. Meanwhile you’re answering a couple dozen small things a day that no report will ever capture. You, of all people, know what it means when the measurement system is missing half the signal. You’d never accept a RevPAR number that skipped a third of the bookings. Don’t accept it about your own team’s workload either.

Why helpful people fall into this

Did you know there’s a name for the pattern underneath this? It’s sometimes called super-helper syndrome: capable, empathetic people who over-help, absorb problems that aren’t theirs, and struggle to draw a line around what belongs to them. Analytics people are unusually exposed to it. We can see the answer fast, we know just enough about every domain to be dangerous, and almost nobody has ever told us where our job ends. Saying yes feels like you’re doing your job. Saying “that’s not mine to answer” feels like dodging.

For the record, I haven’t fully kicked this habit. I still feel the pull to jump in when I can see the answer and someone’s clearly stuck (or slow). The difference now is that I notice before I act on it. Too frequently I still act on it because self control is difficult.

Share

Why it’s worse for analytics than most jobs

The real work of analytics – building a model, validating a messy dataset, thinking through a strategy – needs long uninterrupted stretches to be any good. Email is the enemy of that. Every random question and every “can you just pull...” is a small interruption, and the cost of an interruption isn’t the two minutes it takes to answer. It’s the twenty minutes it takes to get back to where you were.

So the trade you’re making, every time you fire off a fast reply, is deep work for shallow responsiveness. Do it often enough and your calendar fills with tactical questions you can’t prioritize and can’t tie to any outcome, while the strategic work that would move your team forward never gets your attention.

Answer through the owner

Back to my colleague. What he’s doing isn’t refusing to help. He’s helping in a way that strengthens the system instead of routing around it.

The mechanics are simple. A question comes in that belongs to someone else. He sends the owner the context or the answer directly, off to the side, then lets the owner respond to the asker. Three things happen at once. The asker learns the correct path for next time, the owner builds credibility and a relationship instead of looking slow, and the question ends up in the right queue, where it gets managed properly.

He still uses his expertise. He just points it at the system rather than at his own inbox.

Subscribe now

A little assignment

For one week, stop being the first to answer.

Pick your non-urgent threads, the ones where someone’s emailed you directly about something that isn’t really yours. Before you reply, ask two questions: who owns this, and what’s the official channel for it? Then route it there. Feed the owner what they need behind the scenes if you have to, and let them take the reply.

Track what you notice. How many of those questions were genuinely yours to answer? How many were people using you as a shortcut around a process that exists for a reason? At the end of the week, does your calendar feel any different?

The data leaders who get pulled into strategy have usually done the unglamorous work of making ownership and demand visible, so most questions find the right owner before they ever reach an inbox.

If you want help building the intake and routing systems to make this change stick, the guides and playbooks over at Penguin Analytics are built to do exactly that.

It’s like giving your strongest muscles a bigger lever. I love it. I’m also digressing.

The first few months as a new manager are rough. You’re not an analyst anymore, but you don’t feel like a manager yet either. You’re doing both, and not doing either especially well.

I remember being there. I kept the IC work I’d always done, added the manager work on top, and convinced myself I was being heroic. I didn’t delegate because I wanted to be “nice” and not overwork anyone, while I spent hours after the end of the day doing the work I should have delegated.

This pattern shows up in almost every new manager I’ve worked with. It’s not a personal failing. It’s a predictable consequence of how analytics teams get built and how analytics promotions happen. It’s also totally normal, but the faster a new manager can move beyond it, the sooner they can start growing as a manager instead of a super-IC.

Why you get stuck

The org keeps routing work to you because you’re the person who got it done before. Your stakeholders have built up years of trust in you specifically, not in your team. When something urgent shows up, the easiest thing is for you to handle it. You’re faster, you know the context, and the request lands in your inbox anyway.

That’s the structural side. The identity side is harder.

Your reputation, your confidence, your sense of being good at your job, all of it got built doing the work. Not managing the work. Shipping the dashboard, finding the insight, being the person the executive emails when they need something. Letting go of that doesn’t feel like growth. It feels like giving up the thing that made you valuable.

IC work is also easier to measure than management work. You sent the analysis or you didn’t. You hit the deadline or you didn’t. Management work is fuzzier. You can’t tell at the end of a week whether your coaching landed, or whether the team’s work is better because you were involved. You can’t measure it, so you drift back to the work you can.

Subscribe now

The most common pattern

Here’s the version I see most often. The new manager has priority work landing on her plate. She’s always been the person who reliably delivers, and that reliability is what got her promoted. When the urgent thing shows up, she does what she’s always done. She puts her head down, grinds it out and ships it.

Meanwhile, her team has capacity. They want real work. They’re watching her grind through her ticket queue wondering why she isn’t handing them more.

She thinks she’s protecting them. She’s keeping the hard stuff on her plate so they don’t get crushed. She’s protecting the stakeholders too, by making sure the work gets done right. It feels generous. It feels like good leadership.

That’s the story she tells herself. The real picture is a manager doing IC work while her team waits for permission to do their actual jobs.

I’m not saying any of this from a height. I’ve done it. I still catch myself doing it. The instinct to protect the team by absorbing the hard work is hard to spot because it feels generous when you’re doing it.

What it costs

The visible cost is that you’re working too many hours. That one’s obvious, and people will tell you about it.

The hidden costs are worse. You don’t have time for the work nobody else can do for you: setting direction, talking to senior stakeholders, coaching your team through analyses so they get better. That work isn’t urgent on any given Tuesday, so it gets crowded out by what is.

You also train your stakeholders to keep coming to you directly. Every time you take a request yourself instead of routing it through your team, you reinforce that you’re the person who does the work. Two years in, you’ve got a team your stakeholders don’t trust with anything important, and that’s on you.

Your team learns to wait. They don’t build judgment because they’re not making the calls. They become executors of whatever you hand them, not problem-solvers. When you eventually try to hand off something important, they haven’t done it before, which makes you take it back, which confirms your suspicion they couldn’t have done it anyway. And the pattern repeats.

I have a colleague who is great at this. He refuses to answer questions or email folks back when he’s not the right person. It sounds mean, but it reinforces the correct routing, keeps ownership of the relationship with his team and means they know the answer next time.

Rebalancing without the guilt

The shift isn’t from IC to manager in some clean swap. You’ll still do IC work. You should still do IC work, partly to stay credible and partly because some things are better in your hands. The shift is in the ratio.

A reasonable target early on is something like 70% manager work, 30% IC work, adjusted for the size of your team. The exact split matters less than the direction. If your calendar looks the same as it did before the promotion, something’s off.

Delegation isn’t dumping work you don’t want to do. It’s giving your team the problems they were hired to solve. They didn’t sign up to be your assistants. They signed up to do analysis and build things and have impact, same as you did.

Share

A few things that help

Do a weekly inventory of what’s on your plate. Mark each item as IC work or leadership work. Look at the ratio. If IC is winning by a lot, pick two items and move them to someone on your team this week.

Build templates and shared standards so handing off doesn’t mean every analysis comes back looking wildly different. This is what lets you stop rewriting other people’s decks. If “good” is defined, more people can produce it.

When someone on your team ships something, resist the urge to fix the output. Review how they framed the problem and how they told the story instead. Give them one piece of feedback they can use next time, and let them ship the imperfect version. The work gets better through iteration with feedback, not through you rewriting it yourself.

Subscribe now

A little assignment

Pick one project this month that genuinely matters and hand it to someone on your team end to end. Not a piece of it. The whole thing.

You’re the coach. You’re in the meetings as backup, not to take over when it gets uncomfortable. You review their framing, ask the questions that help them see what they’re missing, and let them present it themselves.

It will feel terrible. You’ll want to step in. You’ll be sure they’re going to miss something you would have caught. Sometimes they will. Most of the time they won’t, and you’ll learn the team is more capable than you’ve been treating them.

Feeling stuck between worlds isn’t evidence you’re bad at this. It’s evidence you’re mid-transition, which is where you’re supposed to be. The way out is on the manager side, not back where you came from.

If you’re going through this transition yourself, or coaching someone through it, I wrote a longer guide called Your First 90 Days As A Data Leader. It goes deeper on rebalancing your work, delegating without the guilt, and the first few systems you want to put in place.

The stakeholder was fairly data savvy, so I shared it back to him and asked a few questions about what to do next. What followed was a two-week game of whack-a-mole. Could we exclude these years? Could we look at just the top-performing properties? What if we changed the baseline? Could we trim the outliers more aggressively?

Every request was reasonable in isolation. Taken together, they were a series of nudges to make the data say what they’d already decided.

I should have stopped it earlier. I didn’t, because I was new and didn’t want to push back. Eventually, of course, the data supported their point of view. Torture data hard enough and it will tell you anything.

That experience taught me, in a more practical form than I’d ever read it, what the shift from analyst, who takes orders and answers questions, to advisor, who is a partner and makes recommendations, actually requires. One of the single best questions to uncover whether someone is genuinely asking for help or has already made up their mind is asking them:

What would change your mind on this?

If the answer is “nothing,” I’m not being asked to do analysis. I’m being asked to provide cover.

Subscribe now

The hidden contract

Most analyst-stakeholder relationships pretend the request is for truth. The real contract is often something else: protect me from blame, justify a decision I’ve already made, help me look defensible when this gets questioned, or buy me time while I figure out what I actually want to do.

None of those are bad things to need. Stakeholders are human, they’re under pressure, and sometimes they really do need a defensible artifact more than they need a new insight. The problem is when nobody names what the work is for. The analyst thinks they’re doing science. The stakeholder thinks they’re getting backup. Both walk away frustrated when the output doesn’t match the unstated need.

“What would change your mind?” forces that unstated need into the open. There’s no pushback in it and no skepticism. You’re asking the stakeholder to imagine a world where the evidence pointed the other way. Their answer tells you.

Why analysts get stuck here

Analysts are trained to answer the question they’re asked. Accurately, on time, with good documentation. Those are good instincts. They’re the same instincts that make us terrible at recognizing when the question itself is the problem.

Advisors do something harder. They check whether the question is the real one before committing the team’s time to it. That’s uncomfortable because it slows things down, and because it occasionally means telling someone senior that you don’t want to do the work they asked for until you understand it better. I find this hard, and most of the analysts I’ve coached find it hard too.

The three questions to ask first

Before you open the data, before you scope the project, before you commit your team to anything, ask three things:

- What decision are you trying to make?

- What would need to be true for you to choose the opposite?

- What are you worried happens if this goes wrong?

The first one is standard. If you’ve read any of my writing on intake processes, you should already be asking it.

The second creates a lot of value. If the stakeholder can describe a condition that would flip their recommendation, you have a real analysis to do. You know what to test, where the threshold is, and how to size the risk.

The third question points to the consequences. The honest answer is rarely about the data. It’s usually about something else: a promise made to leadership, a budget already half-committed, a competing team’s project that has to lose for theirs to win, or a personal reputation tied to the outcome. That fear shapes everything about how they’ll respond to your work, and you can’t help them if you don’t know what it is.

Subscribe now

When the honest answer is “nothing”

Sometimes you’ll ask, and the answer will be a polite version of “nothing would change my mind, I just need this on a slide.”

Don’t pretend that’s a research project. Call it what it is: a communication artifact, a risk-reduction exercise, a piece of internal positioning. Then decide whether it’s worth your team’s time, and what level of effort it deserves. A two-hour deck pull is fine. A three-week deep dive with statistical testing is not.

The worst outcome is doing the deep dive anyway, finding inconvenient evidence, and getting pulled into the whack-a-mole game I described above. You spend weeks defending findings nobody wanted, the stakeholder gets frustrated, and eventually you end up putting something together that looks like what they wanted.

When the honest answer is real

A commercial leader once came to me wanting a deep dive on ADR strategy for a set of properties. The framing was “I need to understand the pricing dynamics.” When I asked what would change her mind, she gave a good answer about elasticity thresholds. When I asked the third question, the real picture came out: she’d committed to a number in front of ownership and was worried she wouldn’t hit it without the pricing move she was already planning.

That changed the work entirely. We didn’t need a sprawling pricing study. We needed a tight piece showing the gap between her committed number and the realistic forecast, the contribution she could expect from the pricing move, and what else would have to be true to close the rest of the gap. Two analysts, one week, one decision-shaped artifact. She used it in the conversation with ownership the following Monday.

That’s the form analysis takes when it’s actually advising a decision. You’re not producing “the analysis on X.” You’re producing a clear test: here’s the threshold, here’s what the evidence shows relative to it, here’s the recommendation, here’s what would move it the other way. It’s also dramatically faster to produce than the open-ended version, because you know what’s in scope and what isn’t.

The contrarian take

Most leadership advice says analysts should be “more consultative.” That’s too soft.

The stronger version is that a meaningful number of stakeholder requests should be refused, reframed, or narrowed before anyone touches the data. Not because the stakeholders are wrong to ask, but because the request as posed isn’t analysis. It’s something else dressed up as analysis, and pretending otherwise wastes everyone’s time and erodes the team’s credibility when the output predictably fails to match what was needed.

The harder version of the ADR example above is the one where I push back, the leader insists on the broad pricing study anyway, and I do it knowing it won’t change anything. That’s the move to refuse. Declining to participate in fake uncertainty is one of the highest-leverage things a data leader can do. It’s also one of the hardest, because it requires being willing to slow a stakeholder down at the moment they most want speed.

Share

A little assignment

Pick one analyst on your team and a request they’re currently working on. Sit with them and ask the three questions of the stakeholder together, or coach the analyst to ask them on their own and report back:

- What decision is this for?

- What would change your mind?

- What are you worried about if it goes wrong?

Pay attention to the third answer. If it surprises you, the scope of the work probably needs to change. If it doesn’t come up at all, ask again in a different way, because it’s almost always there.

The shift from analyst to advisor doesn’t happen by accident, and it doesn’t happen by working harder on the wrong question. It happens one request at a time, by asking what the work is actually for before the work begins.

Some of what I write about here I’ve turned into playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

Their immediate response at the end of the conversation was “Okay, I’ll get started on the dashboard.”

Wait what?

We didn’t need a dashboard. We needed an email. Maybe a few slides if we wanted to be fancy. The answer was clear, it wasn’t going to change, and the audience was a handful of people who needed to make one decision. A dashboard would have taken a week to build, required ongoing maintenance, and buried a simple answer inside filters and tabs that nobody asked for.

I hate dashboards. Not in the way someone who has never built one hates them. I like to think I hate them in a much more sophisticated way. The way you hate something that keeps getting requested even after it has clearly failed to solve the problem it was supposed to solve.

Analysts default to dashboards the same way my dog defaults to stealing socks. No matter how many times I tell her not to go digging in the laundry basket, and there’s a better toy in her bed, she sneaks at least one sock per load.

And yes, I track socks stolen per laundry load as ax mischief KPI.

Dashboards have become the default deliverable for analytics teams. They feel tangible, they look like a product, and they let everyone say something got “delivered” and “automated.” When the default answer to every question is “build a dashboard,” you stop asking whether it’s the right format.

Subscribe now

What we think we’re doing

When someone asks for a dashboard, they usually think they want clarity. What they actually want is confidence. They want to know whether something changed, whether it matters, and what they should do next. They do not want to spend twenty minutes clicking filters, comparing tabs, and trying to reverse-engineer the analyst’s mental model. They definitely do not want to feel like they need a second dashboard just to understand the first one, but eventually they’ll ask for one.

In fact, that’s why most dashboards are awful. They get built the way the analyst thinks, not the way the user thinks. Analysts like structure, logic, completeness and flexibility. Users like speed, relevance, and a path to action. So we hand over a beautiful tool that makes perfect sense to us and then act surprised when the business starts exporting everything into Excel so they can “analyze it their way.”

We joke about the export behavior, but it should be a clue. It says the dashboard doesn’t match the user’s workflow. If the user has to leave your dashboard to think clearly, the dashboard is just Excel with a nicer interface.

The dashboard fantasy

The fantasy goes like this: build one dashboard, and everyone will see the same truth, make better decisions, and stop bothering you.

That fantasy is adorable.

In practice, dashboards create new work. Someone has to maintain them, explain them, defend them, update the definitions, handle the edge cases, and answer the inevitable “can you add one more filter?” request that is allegedly simple and is never simple. Updating filters, tweaking definitions and adjusting views feels productive, but it’s busywork and it’s rarely moving the organization forward.

Share

Where dashboards are useful

I should be fair. Dashboards do have a job, and I’ve built plenty of good ones over the years (probably fewer than I think, but still).

They’re good when the question is broad, the audience is mixed, and the goal is shared visibility. They work for stable monitoring, common language, or spotting exceptions. “Useful” is not the same as “best,” though. Too many analytics teams treat dashboards as the universal container for value. They’re one format among many, and often not the format that gets a person from problem to decision fastest.

When you have users that genuinely need to explore data, or have recurring questions they need to answer each month, a dashboard can be a great help. Regular usage helps reinforce understanding, and it does actually streamline their workflow.

We just assume that usage pattern exists a lot more frequently than it does.

The part people skip

Dashboards are often built for the convenience of the analyst or the organization, not the cognitive habits of the person using them. We build them because they’re scalable, because they’re countable, because they feel like a product, and because they let us say we “delivered” something. A dashboard can contain every metric you asked for and still force the user to do the part of the job that analytics was supposed to do. It can say “here’s the data” while avoiding the harder and more important sentence: “here’s what it means and what to do about it.”

That avoidance is a real issue. Dashboards often become a polite way to stay in observation mode when the business actually needs judgment. They create the feeling of progress without the social risk of a recommendation someone doesn’t like. Everyone feels informed and the analytics team doesn’t have to be “responsible.”

Subscribe now

How to move beyond dashboards

A better question than “can we build a dashboard?” is “what decision is this for?”

That question forces the request into a shape where you can ask about timing, owner, action, and consequence. It also makes it obvious when a dashboard is overkill, underpowered, or simply the wrong format.

If the answer is a recurring check-in, maybe you DO need a dashboard. If the answer is a decision with a deadline, you probably need something tighter. You could provide:

• An email with a recommendation.

• A one-page readout before tomorrow’s meeting.

• A chat message with two numbers and a suggestion.

• A weekly memo that tells people what changed, what it means, and whether they need to do anything.

• A five-minute standing agenda item with two slides.

• A triggered alert that fires when something crosses a threshold.

• A pre-read doc that frames the tradeoffs so the meeting can skip straight to the decision.

The options are endless once you stop treating the dashboard as the only container for value.

Share

A little assignment

Next time someone on your team (or you) starts a project and the first instinct is “I’ll build a dashboard,” pause and ask three questions. What decision does this support? Who needs to act on it, and how quickly? What’s the simplest format that gets them from data to action?

If the answers point to a dashboard, build the dashboard. If they point to an email, a weekly readout, or a five-minute conversation with two slides, do that instead.

The goal of analytics work is not to build things. It’s to change decisions on time. Dashboards are fine when they support that. They’re a problem when they become the goal.

Familiarity is how a lot of mediocre analytics gets dressed up as progress.

Some of what I write about here I’ve turned into more robust guides and playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

I went into the first meeting with a list of the things my team had done and was working on and rattled it off while he listened politely. When I’d finished my long list of what we had done over the last few months, he asked a very simple question… “What are we doing differently?”

I – ever ready with an answer – went back through the list again, talking about the data we were sharing, who it was going to and… He gently stopped me and explained he was really asking how the work we were doing was impacting the business.

I was telling a story with deliverables I should have been telling with outcomes.

The last two weeks covered Phase 1 of a data leader reset (understanding what’s happening, getting backing) and Phase 2 (building decision products, retiring the graveyard). Phase 3 helps you tell the story of the impact you’re having and build a sustainable system so you don’t slip in the future.

This is the third of three posts summarizing a longer guide in the Penguin Analytics store.

Here’s Phase 3.

Subscribe now

Build the impact story while you can still remember it

Most data leaders – including me – find “show me the value” uncomfortable. You’ve been asked before, and the answer has always felt thin or inflated. The reset gives you something more honest.

You’re not calculating a precise ROI. You’re building a credible narrative around three kinds of evidence.

The first is usage. For each decision product, track who looks at it, when, and how often. Are the decision-makers checking it before the meeting it supports? Is usage clustered around the decision cadence or scattered randomly? Usage that lines up with decision timing is strong evidence that the product is being used for its intended purpose.

The second is process. What changed in how the team spends its time. How many dashboards retired. How many duplicate metrics consolidated. How much manual reporting was eliminated. These are tangible numbers, and they hold up to questions in a way that “data-driven culture” claims don’t.

The third is narratives reinforcing how it’s used for decisions. Three to five concrete stories where analytics influenced a real call. Not “we built a dashboard.” Something more like “the pricing team used the segment margin view to tighten Mid-Market discount bands in Q3, with projected margin recovery of two hundred thousand dollars.” The story doesn’t need to be precise to the dollar. It needs to be specific enough that the stakeholder would nod and confirm it happened.

Package these into a short update for your manager and, where appropriate, for stakeholders and leaders. A one-page summary or a couple of slides with a few bullets and a few stories is usually enough.

Also be honest about what you haven’t solved. A credible impact story presents the wins, identifies the gaps and a plan for fixing them. A leader who only reports good news is a leader nobody trusts.

Turn the soft filter into a real system

The soft filter you ran in Phase 1 worked as a temporary measure. Now you need to expand that into something durable.

Once a week, review new requests with the team. Classify each as decision-linked, informational, or noise. Decision-linked work gets scoped and scheduled. Informational requests get a lighter touch or a redirect to self-serve. Noise gets a clear no with a reason.

Give your team the language to handle the common cases without escalating to you. “We can support that, here’s what we need to scope it.” “That’s available in self-serve, here’s who can walk you through it.” “That doesn’t fit our current priorities, bring it back when it’s tied to a decision.”

When you defer or decline, write it down. A simple log of “we chose not to do X because Y” protects you when someone later claims they weren’t heard. It also creates a visible record that your team makes deliberate choices, rather than being overwhelmed.

The intake system needs to be simple enough that your team runs it without you and doesn’t skip steps. If every decision requires your personal judgment, you’ve built a bottleneck. If every request requires an hour meeting to scope it and 1,001 intake questions, you’ve built a different kind of bottleneck.

Share

Teach your team the new model

The reset only sticks if your analysts internalize it. You need them to think decisions before dashboards every time a new request shows up.

Reinforce the intake question in your 1:1s. The first few times feel awkward. After that it becomes habit. Review framing in your work reviews, not just SQL. A technically perfect analysis with no decision framing is half-finished work.

For each decision product, name an analyst who owns it end-to-end. The relationship with the decision-maker, the data quality, the delivery, the iteration. Ownership means they present it, defend it, and improve it. It also means they get the credit when it works.

Celebrate the right things in front of the team. When someone’s work changes a decision, make that visible in team meetings, in your update to your manager, in Slack. When someone launches a new dashboard, ask what decision it serves. The signal you send about what counts as success will shape behavior faster than any process document.

Teach the organization too

Your stakeholders also need to learn the new model. Some will adapt quickly. Others will keep sending “can you just build me a dashboard?” requests for months.

Run short enablement conversations with your key stakeholders. Cover what changed, how to request support, and what to expect. The goal is to make expectations clear enough that the common interactions go smoothly without you stepping in.

Some stakeholders won’t get it until they see a concrete example. The decisions you supported in Phase 2 give you those examples. When you can say “for the pricing meeting, we used to do X, now we do Y, and the team spends less time looking at dashboards and more time talking about trade-offs,” you’re making the change real.

What should feel different by Day 90

If the reset has worked, a few things are noticeably different:

• You spend less time in meetings answering questions about numbers and more time talking about the business.

• Your team talks about decisions and outcomes more than dashboards and tickets.

• Stakeholders bring you into conversations earlier, when decisions are still forming, instead of at the end when they need a chart.

• Your dashboard surface is smaller but more used. The things you maintain are the things that matter.

• You can explain what analytics delivered this quarter in three sentences that a non-technical executive would understand and believe.

You still have open problems. Some stakeholders will still default to “just build me a dashboard.” Some analysts will need more time to internalize the new model. The self-serve layer probably still needs work. That’s expected. The measure of the reset is not whether everything is fixed, but whether the team, the stakeholders, and the system you’ve built are pointed in a better direction and moving under their own power.

Subscribe now

A little assignment

Write a three-sentence answer to the question “what has analytics delivered this quarter?”

Not what it produced. What it delivered. Decisions changed, outcomes shifted, processes improved.

If you can’t get to three sentences, you don’t have an impact story yet. That’s useful information. It tells you what to spend the next thirty days building.

If you can, save it. That’s the foundation of how you talk about your team’s work for the next year.

This concludes the three-part series on running a 90-day reset for a data team. The full guide includes worked impact-summary examples, sample language for the harder conversations, and four scenario walkthroughs from real resets. Available in the Penguin Analytics store.

I’m sure you can see where this is going.

The dashboard was retired eighteen months later without any fanfare because no one noticed.

The problem wasn’t the dashboard, it was that it delivered the right information – that’s why everyone was asking for it – but at the wrong time, in the wrong place and in the wrong format.

Last week we covered Phase 1 of a data team reset: understanding the system, sorting the work, getting your manager’s backing. Phase 1 removes the wrong work. Phase 2 is where you pivot towards the right work.

This is the second of three posts summarizing a longer guide in the Penguin Analytics store.

Subscribe now

Pick the decisions worth getting good at

In your mind, you already know which business decisions carry weight. From Phase 1 and from your time in the role. Now you need to name them.

You’re looking for decisions where:

• The outcome has a clear dollar value, whether that’s revenue, cost, risk reduction, or resource allocation.

• The decision happens on a predictable cadence: weekly, monthly, quarterly.

• A real owner exists who is willing to partner with you on improving how the decision gets made.

• Better information would change the outcome, not just confirm what people already believe.

Common examples: pricing reviews, capacity planning, marketing spend allocation, churn intervention targeting. Your list will be specific to your business.

Pick three to five. The temptation is to choose seven or eight because they all feel important but resist it. Depth on three is worth more than surface coverage of eight. Depth means your team understands the decision context, knows the decision-maker personally, and can describe what a good outcome looks like before they pull any data.

One easy trap you need to avoid: don’t pick decisions based on what’s analytically interesting. The most stimulating analysis isn’t always the most valuable. A simple view that changes a pricing call every month is worth more than a sophisticated model that nobody owns.

Build decision products, not dashboards

For each decision you pick, your team is going to build a decision product. The name matters because the framing matters.

A dashboard is a collection of charts and filters that a user can explore. A decision product is the thing that lands in front of the decision-maker at the right moment, in the right format, with a clear recommendation. A dashboard says “here is some data.” A decision product says “here is what you need to know to make this call, and here is what we recommend.”

You know, like my fancy dashboard didn’t.

For each one, define:

• The decision owner.

• The decision cadence.

• Three to five key metrics.

• The narrative structure the data needs to tell.

• The delivery channel.

• Who on your team owns the product end-to-end.

The format should follow the decision-maker’s workflow, not your BI tool. It might be a slide in a recurring meeting deck. It might be an email summary that arrives Monday afternoon before Tuesday’s review. It might be embedded in the tool where the decision-maker already works. What matters is that it helps them make the call.

Co-design or you’ll rebuild your graveyard

The fastest way to recreate the dashboard graveyard is to design decision products based on what you think stakeholders need rather than what they tell you.

For each product, run a short co-design session. Thirty minutes with the decision-maker and one or two of their direct reports is enough. Walk through how the decision happens today, what information is missing, what format works for them, and what would make them stop using whatever you build.

That last question is the most important one, and the one analysts skip most often. Previous analytics tools died in their workflow for a reason. Find out why.

Prototype lightly. Wireframes, a rough slide, a simple query. Review within days, not weeks. Every week you spend building in isolation is a week where assumptions harden and misalignment grows. The co-design process itself builds trust because it shows stakeholders you’re building with them, not for them.

Share

Retire the graveyard with purpose

With your critical decisions identified and decision products in motion, you have the context to start retiring unused content.

This is the scariest part of the reset, because you’re taking things away from people, and people get attached to things even when they aren’t using them.

Handle it in stages. For dashboards that haven’t been accessed in more than 90 days, send a short notification to the last known users. “This dashboard hasn’t been accessed in X days. We’re archiving it on Y. If you still need it, reply and we’ll keep it active.” Most won’t reply. The ones who do will tell you something useful about whether the dashboard matters.

For duplicates, consolidate into the single source of truth your decision products will use. Frame it as a benefit. Everyone working from the same number is a win, even for the people losing their preferred version.

For dashboards with a real audience that are being replaced by a decision product, explain the transition. Don’t archive silently. People feel ownership of work even when they don’t use it, and quiet retirement reads as a trust violation.

Watch where your team is spending their time

As decision products take shape and the graveyard shrinks, your team’s time allocation should start to shift. More decision-linked work, less undifferentiated maintenance and ad-hoc fire drills.

Track it. A rough weekly estimate from each analyst is enough. How much of the week went to decision products, how much to ad-hoc, how much to maintenance. You’re looking for a trend, not for precision.

Use your 1:1s to reinforce the shift. Ask what decision the work supports. Ask whether anything on their plate isn’t tied to a decision and whether it should be. You’re training the team to think in decisions and outcomes, not deliverables, tickets and enhancements.

If you’re not seeing movement after three or four weeks, the answer is usually one of two things. Either the intake filter isn’t as good as you intended and ad-hoc requests are coming in unchecked, or you haven’t retired enough to free the capacity. Both are fixable, but you just need to know which one.

Subscribe now

A little assignment

Pick one decision. Just one. Something that recurs on a predictable cadence and has a named owner you could talk to this week.

Write down, in fewer than a hundred words, what your team would deliver to support that decision if you started from scratch. What’s the format. When does it land. Who reviews it before it goes out. What recommendation or framing does it include.

Compare that to what your team currently delivers against the same decision. The gap is your Phase 2 work.

This is the second of three posts on running a 90-day reset for a data team. The full guide, with the decision-product brief template, the retirement playbook, and stakeholder language for the harder conversations, is available in the Penguin Analytics store.

“What does this get used for?”

He sort of stumbled around for an answer before circling back to who had asked for it, the history of why we were updating it, and why no one else could do it. All true, and it answered “why” we did it, but without really explaining why it was important to our stakeholders.

I didn’t realize it at the time, but that conversation was the start of my first reset. At the time, I didn’t think I was doing anything particularly dramatic, but it was the first iteration of a framework I’ve used a few times since. It was a trigger that made me sit back and think we’re doing a lot… But does anyone notice?

If you’ve been in your role for a year or two and you’re starting to feel reactive in a way you didn’t use to, consider your own reset.

Subscribe now

Over the next three weeks, I’m going to walk through each phase of a 90-day framework for moving your team from reactive reporting people love but don’t look at to decision products that drive decisions. This is a condensed version of a longer guide in the Penguin Analytics store.

Here’s the first phase.

Get the picture you’ve been avoiding

You suspect a lot of your dashboards go unused. That suspicion is probably well founded - it was for me - but it isn’t evidence. Before you can have a real conversation with your manager about changing how the team operates, you need numbers.

Pull a list of every dashboard, scheduled report, and self-serve artifact in your BI tools. For each one, capture the basics: name, owner, audience, topic, and last-accessed date. Sort them into three rough tiers based on usage. Active means the intended audience is using it regularly. Stale means a handful of people still check it, but not consistently enough to call it part of a workflow. Dead means it’s been 90 days or more, or close enough that nobody would notice if it disappeared.

You don’t need a perfect census. Most teams that run this for the first time find half to two-thirds of their dashboards fall into stale or dead. That number stings. It’s also the single most useful piece of evidence you’ll generate in this whole process, because it converts a vague feeling into hard data.

Spend a few focused hours, not a few weeks. The point is to have something honest enough to anchor a conversation.

Sort the work into three buckets

Once you have the census, classify your team’s current effort into three categories.

The first bucket is critical decisions. Work that directly supports a recurring decision with real economic impact. Pricing reviews, capacity planning, churn mitigation, board reporting. The dashboards and analyses where, if they broke, someone would notice the very next cycle.

The second bucket is nice to see. General visibility that isn’t tied to a specific decision or cadence. Operational views, exploratory analyses, self-serve tools with a handful of casual users. Useful background that sometimes uncovers opportunities, but nobody is choosing differently because of it.

The third bucket is noise. One-off reports that were never retired, dashboards built for a launch and forgotten, ad-hoc requests that became permanent artifacts. This is the graveyard.

The line between bucket one and bucket two is where the hard thinking happens. A dashboard can be well-built and well-liked without being tied to a decision. Remember, popularity isn’t impact.

Create space and stop the bleeding

Now you have a picture, it’s tempting to dive in and start cutting dashboards, but you’re not ready to retire anything yet. What you can do is stop adding more to the pile.

Introduce a soft intake filter. When someone asks for new work, ask three questions:

• What decision is this for?

• When does that decision need to happen?

• Who owns it?

If the requester can’t answer the first one, the request goes to a parking lot rather than into the team’s backlog.

You don’t need to make this a policy announcement. It’s a one-conversation-at-a-time shift in how requests get scoped and accepted. Most stakeholders, when asked what decision their request supports, will either give you a real answer or quietly let the request go. Both outcomes are wins.

One conversation that makes the rest possible

Everything above is preparation for one meeting. You need your manager’s explicit backing before you start retiring anything or saying no to anyone senior.

Book sixty to ninety minutes and walk them through:

• What you found in your census.

• What you want to change.

• What you need from them.

Frame the problem in their language. If they care about ROI, show them how much team capacity is consumed by work disconnected from decisions. If they care about executive trust, show them the usage data alongside the dashboards leadership keeps requesting.

Then ask, specifically, for three things:

• Backing when you start saying no to low-value requests,

• Help identifying which decisions matter most to leadership,

• Ninety days before anyone judges whether this is working.

If your manager won’t back the reset, you have a different problem than the one this guide solves. You may need to run a smaller pilot, prove the value on a single decision, and come back with evidence. That’s slower, but it’s still a path.

A little assignment

This week, pull the usage data for your ten most prominent dashboards. Not all of them. Just the ten you’d name if a peer asked what your team produces.

For each one, write down the last-accessed date and the decision it supports. Be specific. “Operational visibility” doesn’t count. “The Tuesday pricing review chaired by Sarah” does.

Look at the list. How many of the ten have a decision name next to them? How many of those decisions actually happen on the cadence you assumed?

Whatever the answer is, that’s where the reset starts.

This is the first of three posts on running a 90-day reset for a team that’s drifted into reactive mode. The full guide, with the census template, sample language for the harder conversations, and worked examples from real reset scenarios, is available in the Penguin Analytics store.

Subscribe now

I always get a few comments from folks who read it as a little too black and white. In this case, they thought I was saying “technical skill doesn’t matter anymore.” That’s not what I said, and it isn’t what I think.

A candidate with zero technical background is, in my experience, a bad hire for a data team. Not “a stretch” or “a risk worth taking.” A bad hire. Even if they say they want to learn. The floor is rising, but there is still a floor.

Subscribe now

What the technical floor looks like

You don’t have to be able to write a window function from memory, but I always ask myself… has this person, at some point in their life, sat down and tried to make a computer do something it wasn’t doing before?

It doesn’t have to be SQL. It doesn’t have to be Python. It can be a hobby project in a language we don’t use, a half-finished side thing in R, a Power Query mess they built to automate their old job, a personal website they coded badly. The specific stack is mostly irrelevant. The fact that they did it is the indicator I’m looking for.

If someone has done this, even at a small scale, it means a few things:

• They know what it feels like to be stuck on a technical problem for hours and finally solve it.

• They understand that “it’s just a small change” is almost never a small change.

• They have empathy for the engineers and analysts they’re going to work with, because they’ve been in the same headspace.

• They can read a piece of code or a model and at least get the shape of what it’s doing, even if they can’t write it themselves.

You can teach someone the specifics of your stack. You can’t easily teach the underlying disposition that comes from having struggled through a technical problem on your own time.

Why self-taught is my favorite

The candidates who learned something technical on their own, without it being a job requirement or part of a course, are doing something I particularly like.

They’re not going to hate it when we ask them to learn. Most analytics roles require continuous technical learning. New tools, new data sources, new methods. If someone has voluntarily taught themselves a language, they’ve already proven they can sit in that discomfort and come out the other side. Someone who has never done it is an unknown quantity, and the unknown usually breaks in the wrong direction.

It shows tenacity and creativity. Teaching yourself a programming language is hard. The first ten hours are mostly confusion. Anyone who has pushed past that has demonstrated a kind of stubbornness that’s genuinely useful in analytics, where the data is messy, the questions are vague, and the answers don’t usually fall out cleanly.

It demonstrates curiosity, especially if it wasn’t required. There’s a difference between someone who learned Python because their manager told them to and someone who learned Python because they got curious about something. The second person’s instinct is to go deeper instead of waiting for instructions.

The resources are everywhere, and this is the part that makes me less sympathetic to candidates without any technical background. Free tutorials, free courses, free AI tutors that will explain a concept ten different ways. The barrier to getting started has never been lower. You can want a career in data without wanting to get all messy in the technical details, but at a certain stage you’re going to have to.

Share

And not taking advice is my least favorite

I’ll meet with people in my network who are trying to move into data. We have a good conversation. I tell them, clearly and directly, what would make them a stronger candidate. Usually some version of “go learn the basics of SQL, or Python, or pick a tool and build something with it. Come back when you have.”

Some of them do it. Those people get my time again, often my recommendation and a place on my team when I have space.

Some of them apply for a role on my team six months later but have done none of it.

I’m probably never going to hire from the second group. I’m not punishing them, but they’ve told me something important: when a hiring manager gave them direct, specific, actionable advice on how to be more competitive, they didn’t follow it.

As someone once said, listen to what they do, not what they say.

If you’re reading this and you’re job-hunting, please listen when a hiring manager tells you what they want, take it seriously. Even if they don’t end up hiring you for the first role, the people who follow the advice get remembered. Mind you, the people who don’t, also get remembered.

If you’re leading technical teams

This one mostly applies if you’re managing analysts, data engineers, or data scientists rather than working solo.

You don’t need to be the strongest technical person on the team. You probably shouldn’t be, if the team is doing its job. But you do need enough fluency to evaluate what’s being shipped, push back when a design decision looks wrong, and notice when someone is over-engineering or under-engineering a problem.

A manager who doesn’t understand the work their team produces ends up trusting too much or too little and has no way to calibrate. Either they rubber-stamp everything because they have no basis to push back, or they get nervous and ask for endless re-explanations that erode the team’s trust in their leader.

This is why I’m skeptical of the “pure people manager” path into data leadership. You can manage a team you don’t understand technically for a while, but eventually you’re going to run into something technical you need to have an opinion on. Make the wrong call, and you’ll spend months untangling tech debt.

A little assignment

If you’re hiring, look at your current screening process and ask: what’s the lowest acceptable bar for technical background?

If the answer is “they have to pass a hard technical screen,” you’re probably filtering out the people I talked about last week.

If the answer is “we don’t really screen for it,” you’re setting yourself up for the failure mode I just described.

The right answer is somewhere in between, and it’s worth being explicit about it. Write down what minimum technical evidence looks like for a candidate you’d hire. Not a test score. Something more like: “Has done at least one technical project on their own initiative and can talk about it specifically when asked.” Then actually use it.

If you’re not hiring but you’re a candidate reading this: the same advice from last time stands. Pick something, build it, finish it. Even badly. Especially if a hiring manager has already told you to.

Subscribe now

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

Some of the most interesting candidates aren’t the strongest technical screeners. They’re the ones who can walk into a room with a skeptical stakeholder, get pushed back on, and not flinch. They already know what RevPAR is and don’t need a glossary to talk about margin. When I describe a messy stakeholder situation, they ask the right diagnostic questions instead of pivoting to which tool they’d use.

We’ve kept our postings open and considered plenty of people who couldn’t code their way through a hard SQL test. Some of those have been the most useful interviews I’ve done all year.

The marginal value of another SQL person is dropping

The economic value of pure technical depth in an analyst role is going down, and it’s going down fast.

Copilot writes the boilerplate. Natural-language query tools handle the “give me revenue by region by month” requests that used to be an analyst’s bread and butter. Modeling layers and metric stores have made the “what is the right join” question less load-bearing. Someone with two years of experience and good AI fluency can now do a lot of what used to take five years and a lot of practice.

It’s not that technical skill ist worthless. The floor is rising, and the ceiling is being defined by something else.

What AI hasn’t gotten any better at is sitting across from a frustrated executive who has decided your numbers are wrong and changing their mind without making them feel stupid. It’s also no better at running a working session with three department heads who all want different things and getting them to a shared definition, or noticing that the question being asked isn’t the question that needs answering, and having the standing to say so.

That work still belongs to a person. The people who can do it well are rare.

What “can’t code” actually means

I’m not saying hire people with zero technical ability. An analyst who can’t write a basic query, read a data model, or sanity-check a result is not an analyst. They’re a project manager and will quickly become a burden on those on your team that can code.

I’m saying “can do hard SQL under pressure in a 45-minute screen” should stop being the gating filter it’s become at most companies. A 6-out-of-10 on that screen can still be a 9-out-of-10 on the things that move work forward in a mature analytics function:

• Domain experience in the industry you operate in

• The social skills to build senior relationships quickly, or relationships they already have

• The ability to disagree with someone two levels above them without folding or getting defensive

• Comfort with ambiguity, including the ambiguity of saying “I don’t know yet, here’s how I’d find out”

• Genuine curiosity about the business, not just the data

These traits are coachable in theory and almost never coached in practice. Technical skill has free resources, AI tutors, and a clear feedback loop. It’s the easier thing to add later.

Subscribe now

A team of all-technicalists falls behind a balanced one

The trap I’ve seen hiring managers fall into is recruiting in your own image. If you came up as a technical IC, you trust technical depth because it’s how you proved your value. That’s what you hire onto your team

You end up with a team that produces correct, well-modeled work that nobody listens to, or one that gets pulled in late to validate something with a chart after the decision has already been shaped.

A team with a mix works differently. Some people anchor the technical work and set the standards there. Others spend most of their time embedded with stakeholders, shaping problems before they become tickets, and translating findings into language that lands. The technical people get to do deeper work because someone else is fielding the “can you just pull these fields” requests with a real conversation. The relationship people bring back sharper questions because they have technical partners who can actually answer them.

That blend is what makes a team look like an advisory function instead of a service desk. You can’t get there if every hire fits the same profile.

How I screen for this

My screening approach takes the technical-versus-business framing off the table, because the two should be inseparable.

I ask them about a problem they’ve solved in the past. Sometimes a tool, sometimes a project. We talk through how they approached it from a business angle and a technical angle. I’m looking for someone who has thought about both.

People without much technical fluency gloss over the details, mention someone else did the building, or talk about a pivot table like it’s the greatest thing since sliced bread. (It is, but I’m looking for a little more.)

People without much business fluency talk about the tools, the stack, and the technical outcomes like accuracy and speed rather than the business outcomes. They focus on the how, not the why.

I’m looking for someone who treats both as one problem. The technical requirements and limitations are defined by what the business has and the tools available to it. That’s the best tell I’ve seen for someone with the instincts I want. Not everyone gets there the first time. Stay engaged and ask as many follow-up questions as you need to get to the meat of the story.

My method isn’t perfect, but it’s helped me avoid a few mistakes over the years.

A little assignment

Look at the last three people you hired, or the last three you interviewed seriously.

For each one, ask:

• What did I actually weight most heavily in the decision?

• If I’m honest, was that because it was the most important thing, or because it was the easiest thing to evaluate?

• What would my team look like in two years if I kept hiring on exactly these criteria?

If the answer to the last one is “a more efficient version of what I already have,” that’s worth sitting with. Most teams don’t need a more efficient version of themselves. They need a different shape.

The analyst-to-advisor shift isn’t only something you do for yourself. It’s also something you build into who you bring on next.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

Share

Both numbers are being used to justify bigger governance budgets, more catalog tooling, more lineage projects, more data quality monitoring spend.

I think that’s the wrong way of interpreting it.

Most of what gets called a “data quality problem” isn’t one. It’s a definition problem, a context problem, or someone using a metric for a question it was never designed to answer. “Better” data quality won’t fix those issues. Even with perfect data, you’ll still find people arguing about what it means.

If you want AI to actually drive better decisions, the bottleneck isn’t your data foundation. It’s how many people in the organization understand what the numbers represent and how they were generated. That’s a literacy problem, and no amount of governance spending or tooling will solve it for you.

Subscribe now

What only 26% of the data is trustworthy means

Think about the last time someone told you they didn’t trust a number.

Maybe they pulled occupancy from one report and saw 78%. They pulled it from another report and saw 81%. They concluded the data was wrong.

In my experience, the data is almost never wrong in cases like that. The two reports are answering slightly different questions. One includes comp rooms, the other doesn’t. One uses arrival date, the other uses stay date. One filters out properties, the other doesn’t.

Both numbers are correct. They’re correct answers to different questions, created with different groups of stakeholders in mind. That gets logged as a data quality issue but it isn’t. It’s a definition issue, dressed in a data governance t-shirt.

The same pattern shows up everywhere. Revenue that doesn’t match between finance and the BI tool because one is net and the other is gross. Customer counts that disagree because one dedupes on email and the other uses customer ID. RevPAR that looks off because someone is dividing by available rooms and someone else is dividing by sellable rooms.

When a data leader reports that 26% of their data is untrustworthy, a big chunk of that 26% is people not knowing which version of “right” they’re looking at. The pipes are fine. We just don’t understand what everyone is talking about.

Share

AI is going to make this worse, not better

The pitch for AI on top of analytics is that natural language unlocks data for everyone. Anyone can ask a question and get an answer. No SQL required.

That’s true… But it’s also the problem.

When an analyst writes a query, they make a hundred small choices. Which table. Which join. Which filter. Which date field. Which definition of “active customer.” Those choices encode context that the analyst usually carries in their head and rarely writes down. The choices are consistent and tailored to the stakeholder.

One could say they’re learned over a series of difficult meetings.

When a business user asks a chatbot “how many active customers do we have,” the bot makes the same hundred choices. It just makes them invisibly, and it makes them based on whatever it can infer from table names and column descriptions. The user gets a confident-looking number but with none of the context an analyst would have applied to it. Sometimes it’s okay, but not always.

It happens to people who should know better, too. Last week I was running a demo and asked the same report two questions I thought were identical. First I asked for the number of hotels still to open in 2026. Then I asked for the number of hotels opening in 2026. Two different numbers came back. Both were correct. The second one caught me off guard because my intent hadn’t changed, but my wording had shifted enough that Copilot answered a different question. If I hadn’t run two sessions back to back, I’d never have noticed the slight difference, which is a problem.

We end up trusting the data too much and not enough at the same time. Too much, because the answer looks authoritative and we stop asking how it was built. Not enough, because when two answers disagree, the response is to dismiss both and go back to gut feel.

Better governance tooling doesn’t close that gap because the gap is human. It’s whether the person asking the question understands enough about how the number was made to know what it can and can’t tell them.

Data literacy is what will move the needle

If you accept that most data quality problems are really definition and context problems, the work shifts. Less of it looks like buying a catalog, and more of it looks like teaching.

There are a few things you can do to smooth the process:

Get your top metrics defined in plain English, signed off by the business owner, and visible everywhere those metrics show up. Not in a wiki nobody reads. In the dashboard, next to the number, in the email, in the chatbot response. If the definition isn’t where the number is, it doesn’t exist. Funny story… Make sure your team is also calculating them the same way. Ask me how I know…

Teach people to ask “how was this calculated” and “what does this include” before they argue about whether it’s right. That single habit prevents most of the “the data is wrong” conversations. Your team should model it relentlessly. When a stakeholder challenges a number, the first response is never “the number is correct,” it’s “let’s walk through how it was built.”

Make it normal for your team to say what a number can’t tell you. If someone asks whether a price increase will hurt retention, and your retention metric only measures people who churned in the first 90 days, you owe them that caveat before you give them the number. This is uncomfortable because it makes you sound less certain. Do it anyway. It’s the difference between being a calculator and being an advisor.

These three habits cost nothing, don’t require a procurement cycle, and do more for trust in your numbers than any tool you could buy this quarter.

Subscribe now

How this connects to trust

A few weeks ago I wrote about trust as a bank account. Every time you deliver what you said you would, every time you flag an issue early, every time you explain what the data can and can’t say, you make a deposit.

This is the same idea looked at from the other direction.

When stakeholders see different numbers in two places and don’t know why, that’s a withdrawal. When the chatbot gives them a wrong answer because it inferred the wrong join, that’s a withdrawal. When you let them walk into a meeting confidently citing a metric they don’t understand, that’s a withdrawal you’ll pay for later.

Definition clarity, context, and teaching people how the numbers are built are deposits. They’re slow, they’re unglamorous, and they don’t get a line item in the budget. But they’re what separates teams that get trusted with strategic work from teams that get treated as a service desk.

A little assignment

Pick one number that gets quoted a lot in your organization. Revenue, active users, churn, conversion, NPS. Doesn’t matter which.

Spend 30 minutes this week answering, in writing:

• What’s the precise definition? Which records are included, which are excluded, what’s the time grain?

• Where does it show up? Dashboards, decks, board reports, the chatbot.

• Are the definitions in those places consistent? If not, where do they diverge?

• What questions can this number actually answer? What questions does it get used for that it shouldn’t?

If you can’t answer all four in 30 minutes, that’s your new project. Not because the data is bad, but because the shared understanding around it is thinner than you need it to be.

Governance isn’t just about the pipes. It’s about making sure people know what the numbers are and are not telling them.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

Not all of them, but enough of them. The filters sit in the wrong place, the view I want is a few too many clicks away, my favorite visuals aren’t big enough and I can’t for the life of me find the export button.

Recently I was part of a project handoff. The analyst taking over the work rebuilt the dashboard in their own preferred format within a couple of weeks, which was a totally reasonable thing for them to do. It made me stop and think, though. If we do that to each other, what on earth are our stakeholders doing?

They’re not rebuilding the dashboard. They’re either not using it, using it wrong, or asking for a spreadsheet because it’s easier than figuring out which of our fourteen filters to click and which parameter controls which deep dive.

As data teams, we see success creating ways to easily get stakeholders the information they need without them calling us, and somewhere along the way we’ve equated that with shipping beautifully built dashboards.

Those two things are not always the same.

Subscribe now

AI agents are coming

Gartner is predicting that 40% of enterprise applications will have task-specific AI agents embedded in them by the end of 2026, up from less than 5% today. Whatever you think of Gartner’s forecasts, this is already happening. Every BI vendor with a pulse is shipping an agent. Snowflake has one. Databricks has one. Power BI and Tableau have them. The “ask your data a question in plain English” pitch has gone from novelty to baseline expectation in about eighteen months.

The standard analyst reaction to this news is panic. If the tool can answer questions directly, the job feels threatened.

I think that reaction has it backwards. If your job was building the fifth variation of the same KPI tile, that job wasn’t strategic to start with. We’ve been telling each other for a decade that we want to be partners, not report factories. Something that finally breaks the dashboard-as-deliverable model is doing us a favor, even if it’s going to take us a little reprogramming to see it clearly.

Dashboard adoption has always been low

Dashboard adoption has always been bad. Studies consistently put regular dashboard usage somewhere around 20%. Yes that means 20% of the people you built your dashboard for are using it. The rest of them are probably still guessing.

Most of us have seen this pattern. You ship the dashboard, stakeholders are excited for a week, and then usage drops to the one person who asked for it, plus whoever has it bookmarked and a handful of people who report to them, because we all know it’s better to use what the boss wants.

The reason isn’t that people are lazy. A dashboard is a piece of furniture built for a specific conversation, and business conversations move. By the time the dashboard is “done,” the question has shifted. The next question doesn’t quite work, so the stakeholder pings you for “a quick pull,” and you’re back to being a service desk.

Agents break that loop in a useful way. Instead of shipping a fixed view and hoping the question doesn’t move, you expose a governed set of metrics and let people ask what they need to know. The work moves from “build the chart” to “make sure the thing behind the chart is trustworthy and well defined.” That’s what we’ve wanted to do for years.

Subscribe now

What matters more when agents are in the mix

If you liked the framing from a couple of weeks ago on outputs versus outcomes, this is the same idea in different clothes (probably cooler, AI futuristic clothes). Outputs are dashboards, reports, and models. Outcomes are decisions made, revenue changed, costs saved, risks reduced. The top teams have always oriented around the second list, and agents are going to make life hard for teams who want to stick with the first one.

A few things become more valuable, not less, when agents are in the mix:

• Metric definitions. When a stakeholder asks an agent “what was RevPAR in Q3,” you do not want it answering from three different tables with three different definitions. Someone has to own what “RevPAR” means, where it lives, and how it’s calculated.

• Business context. Agents are good at retrieving. They’re bad at knowing which question is the right one to ask. Translating “engagement is down” into “which specific cohort, on which surface, and what’s the realistic lever” is still human work.

• Last-mile judgment. Knowing when the number is wrong, when the question is the wrong one, when the recommendation should be “do nothing yet.” These are the critical calls that can’t be trusted to an agent. An agent can surface an anomaly. It cannot tell you whether now is the right moment to bring it up with the CFO.

• Trust and reliability. When your stakeholders trust the agent’s answers, it’s because they trust the people who defined what’s underneath. If the semantic layer is a mess, the agent will confidently be wrong frequently, which is worse than a human being quiety wrong occasionally.

What this means for your team

Some of the work is going away. The dashboard refreshes, the “can you just pull these fields into a spreadsheet” requests, the fifth version of the same churn report. If your team’s value proposition is the volume of tickets closed, you’re in trouble.

The teams that come through it well are the ones who start shifting their time now, before the change forces it. That means getting serious about metric definitions, sitting with stakeholders earlier in their decision process, and becoming the team they want in the room when a difficult decision is on the table. You want to be the first call, not the cleanup crew when the agent gives a confusing answer.

It also means being honest with your team about what’s changing. If you lead people, the worst thing you can do is pretend nothing is happening and let them find out from a vendor demo. The best thing you can do is start showing them what the higher-leverage work looks like and giving them room to practice it.

Share

A little assignment

Look at what your team produced over the last few months. For each meaningful piece of work, ask two questions.

If an agent could reasonably produce this in six months, what was the value you added on top of it? Framing? Context? A recommendation? A relationship that made someone act?

If the honest answer is “not much,” you’ve found the work that needs to start changing. Not because agents will take your job. Because the part of the job that was always going to matter is the part most of us have been underweighting.

The good news is that the diagnosis is also the prescription. Spend less time building the dashboard. Spend more time sitting next to the person who was going to use it. Ask them what decision they’re trying to make, and start there.

That’s harder than building the dashboard. It’s also the thing nobody can automate out from under you.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.

I’m not just talking about presenting insights. I’m talking about the rest of it too: getting a project approved, landing a process change, making sure your team knows a table schema changed before they find out the hard way. The operational communication that keeps everything running or, when it fails, grinds things to a halt.

Most of the communication that matters in your job isn’t interesting... So we don’t think about it.

The boring stuff is the stuff that breaks

A table change notification. A reporting logic update. A deprecation warning for a data source your team has been using for years. A change to how a metric is calculated that will affect a bunch of downstream dashboards.

None of this is exciting and none of it will make anyone’s day (in fact, it’s frequently the opposite - more work), but all of it will cause problems if people miss it.

And people miss it constantly.

A Grammarly and Harris Poll study found that knowledge workers spend 88% of their workweek communicating across multiple channels, and 100% of those surveyed experience miscommunications at least weekly. Your carefully worded Slack message about a field name change is landing alongside hundreds of other messages, most of which also feel important to whoever sent them.

The sheer volume means your stakeholders and teammates are not reading most of what they receive. They’re scanning. Scanning favors things that look urgent, unusual or interesting. A notification about a table migration is none of those.

Subscribe now

Getting things approved

The other side of operational communication is getting decisions made. Budget for a new tool. Headcount for the next quarter. Approval to deprecate a report nobody uses but everyone is emotionally attached to. A green light on a project that requires another team’s time.

I’ve watched good ideas fail because the person pitching them buried the ask under three paragraphs of background. I’ve also watched less compelling ideas get approved quickly because the person was clear about what they needed, why it mattered, and what would happen if the answer was no.

The structure that works is simple: state what you need, state why it matters in terms your approver cares about, state the cost of doing nothing, and state the timeline. I spent years making these requests more complex than they needed to be, adding extra justification because I assumed more detail would be more persuasive. More detail is usually less persuasive, because it takes longer to process and busy people stop processing when something takes too long.

Communicating within your team

Internal team communication gets neglected because it feels like it should just happen. Everyone’s on the same Slack channel. Everyone can see the ticket board. Everyone was in the standup.

The most common way your team finds out about a breaking change is when something breaks.

If you lead a team, or even just work on one, the standard you set for how changes get communicated determines how much time you spend firefighting later. The time you invest in writing a clear, concise update about a logic change saves multiples of that time when three people don’t have to debug dashboards that suddenly show different numbers.

A few things I’ve learned, mostly by getting them wrong first:

• Important operational updates need their own message, not a thread buried inside a different conversation. Bold the change, state who is affected, and include the date it takes effect. If someone needs more context, they’ll ask.

• Repeat yourself more than feels natural. Research from Stanford found that leaders are far more likely to be criticized for undercommunicating than overcommunicating. What feels like saying the same thing three times feels, to your team, like hearing it once.

• When communicating changes that affect people outside your team, state what changed in their terms, not yours. “The logic for calculating RevPAR now excludes complimentary rooms” means more to a revenue manager than “we updated the filter criteria on table dim_reservations.”

  Share

The art of the follow-up

Clear communication gets you halfway there. The other half is following up when nothing happens.

This is where a lot of data professionals give up too early. You send the request, you don’t hear back, and you assume the answer is no or that it’s not the right time. Sometimes that’s true. More often, your message just got lost in the noise, and the person you sent it to fully intends to get to it eventually.

I’ve gotten a lot of things done for my team by being polite, kind, curious, and persistent. A gentle follow-up a few days later. Another one the following week. A quick “just wanted to make sure this didn’t fall off your radar” with the original context restated so they don’t have to dig for it. Most people appreciate the nudge. They know they’re behind on things and are grateful when someone makes it easy to catch up.

The key is patience. Slow, steady follow-up works. It signals that the request matters enough for you to keep tracking it without making the other person feel cornered or pressured. You want to be the person who is easy to work with and hard to forget about.

When follow-up alone isn’t enough, you need to know when to escalate. If you’ve been polite and persistent and you’re still not getting what your team needs, it’s reasonable to raise it to your boss, or to loop in their boss. This isn’t going over someone’s head. It’s making sure your team’s priorities are taken with an appropriate level of seriousness. Part of your job, especially if you lead a team, is making sure the people and resources you need are available. Sometimes that means having a conversation at a higher level to unblock things.

Subscribe now

A note on urgency

There’s a temptation, when you realize how easy it is for things to get lost, to start marking everything as urgent. It works, at first. Urgent things get acted on faster.

The problem is that if everything you send is framed as a crisis, people learn to treat your crises like background noise. As I wrote last week in “The Analyst Who Cried Wolf,” raising every issue to the highest severity erodes the trust you’ve built, and when something genuinely critical happens, you’ve already spent your credibility.

Calibrate your urgency to match the actual stakes. Save the all-caps, the red flags, and the “we need to talk about this today” language for the things that warrant it. For everything else, clear and calm communication, paired with consistent follow-up, will get you further than false urgency ever will.

A little assignment

Pick one operational communication you need to send this week. A change notification, a resource request, a project update, anything that isn’t a data insight.

Before you send it, write down the one thing you need the reader to do or know. Look at your draft and find that thing. If it’s buried after two paragraphs of context, move it to the top.

If you’re sending it to a group, assume half of them will only read the first two lines. Make those two lines count.

Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, a bit more actionable. You can find them at the Penguin Analytics store.

One of our senior stakeholders asked me how my team was doing, workload-wise. Before I could think about it, I heard myself say, “We’re busy, but we’re managing,” which is about as true as saying the Titanic had a minor plumbing issue.

I didn’t catch myself until after the conversation. The instinct to put on a brave face was so automatic that I’d already done it before I realized I was doing it. I wanted to seem like I had things under control. I wanted to protect my team. I wanted to not be the person who couldn’t handle it.

If I do that to my boss, and I’m someone who writes a newsletter about being honest at work (the irony is not lost on me), your team does it to you. You probably do too.

Subscribe now

Why they’re not telling you the whole truth

Let’s be honest (see what I did there?), this is about self-preservation, not about being dishonest.

Kim Scott talks about this in Radical Candor. Most managers default to what she calls “ruinous empathy,” where everyone is so focused on being nice and avoiding discomfort that the truth gets smoothed over until it’s unrecognizable. But the same dynamic runs in reverse, too. Your team is managing up, protecting you from bad news, telling you things are fine because saying otherwise feels risky, even when you’ve done everything right to make it safe.

A 2023 Wiley survey found that only 57% of employees feel comfortable speaking up, compared to 89% of executives. That gap should concern you, because the executives think the environment is open and the people closest to the work disagree.

Even in teams with high psychological safety, people filter. Amy Edmondson’s research at Harvard shows that employees who start out willing to speak freely often become more cautious over time. The longer they’ve been around, the more they’ve learned what reactions to expect, and the more carefully they choose what to share.

You can build the safest environment in the world and still get a version of the truth that’s been edited for your comfort.

How to spot it

Since people won’t always tell you directly, you need to learn to read the signals they’re sending indirectly. A few things I’ve learned to watch for:

Calendar density. If your team’s calendars are wall-to-wall meetings with no gaps, they’re not thinking, they’re just executing. Nobody will tell you “I don’t have time to think.” They’ll just start producing lower quality work, and neither of you will connect the two things immediately.

The “everything’s fine” pattern. If someone says everything is fine every single time you ask, something is not fine. Real work has friction. If you never hear about any of it, you’re not hearing the whole story.

Volunteering drops off. When people are stretched, they stop raising their hands for new things. They don’t announce it. They just quietly stop. If someone who used to jump on new projects hasn’t volunteered in a while, that’s a data point.

Turnover in small ways. Before someone leaves your team, they usually leave in smaller ways first. They skip optional meetings. They stop contributing to conversations. They disengage from social channels. These are all leading indicators that something shifted, and nobody told you about it.

Back in January I found out that two people who worked for me had been putting in late nights and weekends to finish up projects. I knew we were busy, but I had missed just how stretched we were. I was shocked - and annoyed with myself - for missing some signals. One of them said everything was fine, one of them told me about being in more meetings than I expected, and he was still churning out a huge amount of work. I took his answer at face value instead of questioning where the time was coming from.

Share

Ask better questions

“How are things going?” is the question that gets you “fine.” It’s too easy to answer on autopilot.

Instead, try questions that require a specific answer. “What’s the one thing on your plate right now that’s taking longer than it should?” forces a different kind of response. “If you had to drop one project this week, which one would it be?” tells you what they think is lowest value. “What’s something I could take off your plate that would make the biggest difference?” invites them to ask for help without it feeling like a confession.

Kim Scott’s advice on soliciting feedback applies here, too. She suggests asking your question and then waiting. Count to six in your head. Six seconds of silence feels long, and people will fill it with something more real than their first instinct, which is to reassure you. I had a boss that did this, and it worked, even when I knew she was doing it. I stole it to use with my team, and it works on most of them, too.

The key is that these are not interrogations. They’re invitations. And you have to be genuinely willing to hear the answer, even when it means you’ve been wrong about how things are going.

What to do with what you hear

This is where most leaders inadvertently train their team to stop being honest. You ask for candor. Someone gives it to you. And then you react.

Maybe you jump into problem-solving mode before they’ve finished talking. Maybe your face falls and they can see you’re disappointed. Maybe you say “okay, let me think about that” and never bring it up again. Each of those responses teaches the same lesson: it wasn’t worth sharing.

When someone tells you the truth about workload, morale, or a problem they’ve been sitting on, the single most important thing you can do is make them glad they said it. Thank them. Take it seriously. Follow up. This doesn’t mean you fix everything on the spot. It means you demonstrate, through actions, that honesty has better outcomes than silence.

And keep in mind, you’re probably doing the same thing in reverse. I caught myself doing it yesterday. The instinct to project competence is deeply wired, and it runs at every level of the org chart. Being aware of that in yourself makes it a lot easier to be compassionate about it in others.

Subscribe now

A little assignment

This week, pick one person on your team and try one of the specific questions above in your next 1:1. Not “how are things?” but something that requires a real answer.

Then, pay attention to what happens after they answer. Did you listen, or did you start solving? Did you follow up later, or did it disappear?

The goal isn’t to catch your team in a lie. It’s to make telling the truth feel like the obvious choice.

Some of what I write about here I’ve turned into proper playbooks. They’re a more in-depth, more structured, a bit more actionable. You can find them at the Penguin Analytics store.

I’ll admit I’m probably too far in the other direction. I’ve shipped analysis on data I knew had rough edges, because the margin of error didn’t change the recommendation. But this person genuinely believed that if the data wasn’t pristine, we had no business drawing conclusions from it. I respected that instinct. They cared deeply about getting it right.

What I didn’t do well was help them channel it. We chased down every issue. Every. One. Our data engineering partners got tired of hearing from us, and I don’t blame them. One of our big priority projects stalled because we spent weeks investigating a handful of mismatched records instead of delivering the analysis those records were supposed to support. We turned a minor quality issue into a major credibility issue, because we trained our stakeholders to think something was always wrong.

When everything is urgent, nothing is.

Subscribe now

How this burns trust

Analytics teams can lose credibility in obvious ways: bad numbers in an important deck, a metric that doesn’t match other teams, a dashboard that’s clearly broken. Those are the visible and dramatic ways.

But there’s a more subtle version, and it’s more common. Your team flags issues constantly. Small ones. Stakeholders get pulled into conversations about data quality problems that don’t affect any decision they’re trying to make. After enough rounds of “we found an issue, we’re looking into it, it might affect the numbers,” people start tuning you out.

It’s not that they don’t care about data quality or good decisions. They’ve just learned that your team treats every problem like a five-alarm fire, and most of them turn out to be campfires.

When you eventually find something that actually matters, a real problem that changes a recommendation or invalidates a report, you’ve already spent your credibility. The people who need to listen have learned to nod politely and move on.

That’s the analyst who cried wolf. Frequently, it’s a team that never learned to triage.

The materiality question

The fix starts with a concept borrowed from accounting: materiality. Not every data issue is worth investigating, and not every investigation is worth escalating. The question to ask isn’t “is this wrong?” It’s “does this change a decision?”

A few hundred rows out of several million that don’t match between two systems might be worth a note in your documentation. It’s probably not worth a three-week investigation and four meetings with your data engineering team. In the real world we live with small discrepancies between systems because the data in them is still useful even though the discrepancy exists. We know about them, we talk openly about them, and we’re clear about what can be done with them.

Teach your team to ask three things before they escalate:

1. What is the scale of the issue relative to the dataset? If it’s a fraction of a percent, document it and move on.

2. Does fixing it change the conclusion or recommendation? If the answer stays the same either way, the issue is real but not urgent.

3. What is the cost of investigating versus the cost of accepting it? Three weeks of an analyst’s time has a price. So does the relationship capital you spend asking your data engineering partners to drop what they’re doing.

This isn’t about lowering your standards. It’s about applying them proportionally.

Subscribe now

Coaching without crushing the instinct

The person who flags everything usually cares deeply about getting it right. That’s a quality you want on your team. If you dismiss their concerns or make them feel foolish, they’ll stop caring. You’ll fix the over-escalation problem and create a much worse one.

What worked for me (eventually, after more trial and error than I’d like to admit) was making triage a shared exercise. Instead of telling someone their concern didn’t matter, I’d sit with them and walk through the materiality questions together. How many records are affected? What’s the potential impact on the output? If we fixed this, would the recommendation change?

Most of the time, they’d arrive at the answer themselves. The issue was real, but it wasn’t material. Over time, they started running that assessment on their own before bringing it to me.

The message was always “let’s get better at sizing problems,” never “stop finding them.”

Rebuilding when the damage is already done

If your stakeholders have started tuning you out, or your engineering partners flinch when they see your name in their inbox, you can turn it around, but you have to be direct about it. Tell them what’s changed: “We’ve been over-escalating issues that didn’t warrant it, and I know that’s been frustrating. We’ve changed how we triage, and when we bring something to you now, it’s because it affects a decision.”

Then prove it. The next few times you escalate, make the materiality case explicit. Show the scale, the impact, the decision at stake. Two or three rounds of that, where every escalation is clearly worth their time, and you’ll start rebuilding the trust account. People remember when you own a mistake and then follow through on fixing it.

A little assignment

Look at the last three data quality issues your team flagged or escalated. For each one, answer:

Did it change a recommendation or decision? How much time did it take to investigate? Was the escalation proportional to the impact?

If two or three of them were real issues but not material ones, that’s your signal. You don’t have a quality problem. You have a triage problem. And triage is a skill you can teach.

Some of what I write about here I’ve also turned into proper playbooks. They’re a bit more structured, a bit more actionable. You can find them at the Penguin Analytics store.

A better intake process is the structural fix. A consistent way to receive, evaluate, and route work before it lands on anyone’s desk. When it works, it’s also how you stop being a service desk and start being something more useful — what I’ll call an advisor.

An advisor is someone who shapes what gets requested in the first place, not someone who simply produces outputs in response to requests. A service desk gets asked for things and delivers them. An advisor has enough standing to say “are you sure that’s the right question?” and get taken seriously.

Intake is how you build that standing. It’s where the conversation about what a request is actually for happens before any work starts.

Subscribe now

One front door

You need one place where all requests land. Not direct messages, not email threads that die in someone’s inbox, not hallway conversations that get forgotten by Monday. One place. A form, a shared channel with a form attached, a simple service desk. In the end the medium matters less than how well you enforce it.

This is harder than it sounds. Senior stakeholders in particular tend to believe their ask is too important or too urgent to go through a process. It usually isn’t. The front door exists precisely for important, urgent things. They can be moved to the front of the line and acted on quickly. Your job is to hold the line long enough that using it becomes the default. Make it easy enough that it’s genuinely less work than finding an analyst directly.

Keep the form short. Problem in plain language, the decision it’s supposed to support, who owns that decision, the deadline and why it exists, rough business impact. That’s enough. Don’t ask requesters to name their data sources or estimate complexity — they don’t know, and asking them to guess produces bad inputs that waste time in triage anyway.

White paper or dashboard?

The single most important triage decision is one most teams skip: is this a one-time analysis or an ongoing commitment?

I think of these as white papers and dashboards. A white paper is a bounded piece of work — someone has a question, you answer it, it’s done. The scope is defined, there’s a delivery point, the analyst moves on. These can be urgent and significant, but once they’re done, they’re done.

A dashboard is different in almost every way. It takes longer to build than people expect. It needs maintenance when the underlying data changes… and the underlying data always changes. Someone has to own it after delivery, which rarely gets discussed upfront. It has a shelf life that nobody manages, which is how teams end up supporting fourteen dashboards that six people look at and only two senior members can explain.

Most teams treat these two things identically at intake, which means they commit to dashboards with the same casual speed they commit to one-off analyses. Before a dashboard request goes into the queue, you need answers to four things: Who owns this after we build it? What decisions will it inform and how often? What’s the plan when the data structure changes? Is there an existing report this replaces, or are we just adding another one?

Getting those answers before you start isn’t slowing things down. It prevents you from running in the wrong direction. You’ll get it right eventually, so the only question is how much time you’re going to waste in the process.

Share

Triage before you commit to anything

Once something comes through the door, someone needs to do a quick assessment before any real work starts. You don’t need to fully scope it, just figure out whether the request belongs in the queue at all, and what kind of thing it is.

Beyond the white paper versus dashboard split, most work falls into a handful of buckets: one-time analysis, updates to recurring reporting, data access, or something large enough to need real scoping before you can even estimate the effort. Each has different timelines and probably different owners on your team. Routing early matters.

Triage is also where you catch things that shouldn’t have come to you at all. The ask that’s really an IT issue. The dashboard request that’s actually a request for a business decision that hasn’t been made yet. The thing that’s been on someone’s wishlist for eighteen months and finally got submitted because submitting is free. Catching those early is useful. It’s also where you start to function like an advisor rather than a processor. You’re shaping what gets done in what order, not just working through whatever lands.

Pick a prioritization approach and stick to it

There are a lot of frameworks for this — scoring models, impact/effort matrices, weighted calculations with acronyms. I’ve tried most of them with varying degrees of commitment and learned, more slowly than I’d like, that the framework matters much less than the consistency.

A simple four-bucket system — urgent and important, important but not urgent, urgent but not important, neither — used every week without relitigating it, will outperform a sophisticated scoring model that nobody has time to maintain. My most recent process simply uses high, medium and low. Pick something your team will actually use, agree on it, and hold to it long enough for it to break, then adjust.

What most frameworks miss is WIP limits — caps on how many things are actually in progress at once. Prioritization tells you the order. WIP limits tell you when to stop taking on more. Without them, a well-prioritized backlog is still just a longer queue. Two or three active projects per analyst is a reasonable starting cap. When something new needs to jump the line, something else moves. That conversation with the stakeholder — explaining what gets displaced and why — is one of the more advisor-like interactions you can have.

Two tracks, not one

Intake systems can accidentally entrench the dynamic you’re trying to escape. If every request — a broken filter on a report and a major strategic question — goes through the same channel and gets treated the same way, the organizational message is that you’re a helpdesk.

Routine, repeatable work belongs in the regular process: access requests, standard updates, known fixes. Clear timelines, predictable outputs, everyone knows what to expect. High-leverage strategic work — new frameworks, big business questions, cross-functional initiatives — needs to go through the process differently. Those questions deserve to be pulled out and considered as separate projects, not as another ticket.

This also matters for retention. If everything is a ticket, analysts start feeling like ticket processors. The juicy, exploratory, ambiguous work that good analysts love and are good at gets buried under maintenance.

Make the pipeline visible

The part most data leaders skip: stakeholders need to be able to see what’s in the queue, what got accepted, what got delayed, and why. Without that visibility, requests feel like they disappear. People follow up through other channels, ask a manager, or resubmit the same thing three weeks later assuming it was missed.

A regular review with key business partners — monthly is usually enough — where they can see the full picture and understand the tradeoffs, changes this. Most stakeholders are reasonable when they understand what’s competing for the same capacity. They’re unreasonable when they’re operating in the dark.

Subscribe now

A little assignment

Before building anything, audit what you have. Three questions worth answering now:

• Where are requests currently coming from, and which channels bypass whatever process you already have?

• Of the recurring reports and dashboards your team currently supports, how many have a named owner outside the data team? How many could you retire without anyone noticing?

• If you asked three people on your team how work gets prioritized, would you get the same answer from all three?

You don’t need a perfect system on day one. In fact, I’d recommend simple and used beats overengineered and abandoned. Pick one front door, treat white papers differently from dashboards, agree on a prioritization approach, and hold the line for a month.

You’re not the project management office. You’re looking for a place where the work your team is doing is the work that actually matters.

Some of what I write about here I've also turned into proper playbooks. They’re a bit more structured, a bit more actionable. You can find them at the Penguin Analytics store.

But we’d been busy. Our updates were packed with tasks people had been working on, we’d had to push deadlines because we didn’t have the capacity to finish working on things. We’d worked our tails off for… Very little tangible output.

What I had discovered is one of the more insidious things about managing a data team: busy and productive can look identical from the outside, and sometimes from the inside too. The team is at their desks, responding to messages, showing up to meetings, handling things… But nothing consequential is moving.

Subscribe now

The five-minute question

Every data team I’ve been part of has had some version of this. A stakeholder sends a message with something framed as a quick ask. Can you check what that number was last month? Can you pull the breakdown by region? Won’t take long.

And they’re right that it doesn’t take long. Ten minutes, maybe. The problem is that it doesn’t happen once. A busy analyst might field five or six of these in a day, each arriving at a random point in whatever they were actually working on. Research from UC Irvine found it takes around 23 minutes to return to deep focus after an interruption. Five of those in a day and you’ve lost the better part of the productive hours regardless of how fast or easy each answer was.

The five-minute question is rarely malicious. Stakeholders aren’t trying to wreck the week. They genuinely think it’s a small ask. And because it is small, it feels difficult to push back on. So the analyst answers it, switches back to their actual work, gets another ping, and the cycle repeats. At the end of the week, they have happy stakeholders, but have shipped almost nothing of substance.

Meetings that don’t need everyone in them

Data teams attract meeting invites the way a light attracts moths. A business review happens and someone figures the data team should probably be there. A cross-functional planning session gets going and the data team is looped in just in case numbers come up. Before long, multiple analysts are sitting on a call where they’re useful for about five minutes and present for an hour.

A lot of this is well-intentioned. Managers add analysts to meetings because they don’t want them blindsided by decisions that affect their work. Analysts accept invites because declining feels like opting out. Meeting FOMO is real, and in organizations where presence gets read as contribution, it’s not an irrational instinct.

But the cost isn’t just the meeting itself. It’s what happens around it. An analyst who has a meeting at 10am can’t really start deep work at 9:30. After the meeting they need time to reload whatever context they’d dropped. Stack two or three of these across the day and you’ve created a schedule that looks full on the calendar and produces almost nothing requiring sustained thought. Research puts genuine deep focus time for the average knowledge worker at under three hours in a typical eight-hour day. Meetings compress that further.

The question worth asking about any meeting with an analyst isn’t “could they contribute here?” Most people can contribute to most meetings. It’s whether their live presence is worth what it costs. Often a short debrief afterward would have done the same job.

Share

The data quality rabbit hole

An analyst sits down to answer a business question. Midway through, something looks off — a number that doesn’t match expectations, a gap in records for a period that should have data. So they stop and dig. One hour becomes three. The original analysis sits unfinished. The stakeholder follows up, and the analyst explains they hit a data issue.

Add to this the time that can be wasted convincing IT teams there’s a real problem, explaining the context, revalidating fixes, etc. There’s a whole rabbit warren underneath some of these issues.

Data quality problems are real and important. Some of them genuinely need to be resolved before you can trust an output, but not every anomaly is material to the question at hand, and the habit of treating every irregularity as a full stop — rather than asking whether it actually changes the conclusion — is one of the more reliable ways to turn a half-day analysis into a multi-day investigation.

The question to ask is: does this affect the answer? If the gap represents 0.3% of records and the business question is directional, probably not. Flag it, document what you excluded and why, deliver the analysis with a note. If the issue is in a core field the entire conclusion rests on, stop and fix it. Those are genuinely different situations and they warrant different responses.

Teaching analysts to make that materiality call is one of the more underrated things a manager can work on. We’re teaching good judgement.

A little assignment

Look at the last five working days across your team and pull three numbers. How many ad hoc requests came in framed as quick asks, and how many of those interrupted something already in progress? How many meetings had more than one analyst present — and for each one, was that actually necessary? How many analyses stalled or slipped for reasons that had nothing to do with the analysis itself?

You’re looking for a rough read on how much of the week was genuinely available for focused, consequential work versus going to things that felt productive but weren’t moving anything important.

Next week: what you can do about it.

Some of what I write about here I’ve also turned into proper field guides — a bit more structured, a bit more actionable. You can find them at the Penguin Analytics store.

Subscribe now