I’ve been writing on A14K about what remains of a data team’s role when AI can produce much of the visible output. The short version is that the responsibilities don’t disappear just because the queries and charts get easier to make.
That leaves a rather awkward question about team size.
If an analyst can produce twice as much analysis, should you need half as many analysts? If the rest of the organisation can make its own dashboards, how much of the data team should still be there?
I don’t think the number of charts or queries gets us very far. My working theory is that, as more production is automated, analytical headcount will be driven much more by the number of spheres of context the organisation needs people to understand and help steer.
I’m deliberately calling this a working theory. I don’t have a neat ratio to offer, and would be fairly suspicious of one. But I think it’s a more useful place to start a conversation than dividing the backlog by a new estimate of how quickly Claude can write SQL.
What I mean by a sphere of context#
There are parts of a business you can understand well enough to be genuinely helpful without being briefed from scratch every time.
You know what the team is trying to achieve, how the operation works and which measures are useful. You remember why an earlier initiative was abandoned, which assumption keeps causing trouble, and what changed last month that makes the apparently obvious comparison misleading.
You also know the people. You have some understanding of what matters to them, how they make decisions, and where their objectives conflict. There’s enough trust for someone to tell you that the official project description isn’t quite the problem they actually need help with.
That’s the combination I’m calling a sphere of context: a reasonably coherent set of business questions, decisions, history and relationships which someone can remain meaningfully close to.
Part of that can be written down, and should be. Part of it involves noticing what’s changing and knowing when to ask another question. Maintaining it requires attention over time.
This is close to the work I described in Managing Data Stakeholders . The difficult part was understanding what people needed, negotiating priorities and making sure the work actually had an effect. Faster query writing helps with that job, but it doesn’t describe the whole job.
Two businesses with very different needs#
Imagine one business with a single product, a relatively stable operating model and a small leadership team. It might generate an enormous amount of data. It might also need thousands of calculations or charts to support the decisions it makes.
If the questions are closely related and the goals are reasonably aligned, a small number of people could understand a great deal of what’s going on. With good automation and reliable foundations, they might support a very large quantity of analytical work.
Now imagine a business generating less data but working on several quite different things. There are distinct products, a new market launch, an operational change and a partnership with its own commercial arrangements. Different people lead those initiatives, and the assumptions and priorities are moving around in each of them.
The individual analyses might be quite simple. What makes supporting the business difficult is keeping enough understanding of each situation to know which analysis matters, what the result means and what needs to happen around it.
One person could be very productive and still struggle to do that well. They might deliver every requested chart while missing the conversation that would have revealed the team was solving the wrong problem.
In that situation, another analyst could add value through sustained attention to one of those areas. Their value wouldn’t depend on taking half the charts off the first person’s hands.
Those spheres don’t follow the organisation chart#
It would be convenient if this meant one analyst per department. I don’t think it does.
A retention initiative could bring together marketing, operations, finance and customer service. The useful context might be the initiative itself: how those groups interact, where the constraints sit and how its success will be measured. Splitting the analysis neatly by department could make the coordination worse.
Conversely, one department might be running several initiatives with very different customers, operating models and decision-makers. A single box on the organisation chart doesn’t guarantee that it’s one manageable area of context.
Nor is stakeholder count a staffing formula. Several people working towards one stable objective may be easier to support than two people with strongly conflicting goals and a rapidly changing plan.
The useful question is how much of the business someone can remain close enough to understand and influence. That will depend on their experience, the pace of change, the consequences of the decisions and how the organisation works together.
This is also why I keep returning to the subjective part of analysis . Knowing the likely outcome of an action doesn’t tell you how different people value that outcome, or what they are prepared to give up to get it. You need to understand those views to help people make the decision.
Doesn’t AI let one person hold more context?#
Yes. And there’s a more immediate effect which I think is worth being explicit about: AI changes how many people you need within a sphere.
A group which previously needed several people to investigate questions, write queries, build reporting and prepare recommendations may be able to support that work with far fewer. For many organisations, I think one experienced person could take primary responsibility for a sphere, using AI to do much of the production around them.
That’s one person carrying the context and relationships, potentially with juniors learning alongside them. They would still draw on shared technical foundations, specialist help and appropriate review. I’m not suggesting that one person must build, check and maintain everything alone, but the reduction in staffing could be substantial.
What AI doesn’t do is make the underlying spheres disappear. Making the analysis for a new market easier doesn’t remove the need to understand that market, its operation and the people making decisions about it.
Those are two different quantities: how many people you need to support one sphere, and how many spheres the organisation needs to steer. AI can reduce the first without reducing the second.
It can also help the person carrying that context. Retrieving earlier decisions, summarising discussions and finding the relevant documentation can all make it easier to stay close to the work. That might let someone support several closely related areas. One person per sphere is a useful possibility to consider, rather than a universal staffing ratio.
The organisation may have more going on at once#
There’s a possible twist here. The rest of the organisation gets access to these tools too.
If product teams can build faster, marketing can run more experiments and operations can explore changes more easily, the business may be able to pursue more things concurrently. An initiative which would previously have waited for capacity might now get started.
Some of those initiatives will fit within context someone already holds. Others will introduce a new set of customers, relationships, assumptions or operating constraints that someone needs to get their head around.
So AI could reduce the people needed within each sphere while increasing the number of spheres which are active at the same time. That’s why I would be wary of turning a productivity improvement into an immediate prediction about total headcount.
It doesn’t mean that every new initiative deserves an analyst. A business can make itself very busy with things that aren’t especially important. The ability to start more work makes choosing what deserves sustained attention even more necessary.
Start with what the business needs to get right#
I think planning team size starts with identifying the core processes the organisation needs to run well and its main priorities for change. How does it acquire and keep customers, deliver its product or service, and manage its money? Which plans depend on decisions that need sustained analytical involvement?
Those are the areas around which I’d identify the important spheres of context. Some may work well with shared measures, AI-assisted self-service and occasional advice. Others need someone staying close to the people and decisions. Existing dashboards and longstanding requests aren’t a permanent claim on that attention; some commitments should stop so more important work can be supported properly.
Then ask who can carry that context and what support they need. Often, that may be one experienced analyst with AI and good shared infrastructure. It could also be someone already in the business team. More complicated areas may need specialist help, and keeping the data infrastructure reliable remains a separate part of the staffing question.
The test is whether the important areas are actually being understood and steered. If analysis arrives but the decisions still stall, producing more of it won’t necessarily help. That’s the problem in why analysis can get faster without decisions getting faster .
Keep the spheres connected through common definitions and shared foundations, but build the team around what the business most needs to get right. You don’t have to preserve every area of support that happens to exist today.
Where juniors fit into this#
There’s a shorter piece on A14K about whether it still makes sense to hire junior analysts . The apprenticeship model in that article fits alongside the idea of one experienced person taking responsibility for a sphere.
A junior can take on a smaller part of that context with support. They can get to know a team, investigate a recurring question and participate in the discussions about what the result means. The experienced analyst helps them review the work, understand the relationships and learn what to try next.
They aren’t simply extra production capacity for queries that AI could write. They’re developing the ability to take responsibility for more of the business over time. AI may let them reach the organisational parts of that learning earlier.
That still needs time for mentoring and review. Counting an experienced analyst and a junior as two independent spheres of coverage from the day the junior joins would rather miss the point of the arrangement.
What I’d do differently#
Reading back through Growing Business Analytics on a Shoestring , I’m struck by how much of the story is about the organisation becoming harder to keep in one person’s head. The tooling matters, but so does the move from a few people who all know what’s happening to groups with different work, knowledge and priorities.
The mistake I’d try to avoid now is treating faster production as permission to give everyone more projects. It’s quite possible to fill the time saved on charts until nobody has time to understand the decisions behind them. I’d want the productivity gain to buy more meaningful involvement in the work that matters.
So would I expect smaller teams?#
I’d expect fewer people to support the same set of spheres. I wouldn’t assume the business itself stands still: AI may let it pursue more important work at once, increasing the number of active spheres even as staffing within each falls.
Those two changes can pull total headcount in different directions. I suspect the net effect will still be downward pressure on team sizes over time, but I don’t think data teams will disappear entirely. Only time will tell… 🤔
