How design thinking solves the 3 hardest problems for chief data officers

Original Source Here

How design thinking solves the 3 hardest problems for chief data officers

Design thinking plays an essential role in this roadmap on how to address the 3 hardest problems for chief data officers.

By sebastiaan stam from Unsplash

I operated some of the most challenging data analytics landscapes, and I am grateful for those experiences.

Namely, early on in my career, I saw exceptional chief information officers struggle landing on their feet, trying to pioneer novelties in how to capture value across the data use cases.

At the time I began working in information technology in 2011, the formal implementation of a data officer did not exist in the federal government. Fast forward to several years ago, after series of legislative changes across the federal government in the United States, we transitioned from operating under myriad of decentralized analytics cells to celebrating the arrival of the first Chief Data Officer. Again, we are talking about the U.S. federal government, not the private sector and other industries.

Even prior to 2019 (when the data officer function really accelerated for adoption and implementation), the role itself had always existed, whether it be through leadership cells embedded across information officers, information security officers, governance specialists, even cloud architects. I saw and experienced just about everyone, who touched analytics in some shape, to play a role in the advancement of data.

At the time previously when I was overseeing the strategy and management of a 9-digit cost program, I personally wrestled unceasingly with three distinct areas, requiring an unending and dutiful effort to master:

How might we (1) guarantee that data is high quality; (2) govern the organization’s data; and (3) find the gold nuggets: the most important user/business problems that needed to be answered?

Before I unravel what worked for me — my big three hardest problems, here is my personal definition of a chief data officer.

A chief data officer is a leader in the organization who oversees the strategic planning of the data. They sit in a leadership role: they have official and direct authority to issue mandates. In the U.S. federal government, the mandates are — at a minimum — delivered as policies. Also, chief data officers are the most senior ranking member of the leadership team with that title; in other words, they are the key subject matter expert responsible as the chief data officer of that organization.

How might we guarantee that data is high quality?

Focusing on guarantees, I found equate to the same challenges that imply no go-to-mark launch is permissible without a complete product.

There are no products that are complete, as all products are prototypes “that can be tested further” (through back and forth iteration, as stated by Shamsi Brinn) [8]; they remain under continuous quantitative analysis, like using methods based on A/B testing [2].

Similarly, no data is ever 100% complete; rather, what worked for me is data engineering for working towards a high-quality data ecosystem.

Data engineers know how to build data-centric pipeline because they are intensely focused on building optimizations, whether it is to find efficiencies in how to extract, integrate, or transform data. The engineers will lead all your production challenges. You own the work, and data engineers have the expertise to own the how.

It worked for me, relying on their proficiencies. If I could go back and do it all over again, I would have prioritized the hiring and activation of data engineers well before architects, scientists, and other specialists.

How do we govern the organization’s data?

I found this to be easier than the other two. There are many learnings from data science life cycles that can be associated with data governance. I clarify governance as the orchestration cell to the organization’s data DNA.

Fundamentally, everyone needs to be able to state or clarify the happenings from data: what happened, how so, and why [3]?

Consider building a functional program made of up human-centered designers, data engineers [6], machine learning architects, data scientists, product managers, and risk managers. The term “manager” does not always mean or imply supervision; rather, it is the responsibility to manage that domain (with an expectation of taking the deliberate step to deeply understand the team’s motivations [4]).

By Suelyn Yu, Published in UX Collective, Found Here [5]

The tire hits the pavement in this organizational setup. We work across the more procedural matters, like information security (privacy), compliance (against internal policies and macro legal mandates), and cost-management (pay as you go models, in-house vs. outsourced tools). You will find yourself developing clear policies and procedures, and moving beyond establishing monitoring mechanisms to ensure compliance with those policies.

All problems are solved through a user-centric, design thinking approach.

The most important: how can we find use cases?

I identify use cases, indebted to successes based on pursuing an entire journey mapping approach through design thinking to unhinge the “pain points” [9], especially using methods clarified by Illai Gescheit, and bright spots, and I prioritize them according to the shalls, or “what shall we do” such that it must be accepted as a use case (think of MoSCoW [1]: the must-have, should-have, could-have, will not have).

The approach through design thinking is a start and does not have to get to an exceptionally sound process to doing it correctly.

There is no right way to understand those use cases other than to take them through a user-centric process, gather the needs of the users, and decide if they are viable use cases for acceptable operationalization.

No different than productization but narrow to data officership. Operationalization here is in the context of accepting those use cases, leading to the expectation that we corral the organization to support their operationalization. One use case, for instance, could cost the organization 100s of millions of dollars to bring to market, from inception to launch.

A simple start is to establish an intake process. Inform the organization that you are collecting information about use cases according to management of data. This approach taken does not have to be punitive or mandatory. In my experience, the organic start is the best start. Those who come forward first have shown some of the strongest interest in willingness and desire to partner.

Think about building or empowering your design thinking team. Human-centered designers understand how to explore learnings and user experiences.

Beyond these three problems, the chief data officer may find themselves conducting exceedingly large number of social engagements across their organization for buy-in. This is normal, largely due to the role being new, even across its acceptance in just about any industry. The “officership” context of data is not necessarily as easily understood as the scientific management of it, like conducting machine learning, natural language processing, or deep learning procedures to solve for use cases.

Finally, I envision a future where design thinking and data will be consolidated into a set of variables that inform learning, stated exceptionally well by Penelope regarding “product peer reviews” [7].

To be a leader in data, you may need to understand design, not just itemized orchestrations across engineering, the cloud, architecture, and risk. Perhaps, a background well defined in design thinking may even become a requisite in data officership roles.


Trending AI/ML Article Identified & Digested via Granola by Ramsey Elbasheer; a Machine-Driven RSS Bot

%d bloggers like this: