The four failures that kill data teams

Data teams rarely fail on technology. They fail on four things, and I have yet to meet a struggling function that was not losing to at least two of them at once.

Reactive order-taking. The team exists to answer requests. Whoever shouts loudest gets served, priorities are set by proximity to the requester, and nobody can say what the function is actually for. The tell is a backlog measured in tickets rather than outcomes.

Siloed execution. Two teams build the same thing, differently, six weeks apart, and neither finds out. Every silo is a small duplicated cost that compounds quietly until someone runs the numbers.

No accountability. Everyone is responsible for data quality, which means nobody is. The business believes the data team owns it. The data team believes the business owns it. Both are half right, which is the worst possible arrangement.

Inconsistent quality. Two analysts, two answers, one board meeting. Once that has happened in front of an executive committee, you are no longer arguing about data. You are arguing about trust, and that is a much longer conversation.

I named these four in the second version of a playbook I wrote, after the first version met reality and lost a few arguments. The fix is not a tool. It is an operating model with explicit accountability on both sides, written down, and a way of working that people were told about before it took effect.

The uncomfortable part is that all four are leadership problems wearing a technical costume.