3 Strategy Killers for Data Teams

The three things most likely to kill a data strategy are too much tribal knowledge, never making time to refactor, and migrating bad code into new tools. None of them come from bad intentions. They come from the normal pressure of shipping, and they quietly undo months of planning and budget. Tribal knowledge concentrates the architecture in a few heads. Skipping refactoring leaves every first draft running forever. Lift and shift migrations move the problem into a faster engine and call it modernization. Over the past decade of working with data teams, these are the three I see derail projects most often.

Strategy killer 1: Too much tribal knowledge

This one is not specific to data. It shows up in companies generally, and data teams are just an unusually concentrated version of it.

Tribal knowledge is what the people who have been somewhere a long time understand among themselves. They know what the rules are and what a field represents, and none of it is written down.

Why it hurts a data architecture

You can never fully avoid it. It is part of any culture and any group of people who work together long enough.

The damage shows up at the edges of the team. Onboard a new person, or explain something to someone outside the group, and you look unorganized and unprepared.

The signs to look for

• Information stuck with one or two people. Nobody else quite understands it, and it never gets written down.
• A single person everyone has to ask. They have been around long enough to understand the context better than anyone else.
• Answers that start with history. The explanation depends on something that happened years ago and was never documented.

What happens when that person leaves

Picture the original architect of the whole system walking out the door. If the design lived mainly in their head, you are now picking up the pieces.

New people arrive and do not want to break anything, because they do not understand what was built or why. So they build on top of it instead.

That patchwork grows until the only remaining option is to start over and do all the work again. I have run into this more than once, as an employee and as a consultant.

The fix is unglamorous

Document it. It is not a fun process, and it is obvious advice that teams still skip.

Take a moment to look at how much of your architecture is held between one or two individuals. Share the wealth, get it written down, and the whole team moves faster.

Strategy killer 2: Never spending time on refactoring

In the normal cadence of work this is genuinely hard to do. There is always new work, and nobody is asking you to revisit the old work.

So what happens in data, and in development generally, is that you build fast and never go back. The thing stays there and keeps running in perpetuity.

Nothing is right the first time

Sometimes leaving it alone is fine. More often there are areas you could meaningfully improve, because the team understands the problem better now than it did then.

First drafts are rarely perfect, or at least it is very rare. Treating them as permanent is the mistake.

Put it on the calendar

The approach that works is allocating time deliberately. That might be a dedicated sprint, or a block once a month or once a quarter.

The point is that it is scheduled. Time set aside to revisit things you know are not right but never have room to fix.

Making the business case

The pushback is predictable. The business wants outputs and reports, and does not want to be slowed down for work that means nothing to them.

So translate it into their terms. Refactoring can make their deliverables more performant, let the system take on new data, or unlock things it could not do before.

Cost is the strongest version of the argument. A long running, inefficient query fixed in an afternoon turns into real money saved, and that saving compounds for as long as the fix holds.

This is easier said than done. But a strategy that is never revisited scales badly, and the alternative is a slower death by things that were never optimized.

Strategy killer 3: Migrating bad code

The third one shows up most during a migration or an architecture revamp, which is exactly when teams are most hopeful.

It usually goes like this. You bring in new tools and new workflows, then copy and paste what you had before into them and hope the problems come along for the ride and disappear.

A faster engine is not a fix

A new database with a better query engine will run your old logic faster. That is real, and it is also not the same as fixing anything.

The same happens between transformation tools. Stored procedure code gets pasted across because nobody wants to stop and rethink the strategy.

The question that gets skipped is whether the warehousing and the modeling were right in the first place, or whether they should look different going forward.

The attention goes to the wrong place

Focus lands on lifting and shifting the tooling rather than on the code and the logic underneath it. The project gets measured by whether the new tool is live, not by whether the output got better.

Meanwhile a migration is one of the few moments when you have permission, budget and attention all at once. It is a very good opportunity to actually think about your strategy.

The two kinds of migration

I have worked with clients who are fully aware of this. They are willing to change their modeling or their workflow if it makes more sense with the architecture they are moving toward.

And I have worked with teams on such a time crunch that they copy and paste. When I walk away from those projects, I already know how it ends.

Sometimes other factors force your hand and you simply have to get it done. If you can see it happening though, it is worth reconsidering while you still have the chance.

Related reading

• Avoid These 5 Costly Mistakes (as a small data team)
• The Modern Data Viewpoint (3 Principles)
• Data Architecture 101: The 5 Key Questions
• The Gift & Curse of Small Data Teams

Final takeaway

Across a decade of client projects, the teams that stall are almost never the ones with the wrong tools. They are the ones carrying knowledge in their heads, never going back, and moving old logic forward unchanged. Fixing any one of those three changes the trajectory of the whole strategy.