Headcount is not capability
You can assemble a talented data team and still produce nothing that matters. The org chart fills, the tooling arrives, the salaries are paid, and the business cannot point to a single decision that changed because the team exists. This is uncomfortable to say to a room that has just spent eighteen months hiring, but the problem is almost never the people. It is how the team is wired into the organisation around it.
Headcount is the easiest part of building a data function and the most often mistaken for the whole of it. A team’s capability is not the sum of its CVs. It is the rate at which it turns questions into decisions the business acts on. A small team coupled tightly to real decisions will out-deliver a large team producing technically excellent work that no one consumes. The second team is not under-resourced. It is mis-wired, and adding people makes the wiring worse, not better.
What a delivering team has that a stalled one does not
The clearest marker is proximity to the decision. Delivering teams sit close to the people who actually decide, so they understand the decision, its constraints, and its timing. The shift this produces is in what gets asked, not in what gets built. An analyst who sits in the room where the call is made stops answering the most interesting question and starts answering the one the decision actually turns on. The work often gets smaller and considerably more useful. Distance breeds the opposite: analysis produced in isolation answers the analyst’s question rather than the decider’s, and arrives too late to matter even when it is right.
The second marker is where the team puts the finish line. On a stalled team, “done” means the analysis is finished. On a delivering team, “done” means the decision was made and the outcome is being tracked. That single difference reorganises everything else the team does, because it makes the analyst responsible for being understood and used, not just for being correct. It is the team-level version of the decision-system problem.
The third is leadership, by which I mean translation more than seniority. A data team’s lead is a translator before they are a technologist, turning business ambiguity into answerable questions and analytical findings into language that moves a decision. Without someone who can stand credibly in both rooms, the best analysis dies on the way out of the data team.
You design delivery in, you do not hope for it
Delivery is a property you build deliberately, not a culture you wait for. It means defining the team around the decisions it serves rather than the technologies it runs, hiring for proximity and translation alongside technical skill, and building local capability that lasts after the engagement ends. This is the logic behind our embedded model, and it is also how we think about building practices for African realities. We place people inside the client - the Boots - and have them build the client’s own capability while they deliver. Our own measure of a job done well runs slightly against our short-term interest: can the client run it without us once we leave? We build for that on purpose, pairing on the work rather than doing it behind a curtain, and handing over the reasoning rather than only the dashboard. A dependency is easy to create and is a poor compliment to pay a client. Data culture, in the end, is just the residue of this done consistently. It is what is left in the business after the work, not a value painted on a wall.
Key takeaways
- Capability is the rate of turning questions into acted-on decisions, not headcount or tooling.
- Delivering teams sit close to the decision, define “done” as the decision made, and are led by translators.
- A small team close to decisions beats a large team producing work no one uses.
- Data culture is the residue of delivery done consistently, which is why we build client capability as we deliver rather than create dependency.