There’s a lot of ink out there about data leadership.

Much of it reflexively treats headcount as a proxy for capability. Hire early, they say, because it feels safer and shows tangible forward motion. You can point to all the things your data team can deliver as proof of ROI.

I may catch heat here, but I’m not sure that’s always the right approach.

For a lot of smaller and mid-sized enterprises, the right data team may be smaller than leadership might assume. Once you cross a certain threshold, however, running lean becomes far more of a liability – and having watched our law firm scale to over 200 employees, I’ve lived that, although that’s for a different blog post.

I do believe the measure of a data leader should be less of raw headcount, and more of proper headcount. Beyond a certain horizon point, predicting future scale is like predicting the weather at 2pm on a Tuesday six months from now. You might be buying some expensive coats, only to keep them in the closet when the winter never actually got that cold.

I’ve long been an admirer of W. Edwards Deming and the influence his thinking had on Japanese manufacturing, including Toyota and the production systems that eventually became synonymous with lean and just-in-time. And, I believe – up to a certain scale – these frameworks can help data leaders balance the competing staffing needs for their organizations.

Key Person Risk Is Not What You Think It Is

Every conversation about a lean data team arrives at the same objection: what happens if someone critical leaves?

But, I would challenge the assumption that headcount reliably solves this problem. A team of ten still has one person who actually understands why the pipelines were built the way they were. A team of five still has one analyst everyone calls when the numbers stop making sense.

That concentration exists whether the org chart shows it or not, and adding headcount can merely make the dependencies less visible while increasing run rate.

Eliminating key person risk has diminishing returns, so the more appropriate goal is to make it manageable. Engineer enough overlap, documentation, and operational discipline that the business keeps functioning when someone leaves. If you can build that floor, running lean becomes a real option, and it pays off in agility and execution speed that larger teams rarely match.

The goal is to balance the agility of a lean team against the marginal value of adding headcount to reduce that key person risk further. If the answer is substantial payroll, slower decisions, and a more complicated operating model, the trade may not be worth making yet.

Small Teams Need Broad People

A lean model only works when the people on it can operate without heavy specialization. Not going to lie, this is a real constraint.

Early data teams need people who can cross boundaries: understand architecture, work with pipelines, troubleshoot production problems, and talk to the business without routing every question through another specialist.

One person owning orchestration, another owning modeling, another owning BI, and another owning governance looks mature. It can also be incredibly slow, and it creates dependencies on various technical tools and processes before the team is large enough to benefit from them.

So, assuming the talent strategy is workable, the goal is to stay lean and broad longer than feels comfortable, and avoid introducing specialization before the work – or the scale – actually requires it.

Someone Has to Be Watching the Horizon

Lean stops working eventually. The business grows, requests compound, systems multiply, and at some point the team hits a wall it was never built to clear. The key here: That should never be a surprise.

Someone has to be looking far enough ahead to see it coming: the data leader, the CIO, or a VP.

I’m not saying predict the weather at 2pm on a Tuesday six months from now, which is impossible; but someone should be watching the horizon and making reasonable judgment calls. Who owns those calls matters less than making sure someone does.

If the team is already underwater when the first requisition opens, the organization waited too long. Good hiring takes time, and running lean demands more deliberate capacity planning than more mature data organizations might be used to.

What Happens When You Scale Too Early

Most people who work in data do not sit around waiting for work. Hire ahead of the need, and those people will go hunting – and find things to build, usually for perfectly good reasons.

Someone wants a new platform. Someone wants a semantic layer. Someone wants to formalize governance before governance is actually a problem. Someone decides the reporting architecture needs to be replaced. Someone else wants to standardize everything before the company is large enough to have the problem being standardized.

None of those ideas are necessarily wrong, and that is what makes premature scaling an underrated risk. Three years in, and you’ve got six tools, fifteen pipelines, and a bunch of infrastructure the business never really needed – and the floor on the headcount to keep the lights on just went up four flights of stairs.

That is part of the illusion of safety in adding headcount early, and that complexity does not unwind easily. Once people and processes depend on it, it becomes part of the company. Now you need headcount to maintain what you built because you hired the people who built it. The sprawl grows, the ROI shrinks, and eventually someone asks why a team that size cannot move faster – and the data leader realizes, sometimes too late, that they dug themselves into a hole.

When to Scale, and How

The signals are not subtle when the lean operating model reaches its limit. There’s operational demand the team cannot meet, capabilities the business needs that do not exist yet, projects on the horizon that the current structure cannot absorb, or even simply realizing the team is redlining.

When that happens, add coverage before depth. If the team is strong in engineering but thin on analytics, hire analytics. If governance has become an actual operational problem, address it. Scale surface area first: People who can own a functional area end to end, not specialists optimized for a team three times your size.

Also, use the horizontal expansion as an opportunity to bring in some outside perspective. Internal talent knows the company in ways an outsider never will on day one. But external hires bring pattern recognition from organizations that have already been where you are going. They know what breaks first, which problems might actually matter, and how to use tools that you might be growing into.

A growing data organization needs both perspectives.

Stay Small Until the Work Changes

The lean operating model has one other benefit: It forces useful questions. What do we actually need? What is genuinely broken? What has to be built now?

Stay small while those answers are still simple, and of course not so lean that losing someone becomes a crisis. Watch the business closely, and when the work changes, let the team change with it. Scale when the organization earns the need for additional complexity, not before.

The right data team is the one that grows when the business gives it a reason to grow.

–Scott