Every shared-service function goes through a similar awkward adolescence. Data, IT, marketing ops, … you name it. At some point a small team is asked to do two things at once: build the foundations the whole company will eventually rely on, and deliver the tasks stakeholders are assigning them right now. Those two things compete for the same hours, and the tension between them doesn’t resolve on its own. It has to be managed.
What's a "Data CoE"?
Center of Excellence (CoE) is corporate shorthand for a small team of subject-matter experts a company sets up to serve the whole organization on one domain, here: data. In plain terms, it’s a shared data hub, or simply an internal data team, that other departments come to for models, reports, and analysis instead of hiring their own.
This post uses “CoE” as the label, but “data hub” or “data team” mean the same thing, so read them interchangeably.
Once a data hub is mature, this problem mostly disappears. For a “Data Department”, it occurs when the models are solid, the pipelines rarely fail and have finished processing fresh data before anyone joins the office. Answering a business owner’s question becomes fast and cheap. At this point, most of the team’s “inner work” shifts to R&D rather than firefighting.
But getting there takes time, and during that time, the team is doing scrum-shaped work (build the foundation in sprints) and kanban-shaped work (answer the stakeholder as a helpdesk) simultaneously, with the same people. It can become stressful if not properly prioritized internally and communicated externally.
A CMMI-like maturity model for a Data Team. Credits: HeadToNet
The trap: treating every request the same
Imagine a finance team asking for a model that can answer any revenue question they might have; clean, production-grade, extensible. That’s genuinely valuable, and obviously slow to build properly.
Meanwhile, finance also wants this month’s forecast by Friday.
The instinct is to treat these as the same problem : finish the real model, then answer the question. In practice, the better move is almost always to decouple them. Deliver the forecast now, via one specific, narrow, slightly manual query. Reuse that same query next month. And the month after that. Keep reusing it, on a kind of autopilot, right up until the real model is ready to take over. Nobody notices the seam, and nobody had to wait for a foundation that wasn’t built yet.
This is the core move: an ad-hoc answer isn’t a failure to have a model. It’s a deliberate release valve while the model gets built. This sounds easy, but in practice, stakeholders like to ask various questions all the time, so having one single ad hoc query won’t help in the long run, and the model still needs to be built.
While your org is still immature, stakeholders won’t be frustrated: they know each query is hard to get, so they ask less and expect to wait. But once they start expecting more autonomous data delivery, request volume grows faster than your delivery speed until the models are built. That gap is where you, as a manager, have to triage sharply and over-communicate to keep frustration down.
What actually decides priority
The hard part isn’t to accept your team will need to work on two similar jobs to satisfy short term and long term expectations. It’s making the call, request by request, in real time, to split your team’s work across these two distinct lanes.
The instinct to let the most senior requester jump the queue is exactly the instinct to resist. A CEO asking for a deep, bespoke model doesn’t automatically outrank a simple, reusable model that a dozen other stakeholders would also benefit from. Seniority is one input, not the only one.
In practice, I’ve found six criteria worth weighing together. The first four are about value (who wants this, and how much good it does):
- Who is this for. Seniority matters, not because of years, but usually because there decisions have more weight on the company’s strategy. Answering an intern has generally less impact.
- How critical is it. Casual curiosity versus something a real decision depends on. Some Senior people can be very curious: it’s good to challenge the requests you receive.
- Will this come up again. A one-off question is a candidate for an ad-hoc answer. A recurring one is a candidate for a model.
- Who benefits, long-term. One stakeholder, or half the company.
Value alone isn’t the whole picture, though, it has to be weighed against cost:
- How much effort this actually takes. A five-minute query and a three-week data model can both be “recurring and broadly useful,” and that difference changes everything about whether it belongs in this sprint or the next one.
- How urgent it is. Not the same axis as criticality: a request can be low-stakes but due Friday, or genuinely important with no real deadline at all.
- How much trust or compliance risk it brings. A number headed into an investor deck deserves more scrutiny than an internal curiosity question.
A request that’s senior, urgent, and one-off gets an ad-hoc answer, fast, with no guilt about skipping the model. A request that’s modest, recurring, and broadly useful (and cheap enough to build properly) is exactly the kind of thing worth pulling engineering time toward, even if the person asking isn’t the loudest voice in the room.
Sometimes the request happens to piggyback on a model that’s already mostly built for something else: the cheapest way to answer a new question is that you were already halfway there.
Here’s the same six criteria run against two real requests, to show how the same checklist can point in opposite directions:
The challenge for you also lives in the fact that a stakeholder just knows she wants an answer. It doesn’t matter to her whether it comes from an ad-hoc query or a long-term data model.
Making the workload visible without making people anxious
This is a second problem that comes with the prioritization question: communication. A kanban board that’s visible to stakeholders is a double-edged tool. On one hand, it’s honest: new stakeholders can see the queue, see roughly how long things take, and calibrate their expectations accordingly. On the other hand, watching your own request sit untouched for three weeks is not a pleasant experience, and a static board with no context reads as neglect even when it isn’t.
The fix I’ve used is a weekly meeting, one per stakeholder group. In a company organized around business units, that’s usually a natural split. Each week, one hour: the data analyst who owns that group’s requests, me as the manager, and a small group of senior stakeholders from that business unit (in one real setup, the BU director, the BU head of product, and the BU head of marketing).
The meeting does three things at once. The stakeholders see the actual state of the board, not a secondhand summary. I explain what foundational work is consuming capacity right now, and why, which turns “why is this taking so long” into a conversation instead of a complaint. And the analyst re-arranges the board live: adding what’s new, re-prioritizing what’s changed, closing out what shipped. Nobody leaves the room wondering where their request stands.
The board isn’t just for the people using it
One more piece of this, easy to miss: not everyone on the data hub actually touches both boards day to day. The people building the backend (data engineers working on infrastructure and the stack) live almost entirely in scrum. The people facing stakeholders (data analysts, data scientists) live almost entirely in kanban. Unless you already have hybrid profiles such as Analytics Engineers, the manager is usually the only one juggling both.
The temptation is to let that split harden into “this board is for that team.” I’d argue against it. We made a point of keeping both boards visible to the whole team, including the engineers who rarely touch the kanban directly. The payoff shows up more often than you’d expect: an engineer glancing at a recurring stakeholder request they’d otherwise never see will sometimes spot a simple, buildable fix that turns a repeated ad-hoc answer into an automated one, then propose joint work with the analyst handling it. That connection doesn’t happen if the two boards live in two separate worlds.
The trade-off between engineers and analysts
There’s one more decision that’s genuinely hard to get right, and I don’t have a clean answer for it: how much backend capacity to staff up early.
More engineers early means foundations get built faster, which means the data hub reaches maturity sooner. That sounds like an easy call, until the team actually reaches maturity. At that point, a lot of the backend work that justified that headcount simply isn’t there anymore. You’ve traded early speed for a team that’s now larger than the ongoing “inner work” requires.
Under-staff the backend instead, and the team stays lean for the long run, but the early years are harder. More requests get stuck in the ad-hoc lane longer than anyone would like, and the foundational work keeps losing to the next urgent stakeholder ask.
I don’t think there’s a universally right answer here. It depends on how much runway the company has, how fast the CoE team actually needs to mature, and how much short-term frustration the organization can absorb.
It also depends on the shape of the team. A group split cleanly into data engineers and data analysts hits this trade-off head-on, because the two roles pull in opposite directions and only the manager bridges them. A team with a dedicated analytics engineer works differently: that role turns stakeholder requests into reusable models as it goes, so the backend and the kanban lane stay connected without a pure headcount bet. What I do think is worth doing is naming the trade-off honestly, up front, instead of pretending the early hiring plan is purely a capacity question.
Hero image by Tom Fisk on Pexels.