In 2015, retired US Army General Stanley McChrystal wrote one of the best books on data: Team of Teams. The word data governance is not mentioned once in the book, but the problems the general was facing when taking command of the Joint Special Operations Task Force (JSOC) in 2003 were very much data governance problems.
The first issue was that JSOC had too much data. It came in raid after raid and piled up and expired before any of the stakeholders could look at it.
The second problem was collaboration. It took too long for any of the teams that are part of, or work with, the JSOC to actually look at the data, disseminate it, and share its insights back to the rest of the force. This lack of collaboration happened mostly because within each silo, there’s a chain of command the information needs to flow through before it can leave to other parties. If they released it at all!
Sound familiar? The above problem is one most organizations face. But they can’t afford to anymore because a competitor that reacts faster based on new data will win in a digital world.
That’s why some of the best companies in the world are adopting some of the lessons learned in Iraq . And you should consider applying them, too.
General McChrystal’s solution was unconventional and brilliant. He moved from the century-old command structure to a team of teams. We won’t cover all insights of the book, nor is this a book review, but the most important data related lessons are:
- Foster trust between silos by embedding (on a rotation basis) the best people in other teams
- Create liaison officers (again, the best people) to learn and work with other teams
- Create an extremely open culture about data. This was achieved by opening up all conference calls for all teams so they could share information instantly.
Although reluctant at first, all stakeholders that worked with the JSOC started to see the benefits. And after a while, they started to share information themselves rather than just listen in. Once they established trust between the teams, data flowed faster and to the right channels. And this meant they could deliver crucial pieces of intel to the right team on time rather than expiring on a pile.
Data-driven business worldwide have since applied the lessons and concepts that the book outlines. If a strategy of inclusiveness and adaptability is good enough to beat Al Qaida in Iraq, it must be good enough to beat the agile competitor you are facing.
So what can we – the data citizens – learn from this and how do we apply it in our daily data governance operations?
The biggest lesson of all is that Big Data will not save us.
As the general writes: “attacking complexity with big data will result in failure. It’s obvious to those on the receiving end of a big data fire hose that absent an ability to discern and apply useful patterns, data leads to just more noise. And it can be deafening.”
He goes on to say “Complexity undercuts the promise of big data because data, like other elements in a complex system, is interdependent. And this interdependence makes it virtually useless for purposes of prediction.”
“Gaining understanding is not always the same as predicting … . In a simpler world, our leaps in data would have been of great predictive value, but the reality of increased complexity meant that when it came to foresight, we were essentially chasing our own tail — and it was getting away from us … . We have moved from data-poor but fairly predictable settings to data-rich, uncertain ones.”
It was not the gathering of more data that made the efforts in Iraq successful. Rather, it was the collaboration that happened around and with the data.
Key Takeaways to Apply to Our Everyday Business Lives
First, allow stakeholders from other teams to work directly with you. Let other teams in on viewing your data assets and the collaboration on it, even if its data that only exists in your silo. You might not see interconnectedness that an external team member does.
Second, to establish trust, consider embedding a staff member from another team in your team, ideally on a rotation basis. For example, someone writing technical data quality rules in IDQ could switch places for a month with someone who writes data policies for the business. They would gain a lot of insight on why or how policies and data quality rules are built and trust between the teams would follow. Later, when the team members are back at their regular positions, they still have the connections and insights of the other teams which they can leverage to solve issues faster and in a more agile way.
“The Task Force still had ranks and each member was still assigned a particular team and sub-sub-command, but we all understood that we were not part of a network; when we visualized our own force on the whiteboards, it took the form of webs and nodes, not tiers and silos” (p. 251).
Third, open up your metadata. Often, clients ask me whether it’s possible to have restricted views on data assets for the wider audience. Many times, this is to hide communication on issues or less than expected data quality. The opposite should be the goal. Share all info, relations, issues, and logs with the whole organization. If data quality of a certain feed is bad, let everyone know it rather than hide it. And show how you are resolving it. You’d be surprised who gives tips or who faced the same problems before.
“- using “cc” line of e-mails liberally “whenever it seemed that even the second- or third-order consequence of the operation discussed might impact them” (p. 163)
“…taking lots of calls on speakerphone–even when it made others uncomfortable or surprised them (p. 163)”
Finally, as a Chief Data Office team, you don’t need to be involved in every decision and seek to wield more and more authority. Powerful leadership also comes from enabling others. Many data governance programs initially failed because the central Data Governance Councils sat in an ivory tower, trying to get control over all decisions on data.
The goal should be for the council or CDO team to create the right data culture under which the silos can thrive.
To use General McChrystal’s analogy, the CDO needs to be a gardener:
“If the garden is well organized and adequately maintained, and the vegetables are promptly harvested when ripe, the product is pretty impressive. The gardener creates an environment in which the plants can flourish. The work done up front, and vigilant maintenance, allow the plants to grow individually, all at the same time…I began to view effective leadership in the new environment as more akin to gardening than chess…nurturing the organization…to enable the subordinate components to function with ‘smart autonomy’…as in a garden, the outcome was less dependent on the initial planting than on consistent maintenance. Watering, weeding, and protecting plants from rabbits and disease are essential for success. The gardener cannot actually ‘grow’ tomatoes, squash, or beans–she can only foster an environment in which the plants do so…Creating and maintaining the teamwork conditions we needed–tending the garden–became my primary responsibility…I found that only the senior leader could drive the operating rhythm, transparency, and cross-functional cooperation we needed. I could shape the culture and demand the ongoing conversation that shared consciousness required” (p. 225-226).
The worst thing a data driven company could do is create a vertical solution for a horizontal problem: the Chief Data Office as a silo. Rather, a team of teams approach on top of a federated governance structure, can help break down silos, improve the speed of change, and re-build the trust that all data-citizens must have to truly turn analytics into action fast.
