Why Another Hire Won't Solve Your Data Team Problems

If your data team feels swamped and you're about to open a job req, the problem usually isn't headcount. Feeling overwhelmed and behind is a symptom. Underneath it there's almost always a workflow problem: years of nested logic nobody wants to touch, knowledge stuck in one or two people's heads, inconsistent naming and query design, and ad hoc requests that keep breaking your momentum. A new hire doesn't fix any of that. They inherit it. Map out your current workflow first, and you'll often find more capacity than you expected with the people you already have.

Why feeling behind isn't a hiring problem

A lot of the teams I talk to are convinced they need another person. When we look closer, they don't have too much work so much as unclear priorities and not enough structure to handle the work with the people they have today.

That feeling of being behind is rarely the problem itself. It's a symptom. The work isn't the issue. The way the work gets managed is.

Data teams have a workflow problem, not a people problem

Years ago in a dbt training, I heard that the whole reason dbt was created was that data teams have a workflow problem. That was true then, and it's even more true today.

The appetite for data keeps growing. AI has added a new wave of requests on top of the old ones. If you don't have a good workflow to absorb those requirements, you'll feel overwhelmed no matter how many people you have.

When I look under the hood at teams in this spot, three causes come up over and over.

Nested logic that builds up over years

Nested logic is layer after layer of SQL or models built on top of each other because nobody wants to go back and fix what's underneath. The more you build on it, the harder it is to change.

I'm working through this right now with a manufacturing company. We're rebuilding parts of their data model after years of custom SQL piled up. The first instinct was to add people.

But if we refactor what's there and add some structure, they can move faster with the team they already have. Throwing bodies at the problem isn't the solution.

Tribal knowledge becomes a single point of failure

On smaller teams there's usually one person, maybe two, who has been around for years and built most of the process. A lot of what they know lives only in their heads. That's tribal knowledge.

As a leader it can feel like a sense of control. That person's got it. In technical terms, though, it's a single point of failure. If they leave, the team is exposed.

It also feeds the overwhelm directly. If they're the only one who can take on certain requests, all of that weight lands on them. It becomes a self-reinforcing cycle.

Inconsistent naming and query design

Consistent naming and query design isn't about being nitpicky. It improves your workflow, which means you deliver faster. The small things matter:

• Prefixes that tell you which layer an object lives in
• Directory structure that groups models the same way every time
• Imports at the top of each dbt model, so every table and ref it depends on is visible without scrolling through the query

None of these feels urgent on its own. Over time, the lack of them builds up into an architecture that feels chaotic to work in. I see it every week, and it's worth fixing before you bring someone new into it.

Why ad hoc requests kill your team's momentum

Ad hoc requests come through the front door fast and land on your team's desk. Some of them truly need you to drop everything. That's part of serving the business.

But a lot of them are favors. You're in the middle of building something deliberate, maybe getting facts and dimensions structured, and a request comes in that forces you to rework everything around it. The request itself isn't bad. The interruption is the cost.

The penny that doubles every day

There's an old question in finance. Would you rather have a million dollars today, or a penny that doubles every day for 30 days?

For the first few weeks, the penny looks like nothing. One cent, two, four, eight, sixteen. Meanwhile the million dollars sits right there. By day 30, though, the penny is worth a little over five million dollars, and most of that comes in the last few days.

Interrupt that momentum at any point and you don't just lose a day. You lose the big jumps at the end. Data architecture works the same way. Every interruption costs you the compounding progress of the architecture and the team, plus the time it takes to get back into the flow of what you were doing.

Why saying no earns you respect, not less

Nobody likes saying no, and nobody likes hearing it. There will always be exceptions. But saying no to a request often earns you more respect from the business, not less.

It shows you're protecting what your team is working on. It adds a little friction, so people have to think about whether the request is really worth it before they send it. Over time, that alone cuts down how many ad hoc requests come through.

Treat stakeholders like customers

I like to think of a data team as a small business, and your stakeholders are your customers. There's a saying I like: the customer isn't always right, but they should always feel like they are.

You can listen, understand what they need, and let them know you'll address it. You can still deliver what they want. You just do it in a way that keeps your team aligned with its goals and protects the commitments you've already made.

Why a new hire just inherits the problems you already have

Adding someone to a team in this state scales the problem you already have. The hope is that they'll walk in, figure everything out and save the day. That isn't a fair thing to put on someone, and it rarely gets the results you want.

New people patch, they don't refactor

A new hire doesn't want to come in and rewrite everything in their first month. That's a high risk move, especially if they break something the company already relies on.

So they walk on eggshells. They don't fully understand the code, and they add to it carefully. You get patchwork on top of something that was already complicated.

From the business side it looks like requests are getting fulfilled. Under the hood, the problem is getting worse. You're kicking the can down the road.

What I saw on one team

I joined a team once during a period of management change at the company. People started trying to prove their worth, and that bled into the team's workflow and the requests we took on.

Everything was designed to not break and to keep stakeholders happy. We were in meetings constantly, talking about the work, but rarely building anything foundational. That's not a place you want to bring a new hire into.

And with AI tools, small teams can do more with fewer people than they could a few years ago. You may need to hire eventually. Get your house in order first, so the new person walks into momentum instead of a fire.

What to map out before you post the job listing

Before you decide to grow the team, map out your current workflow from intake to delivery. A few questions to start with:

• Intake. How do requests come in? Is there a formal process, or do people email you and stop by your desk?
• Protocol. When a request shows up, what happens next? Is there a rule for what jumps the queue, or does everything get handled as it arrives?
• Delivery. What's the process from request to finished deliverable, and how much of the middle is automated?
• Interruptions. How many ad hoc requests land in a typical week, and what planned work do they push aside?

Then start paying attention to the ad hoc requests specifically. Build a little bit of a wall around your team's time. Protecting it is how you get the long-term work done, and that's what actually helps the business.

Related reading

• The Art of Data Team Workflows
• Data Team Stakeholders: Friend or Foe?
• The Long-Term Impact of the First Data Team Hire
• Why Bother With Naming Conventions?

Final takeaway

When a team I work with says they need to hire, the first thing I look at is the workflow. More often than not, adding structure gets them further than adding a person, and if they do hire later, that person walks into something they can build on.