Any sufficiently advanced technology is indistinguishable from magic.
-Arthur C. Clarke
I empathize with the frustrations many CIOs experience as the latest fad hits their desks. From nowhere a demand pops up that a particular technology is urgently needed to modernize their company. The problem to solve is fuzzy, and desired outcomes unclear. I recall a skit from a peer at a team event years ago. In it he emulated one of those executives we’ve all met who, after leaving a long flight, rushes into the office and declares that “technology X,” featured in an in-flight magazine, is exactly what our company needs. It was one reason a favorite retort of mine became, “Thank you for the solution, now what was the problem?” when confronted with this behavior. It’s the silver bullet syndrome at its finest: a desire to be cutting edge without fully understanding the underlying problem or complexity.
Silver bullet syndrome is compounded by the irrational publicity and inflated market capitalizations that often occur at the mere whiff of new technology. Data is an example of a technology area subjected to this trend. A recent article on a food service company led with the headline, “Company X isn’t in the food business—they are in the data business.” Eh, no, they aren’t. Customers go to this brand for a drink or a bite to eat. Yes, data plays an increasingly important role in their business, but is not their raison d’etre. In my previous role, I was thrilled to read a stock analyst raving about our technology solutions—but the report lost some credibility when the analyst postulated that McDonald’s was now a technology company, not a restaurant company. Microprocessors with your hamburgers, anybody?
I appreciate the promise technology holds in unlocking value in new ways. Its considered application is a critical competitive differentiator, and helps people find new offerings or even businesses to launch. Doing this, though, doesn’t make a company a technology company, just as profound insights into a P&L does not turn a construction company into a finance company.
So how do we tackle this conflict between silver bullet thinking and not wanting to be left behind? The full answer would be more suited to a book than a blog post, but I want to reflect on four powerful approaches I’ve seen work.
Work Backwards Together
Too often data initiatives start with what we want from the customer, rather than what the customer values. Customers give companies data on themselves and their behaviors in return for a better experience, a personalized offer, or some other quid pro quo. Without this two-way value exchange, there is no business or data. As with any initiative, understanding the customer value proposition should precede anything else. Then, work backwards from this to define the “how.”
Agile methodologies work well here as with any highly uncertain situation. Fast-moving cross-functional teams focused on defined business problems or outcomes can turbocharge the usefulness of data. (I prefer this over the establishment of a dedicated analytics function, but that’s a topic for another day.) The typical agile tenets apply, including small, autonomous teams, sprint reviews, and a focus on value delivery. An added benefit of this in-it-together approach is that these teams establish trust early on, causing team members to be more willing to learn. This foundation helps establish a level playing field in terms of understanding what’s needed on the data journey, reducing friction and improving success rates.
The iterative build-test-learn approach is also a proven way of creating urgency, momentum, and focus. Prioritizing value helps prevent the tendency to churn out data reports without the requisite action that makes data useful.
Increase Data Literacy
The practical application of data in a business requires a level of data literacy: your own, your peers’, and the organization’s. Just as some companies have set up internal digital academies or training programmers, the same is needed for data. Whatever educational journey you plot should demystify and contextualize terminology such as data stewards, data lakes, descriptive and predictive analytics, and big data. It should make concrete what the phrase “data-enabled” means in your business. At its most simplistic, this could be using the data you already have to create a virtuous circle of data driving better innovation that in turn drives better products or services, better customer engagement, and better data.
Most important is education around mindset. Our built-in confirmation bias looks for data to support our assumptions and positions. Truly data-enabled organizations must be open to the fact that the data is just as likely to contradict deeply held opinions and beliefs. The promise of big data goes further: we need to accept that often we don’t even know the right or most pertinent questions to ask. This culture change is difficult. Early on, leaders need to start demanding data to support hypotheses or opinions, and asking searching questions to ensure opinions are founded on data rather than vice versa.
A practice we often skip in our desire to be decisive is to not take decisions until necessary. On one side of this “decide/defer continuum” are analytic tools. In today’s environment, it is counterproductive to select a single tool. For many end users, simple tools such as Excel or Amazon QuickSight on top of abstracted data will suffice. For others, R and Python and direct access to the raw data are critical. Over time, you might narrow the field to make recruitment, training, or licensing decisions easier. In other areas, I would not procrastinate. For instance, regardless of your business objectives, a data lake for your raw structured and unstructured data makes sense. Given the 3 Vs of big data—velocity, variety, and volume—along with the need to ensure cost effectiveness and wide accessibility of data, just please don’t try to do this on-premises!
In a similar vein, there is no dearth of tools out there for data movement, ETL, data lineage tracing, or machine learning. In the early days of your journey, opt for pay-as-you-go technologies when possible. This enables your team to figure out what is really needed, even just as a minimal viable product, without being locked into unnecessary and restrictive license terms. It also avoids the oh-so-easy to slip into sunk cost bias, a fallacy that prevents better ways of working from emerging.
As with any change in culture, having a single threaded owner is important. In some companies this might be a Chief Data Officer (CDO) or Chief Analytics Officer (CAO), but I caution creating these new roles before having a good understanding about what is required for your organization. I suspect that it is far better initially to nominate an existing senior leader whose mission it is to get the proverbial data ball rolling. If you do opt for a CDO or CAO, just like the digital officers before, use these roles to infuse data-centric thinking in the organization rather than to build a data empire.
Organizationally, the instinct is often to go hire a bunch (correlation?!) of data scientists before understanding what skills are really required. These initial job descriptions often define unicorn roles: deep technical, business, and cultural expertise and achievements beyond what is reasonable. Early on in your data journey, use consulting resources to help you understand what skill are really needed, as well as to accelerate your learning curve. Normally there is significant untapped potential in the data already available or significant issues to overcome to get the data, such as functional siloes resisting giving up their control over it. In these situations, having niche skill in-house will prove costly, of little benefit, and demotivating for the individuals who took the roles. Many large organizations I’ve seen have internal disagreements over what should be done centrally and what in business units. Figure these dynamics out before staffing roles else suffer the consequences of reduced agility and increased conflict, as I’ve discussed in an earlier blog post.
Imagine someone turning up at your home telling you that they were there to fix your washing machine, which was going to fail in five days’ time. Would you believe them? Well, that was the issue I encountered on an Internet of Things project a decade ago, focused on enabling real-time monitoring of tens of thousands of pieces of equipment. The hypothetical business case was compelling and we were pleased with some of the cool implementation details, such as data communications over the electrical wiring. The problem, as is the case over half of technology-enabled initiatives, is that we had woefully underestimated the role of human behavior.
Data without frontline action is expensive and academic. Analytics is about understanding and motivating a change in an organization. As with many large-scale changes, the rule of thumb is that half of the investment in data should be on the human enablement component. I witnessed this firsthand in the 1990s with the deployment of food analytics across UK restaurants. Significant effort went into training restaurant staff on how to use data as a diagnostic to identify sources of waste, and their feedback helped us ensure that the reports were meaningful and digestible. Tens of millions of pounds were saved therefore. Simplicity and engagement are the keys. Ensure reports are clear and visceral in the eyes of the end users; in fact, get them involved in the design. Invest in training and collect data on how effectively data is being used to identify further training opportunities. Encourage leaders to talk about the value of the data. Take every opportunity to engage with those using the data to understand barriers in turning it into valuable action.
Interestingly, actual silver bullets are less accurate and more expensive than regular bullets and were speculatively manufactured to slay mythical creatures. Good context for the next time you a presented with the technology equivalent! Learn more about what data and technologies like AI and ML can do for your business.
This blog was previously published on AWS Cloud Enterprise Strategy Blog