Dylan Anderson interviewed 25 data leaders for his newsletter The Data Ecosystem. In his account, the first and biggest anxiety is the data team's weak brand inside its own organization. One leader explained part of the difficulty: "People need to see and hear you. Because people don’t understand this discipline."
The remedy in the piece follows from that diagnosis. If nobody sees the work, make it visible: lunch and learns, town hall presentations, naming wins tied to business results. Anderson describes one leader whose efforts to raise the team's profile helped garner eight internal award nominations in a year.
That is useful advice. But his interviews also suggest that making the work visible needs to be accompanied by a clearer agreement about what the team is expected to deliver.
What the business expects
One leader said it took six or seven years to build trust and visibility, citing the initial lack of management, outputs and direction. That account does not tell us how much better communication might have helped. It does suggest that the work itself and the way it was managed mattered alongside visibility.
Another described being treated as a software, finance and consulting team, expected to deliver across all those functions. Anderson also describes leaders whose plans were disrupted by commitments other executives made and priorities shifted above them.
In those circumstances, asking the data leader to make clearer promises is only part of the answer. The executives requesting the work need to agree on priorities and what can wait. Otherwise, the team could be judged against expectations that change after the work begins.
My reading is that a team's reputation needs an agreed basis for judging delivery. A newsletter can explain a success. It cannot, by itself, establish whether that success met the expectations of the people relying on the team.
Promise first, then publish
The practical version is small. Pick a few things the team will stand behind this quarter and agree them with the business leaders who depend on the work. Write them the way you would write them to a customer.
For example, a team could agree when a revenue table will be refreshed and who will be notified if it is late. Put a name on each side of every commitment, the person responsible for delivery and the person relying on it. Agree which requests will have to wait.
Then use the town hall Anderson recommends to report against those commitments, misses included. Explain changes in scope as well as delivery failures. If an executive redirects the team's capacity, make the effect on earlier commitments explicit.
Anderson reports that foundational work has a better chance of being funded when it is tied to a business outcome. A commitment like this could make that connection concrete: the funding request would explain which agreed service depends on the proposed work. It would still need a business case.
At the next review, show what was agreed, what was delivered and what changed. Give the people relying on the work a chance to say whether it met their needs.
Sources
- Issue #72, Data Leader Therapy (Part 1 - Worries), The Data Ecosystem