In the movie Cars, Lightning McQueen cannot make a left turn on a dirt track because he has only ever raced on asphalt tracks. Doc Hudson offers Lightning the practical advice of "I'll put it simple; if you're going hard enough left, you'll find yourself turning right." Lightning cannot embrace a different paradigm and misinterprets Doc's instructions as "turn right to go left." That's a subtle, but big difference. Lightning tries turning right, and guess what, he goes right. Later in the movie, he learns that he has to first commit to the left turn and then he will find himself turning to the right, which saves him from crashing in the final race of the Piston Cup season.
This sounds a lot like data. In most organizations, the data team and data capability emerge out of IT. The result of this genesis is that data strategies (you shouldn't even have one!), data roadmaps, intake, value proposition, sponsorship, funding, ROI, and more end up being owned by IT. Furthermore, IT thinks it is still racing on the asphalt track of IT projects but data is a dirt track and everything is different. For data to make the turn and keep from crashing, we need to first commit to thinking differently about data and then we will find ourselves successful with data.
Doing the right things with data requires thinking the right things about data, and that in turn will require most organizations to embrace a number of significant paradigm shifts, including:
- How we select people to work on data (part 1 in this series)
- How we approach the IT/technology work for data (part 2)
- How we manage the data we capture and move (part 3), and
- How we start thinking and doing the right things with data (continue reading)
- Not starting small, and
- Not saying "no"
We can see many results from these two mistakes:
- Lots of data in the data lake but users can't find what they need
- Lots of people invited to data governance meetings but limited engagement from them
- Lots of IT projects but our systems still don't talk to each other
- Lots of money being spent on data but no progress toward creating data as a business asset
- Lots of new technology being introduced but our companies are still incredibly hard to do business with
So, how do we make the adjustment to the dirt track of data, especially when we have so much data debt, when there is so much momentum in the opposite direction, when we experienced a previous and very visible failure with data, or when there is so much pent up demand to do more with data faster?
It may seem counterintuitive, but if we want to go big and go fast, we must start small and have the courage to say "no." We need to embrace Doc Hudson's approach to a different way of thinking. The instruction is not "slow down to go fast" or "say no to say yes." The instruction is something like "if you're going slow enough to get data right, you will find yourself delivering more business value faster" and "if you're saying no to enough of the wrong things, you will find yourself saying yes to many more of the right things." Again, that's a subtle, but big difference.
This may sound difficult, however at a very practical level, it is not as hard as it may first seem but it does require a lot of courageous leadership. Here are several practical ways to slow down and say no to get data right, and these can easily be right-sized for your organization's size and level of data maturity:
- Intake -- Funnel all data requests through a single process and a single group of business leaders to align the requests to the customer journey, the business strategy, and the data product roadmap. If alignment is not there, say "no."
- Business Value -- Identify the business value, who owns that value, and how ROI will be measured. If any of these are not or cannot be clearly defined, say "no."
- Data Readiness -- Conduct a quick and easy assessment to determine if the organization is ready for the requested data work. If there is no data readiness and no line of sight to readiness by the end of the project work, say "no."
- Data Governance - Invite those with a direct and vested interest in the approved data work to lead and own the data governance. If someone is not directly involved, say "no."
- Funding -- All data funding must come from the business, not IT budgets or application portfolio budgets. If data is being funded from any source other than the data budget owned by the business, say "no."
- Data Movement -- If the data request involves moving data in a way that is not aligned with the target integration architecture, say "no."
- Data Ownership -- If a data product owner is not identified in the business for every data domain in scope for the data request, say "no."
- Data Security -- If the data is not classified and cannot be kept private and secure, say "no."
Saying "no" does come with a couple of caveats:
- If you have a data product roadmap, saying "no" turns into "not yet," a message that is much better received by the business when we can justify our "not yet" based on an approved roadmap and we can point to the place in the roadmap where their request will be executed.
- If the business value justifies a "yes" answer when everything else points to a "no," then we can make a conscience decision to move ahead with intentionally creating data debt, while at the same time requiring a plan, timeline and budget to retire that data debt before the request is approved.
The value in taking these practical steps includes:
- Clarifying the win up front rather than the data team always playing catch up
- Narrowing the initial focus on what can be done well and what can produce business value
- Thinking in terms of steps toward high-quality, reusable data assets and data maturity, not starting your data journey with large data sets for self-service analytics that ultimately don't get used
- Starting small and celebrating wins publicly and often
- Over time, saying "yes" to many more requests
Lightning McQueen tried turning right to go left; he went right and crashed. However, when he learned to go hard enough left, he found himself turning right and he saved himself from crashing. Likewise, if we simply slow down and say "no," we will slow down, the business will go around the data team, and we will crash again. However, when we learn to lean into the process of slowing down enough to do data right and saying "no" to the wrong things, we will find ourselves going much faster, saying "yes" to a lot more, and saving ourselves from yet another data crash.
Question: What "asphalt track" rules of legacy IT exist in your organization where different "dirt track" rules of data are needed? Leave a comment below.
