Tackling Sensitivities in Centralized Data Management

Lessons from the trenches

Photo by Jehyun Sung through Unsplash.

Most organizations of a given size and age have by now kicked off an initiative to enhance the way they treat and manage data. Any attempt to structurally enhance data management capabilities will require a minimum amount of centralization, if only to discover the current state practice across the organization. A common trend is to name a Chief Data Officer, with a survey finding that >80% of Fortune 1000 organizations now report to have a CDO in place.

Any change can trigger a reaction, but specifically organizational change that defines new responsibilities, changes authorities, and requires funding might be sensitive and therefore tricky. I’ve spent over a decade accompanying emerging Chief Data Officers on their respective journeys. I have the battle scars to show for it, but also a few lessons learned. In the remainder of this article, we’ll review the typical challenges that accompany the launch of a central data team as well as the practical actions you can take to manage these risks.

Launching a central data team and related sensitivities

Creating an initial central team and centralizing responsibilities can be done in many different ways. It may include the launch of a Chief Data Office, kick-off of a data (governance) council, enhancements in centrally driven policies and standards, and centrally provided resources to execute specific data governance processes.

As a central data team gains authority, by definition other teams must be ceding it — and that can come with sensitivities. The following are some of the most common challenges:

• Fight over resources. Central teams need people and budget to function. Sometimes, this can mean taking away from the budgets or people of other teams, which can trigger a reaction by these teams’ leaders.
• Loss of control. Teams that used to have freedom over certain tasks may not like having a central team take over, or providing standards around how to do it.
• Lack of local relevance. If the central team is too detached from local (or business-specific) needs, operations, and nuances, they may make decisions that don’t result in desired business impact, and local expertise may be lost.
• Becoming a bottleneck. The potential for the central team to become a bottleneck or a point of friction in the organization, if it is not staffed and managed appropriately, and therefore it becomes a source of frustration and resentment.
• Becoming a dumping ground. The potential for the central team to become a dumping ground for tasks and responsibilities that nobody else wants to take on and that drive only limited value.
• General resistance to change. Teams and individuals may be resistant to change, specifically if the impact is unknown or badly understood, and if they feel unequipped to live up to new expectations.

Let’s review a few real-life case studies related to these challenges, which I have witnessed up close. In the first case, the strategy of the organization, a global top 100 insurance organization with over 50k employees, was very aggressive. The newly incoming CDO had a history of “getting it done,” which had been part of the reason behind his appointment. His plan was to define a list of activities that were classified as “data governance activities.” Then, with the descriptions in hand, people were identified across the organization that were already executing such activities, initially under the guise of assessing the current state. Of the people that ended up being identified, sometimes data governance made up their entire job, and sometimes only a small part. For example, someone could be doing data quality work as part of a marketing pipeline process.

Once the analysis was completed to identify these people, the proposal was made to move a substantial share of these people into the central team. Of course, this led to instantaneous revolt by business and functional teams where these people were positioned. They had shown goodwill by participating in the maturity assessment, only to see their team members, often critical components of their respective operations, being reassigned. The new CDO quickly found himself in a hostile situation and achieved virtually nothing for the remainder of the first year.

Another case study comes from a global bank, where the global Chief Data and Analytics Officer (“CDAO”) launched a transformation program to created a curated data lake. The CDAO was wary of creating a data swamp, so she insisted on a strict certification process. The promises of the program were strong — teams could submit requests to upload their data into the lake, and a central team under the CDAO would take care of its ingestion, labeling, and quality control, as well as access provisioning, so that business and functional teams could focus on analyzing the data and building analytical models. However, demand soon exceeded capacity and the average processing time to get data into the lake surpassed 1 month on average, and business teams grew frustrated as the central data team became a bottle neck. Despite good intentions, a major reset was needed (where my team — coming in as the above-described situation worsened — helped with analyzing tooling that could automated data governance processes in the ingestion pipelines).

The examples above come from my personal experience, but for those interested in more, Creating a Data-Driven Enterprise with DataOps by Ashish Thusoo and Joydeep Sen Sarma provides for some excellent reading with additional case studies.

Mitigation tactics

Image by the author.

Organizations can employ various measures to manage the sensitivities associated with centralized data management. Here are some of my personal favorites:

• Focus on automation. By adopting an automation-first mindset, manual effort and costs can be reduced, thereby shrinking the need for a large team. Data governance by design, where governance principles are embedded in the design of data systems, can promote consistency and efficiency.
• Communication and transparency. Clear and timely communication about the reasons for centralization and its expected outcomes can foster trust and encourage buy-in from stakeholders.
• Guidance and training. Any new or updated process or policy should be paired with fit-for-purpose educational materials and socialization processes that clarify their implementation.
• Provide avenues for feedback and influence. A data council or governance forum can be used to ensure that stakeholders are not just at the receiving end of data governance guidelines and instead are active and appreciated partners in the journey.
• Proactively address tough stakeholders. Identify stakeholders that may have specific concerns or objections, and address them proactively, where possible including 1:1 sessions and explicitly managing respective needs and demands.
• Start small and put a win on the board. Start with a scope that is well-understood, has relatively “friendly faces” involved, and comes with a clear business case. This can create initial momentum, which may be needed to tackle more complex topics later on.
• Empower local teams and managers. Intelligent data governance is not about centralizing all the work — it enables existing roles and people to better live up to their responsibilities in a consistent way. Cross-functional and cross–regional teams may be an option.
• Only centralize where needed. Ensure efforts to standardize or centralize data governance are based on a positive business case. Avoid centralization when unsure.

Let’s review a few additional case studies from my personal observation. First, to avoid bloody fights over resources, a large regional retailer used a targeted, use case-driven approach, analyzing resourcing needs and gaps based on a common set of ~25 data roles. These roles included personas like data owner, data steward, data modeler, data scientist, data engineer, system owner, process owner, domain data steward, data architecture, and a few more. The next step involved discussing these roles with business and functional teams, identifying which roles they already had and where they faced challenges, for example in terms of having the right expertise and technology. When common pain points and opportunity areas were identified where a central team could effectively supercharge business and functional teams, this was immediately welcomed. The completion of the business case to get the initial, albeit small, team funded was quick and easy.

With another Chief Data Officer that I worked with, we deployed a data literacy and culture campaign alongside the launch of her new data governance operating model. The new operating model came with a lot of new terminology and responsibilities that were new for the employees, and we believed that this could cause confusion and anxiety. Among other initiatives, we organized an “Ask me Anything” session, where anyone in the organization — which counted well over 25k employees — could anonymously submit questions that would be answered live. In addition to many practical ones, a lot of sensitive questions were asked, such as “How do these new responsibilities impact what I get paid?”, “This is the 3rd new operating model in 3 years — do we really need another?”, and “My team leader thinks this is nonsense — what can I do about this?” Anonymously collected feedback afterwards in combination with anecdotal comments indicated that this transparent approach alleviated personally felt concerns and encouraged buy-in across those people that were impacted by the revamped responsibilities.

A final example, and perhaps my favorite case study, is where the revamped Chief Data Office adopted an automation-first mindset. A reference architecture for a newly implemented cloud-native data platform was created with a few enabling foundations: a data product approach, strict interoperability standards, and a data management hub. This meant that anything that was moved onto the platform by definition was automatically governed. That is, only what qualified as a data product was allowed to be stored on the platform, ensuring that (product and data) ownership was defined. The combination of interoperability standards, the common storage patterns inside the platform, and the data management hub (which included a data catalog) drove nearly fully automated metadata management. Although this did come with a substantial upfront investment to get the foundations right, it avoided a situation where the central data platform team needed a large number of analysts and engineers to operate the platforms and its data products.

Looking ahead

Centralizing data management is not a straightforward task; it’s fraught with complexities and sensitivities. However, through effective communication, stakeholder engagement, focused training, and a measured approach, only centralizing where there is a clear business case to do so, these challenges can be managed effectively. If you have any insights or experiences to contribute, please share them in the comments.

References

• Three underappreciated success factors of Chief Data Officers, Medium.
• 8 Strategies for Chief Data Officers to Create — and Demonstrate — Value, HBR.
• 5 lessons from a three-time Chief Data Officer, Data World.
• Creating a Data-Driven Enterprise with DataOps, Ashish Thusoo and Joydeep Sen Sarma.