Ben's Page

Bottom Line Up Front

I advocate for the development of “data support plans,” not “data strategies.” Though this difference might seem like a matter of parlance, I believe it to be indicative of one of the greatest challenges firms have in working with data: understanding how data supports the broader mission. Simply put, there is one strategy – the business strategy. Everything else (e.g. marketing, recruiting, staffing, sales, finance) is in support of that strategy. Data is no exception.

Overview

Almost every organization in business and government realizes the value of data. As a result, many groups are seeking to build “data strategies” to more effectively use data. In doing so, companies often conduct research and hire consulting firms to identify “best in class” examples of firms working with data (usually in the tech industry). The idea, of course, is to emulate such “best in class” practices.

Though this logic is understandable, I advise against it. Working with data is not an end in and of itself. Rather, it is a means to an end. Accordingly, a firm shouldn’t be asking “What should our data strategy be?” Instead, a firm should be asking “What is our (business) strategy, and how can data support it?” Furthermore, a firm shouldn’t be seeking to implement “best practices” simply because they worked for someone else. Instead, a firm should be asking what practices, if institutionalized, would significantly bolster their business.

Though these points might seem like trivial points, or mere issues of parlance, I believe they are actually one of the most important aspects of working with data. The purpose of this post, therefore, is to:

Highlight issues that arise from developing “data strategies” in isolation
Explain why I advocate for a “data support plan” in lieu of a “data strategy”
Provide a list of questions to help firms understand what (data) practices should be institutionalized at their organizations

The Dangers of Crafting a “Data Strategy” in Isolation and Seeking to Emulate “Best in Class” Examples from Outside Your Firm

There are indeed firms who need a true “data strategy.” If you are reading this white paper – you probably aren’t one of them. I don’t say that to provoke, but to highlight a point. If your business does not make money solely from the provisioning, engineering, and use of data, then data isn’t your strategy. If, instead, your business makes its money through some other activity (sale of products, services, etc.) then that activity is your strategy. You should use data to support that activity.

I recognize that many people will say this idea – using data to support your main activity – is what they mean when they say “data strategy.” Even so, I still caution against this term, in favor of the term “data support plan,” because of how it will be practically implemented at the developer and engineer levels.

Simply put, developers and data engineers, especially those from external teams, tend to interpret “data strategy” as that which works best for them as they work with data. As a result, it is not uncommon for development teams to create “data strategies” which produce great data infrastructure, but that is still confusing, burdensome, or altogether useless.

These scenarios are easy to identify. Just ask one of the business analysts a fairly straight-forward, but niche business question (e.g. “What was the percentage change in revenue on this product in that state from April 2012 to May 2013?”). If the analyst has to generate a truly bizarre query to find the answer to the question, it’s because the data infrastructure was developed in isolation from the needs of business users. (By the way, this is an incredibly common problem).

We also advise against the trend of blindly looking for “best in class” examples of firms working with data (usually tech firms). It is understandable why a firm would want to do this, particularly if the firm does not feel confident in their current ability to work with data. The idea of simply benchmarking against “best in class” examples, however, can lead firms down the wrong path. This mentality can end up leading to a lot of wasted time and energy.

For instance, if your firm makes money by manufacturing and selling components for construction equipment, should you really care how Amazon structures and leverages data to for its recommendation engine? Indeed, Amazon is “best in class.” But that doesn’t mean your firm should simply just try to do what Amazon does. The questions your firm should be asking are about how you can use data to measure performance, forecast issues, improve sales, etc. Most importantly, you should be asking what practices your firm should employ to better address these issues.

If it happens to be that your firm’s imperatives align with applicable examples from Amazon, then you are in luck. Do a case study on Amazon, or simply try to hire some of their people, and do what they do. But this is rarely the case. More often than not, firms try to emulate leading tech firms without proper context. This can lead to several pointless initiatives.

The Benefits of a “Data Support Plan” Mentality

As trivial as it might seem, I champion the term “data support plan” in lieu of “data strategy.” To be clear, I am less concerned with the specific terms in question. I are more concerned about the mentality behind the terms in use. The “data support plan” mentality fosters alignment with the business owners and with the other members of the company.

To make this point more clear, I suggest an experiment. Ask the following questions to a Java developer in your company and also to a person who is directly responsible for booking revenue (sales, servicemember, etc.) I'm 99% certain you will get different answers.

What data does your firm own?
What data does your firm need?
What is the best approach and tool to store and manage your data?
How does data inform your decisions?
What benefits should you expect from expanding your data capability?

The reason your firm will get different answers to these questions is because of misalignment between the developers/engineers and those who book revenue. Having a mentality of “data support planning” in lieu of “data strategy” planning is a great way to add context to these types of questions and to mitigate such misalignments.

Practical Questions to Identifying (Data) Practices to Institutionalize

It would be unfair to criticize blindly seeking out “best in class” examples without offering an alternative model to determine what practices should be institutionalized at a company. I therefore offer the following framework for identifying best practices, both from current practices, and from external firms who indeed, would be worth imitating.

First, review your current data practices in light of a few questions:

Can we get rid of this practice/tool altogether? This sounds like an obvious statement, but you might be surprised how much time, attention, and energy is given to legacy code and tools which have far surpassed their business value.
Is this practice being done in different ways by different teams in the company? If the practice is inconsistent, seek to standardize it before reinforcing any of the divergent methods used.
Can this practiced be improved? If there are obvious lags in the practice, then address them before seeking to broaden the application of the practice.
Can this process be automated? This is a no-brainer. Do not invest in maintaining a practice that could otherwise be automated.

If your current practices fail the above questions, then it’s a good idea to bring in fresh thinking. But that’s not to say you should blindly do what other companies do. Before implementing practices from other firms, review them in light of a few questions:

Does the firm face the same regulatory / oversight pressures as our firm? While this may seem outside of scope, it’s a great question. If you are in a heavily regulated industry (e.g. finance, life sciences), trying to follow the practices of a firm in an unregulated industry could be problematic. Proceed with caution.
Do we have the personnel to implement the practices from the firm in question? Hiring consultants to train your own team or to buy time while creating your own team is acceptable practice. But do not invest in a practice if you do not already have the people (or plan) in place to implement it.
Do we have access to, or intent to use, the same type of data as the firm in question? Benchmarking against a firm that uses completely different data than your company can set unreasonable expectations. It is worth doing a quick “sanity check” to make sure you aren’t trying to follow a precedent that your company couldn’t reach in any condition, simply because of the type of data your company uses.

Conclusion

To sum it all up, I advocate for the use of the term “data support plan” in lieu of the industry standard “data strategy” because it fosters a mentality of more smartly using data to support business objectives. Furthermore I caution against blindly emulating “best in case” examples of firms working with data. Instead, carefully consider the specific business strategy and how data can be used to further it. Then seek to institutionalize best practices from within a company and from external examples.