Keeping Up With Data #87
5 minutes for 5 hours’ worth of reading
Every company needs to find a balance between offensive and defensive elements of data strategy.
Offensive elements are about data and analytics supporting the business objectives (driving revenue, profit, value, or UX). Defensive ones focus on minimising the downside risks, they look into compliance, security, privacy, or governance.
Taking an extreme position is not an option (it’s like buying a car without breaks, or without engine), and we can’t take it all. There is an inherent trade-off between offense and defense.
I love this approach to data strategy outlined by Leandro DalleMule and Thomas H. Davenport in their 2017 HBR article. I find it very intuitive and illustrative.
Not everyone agrees and many people are evading the term offensive when debating data strategy. Investors and executives are talking about value creation and value preservation. Data strategies should too.
Next to the masterpiece discussed above, there are three more articles in the reading list today.
- How to Prevent Data Analytics from Wrecking Your Strategy: In the world where everyone is saying what to do with data, it is refreshing to read what not to do with it. There is a thin line between data enthusiasts and data fanatics dogmatically and blindly doing what the data says. But this approach contains huge risks. What the leading strategy advisor is proposing? 1) Don’t limit the data sources for inferences; 2) don’t flatten data to its most unidimensional form; and 3) don’t be convinced by data that something is undoable. (Roger Martin @ Medium)
- Maturing a Data Literacy Initiative in a Large Organization: The article provides a unique insight into shifting data literacy of an organisation with ~25k employees. I very much enjoy blog posts written by industry practitioners (especially when written in hindsight), because they often contain lessons learnt for others who follow a similar process. There were two such points for me: 1) the data office has been organised around principles, which I’m a big proponent off as they offer guidance in the times of trouble (and there are many on a data journey!), and 2) driving data literacy cannot be done with one-size-fits-all solution, but requires a targeted approach (in LEGO’s case designed around 5 personas and 26 sub-personas). (Ellis Didriksen @ LEGO Engineering)
- Design Patterns in Machine Learning Code and Systems: Design patterns are important for object-oriented programming. But Eugene puts it: “Design patterns are not just a way to structure code. They also communicate the problem addressed and how the code or component is intended to be used.” Nice overview of factory methods, decorators, adapters, or mediators. Not every data expert is a programming expert, but learning something new can’t hurt. And for example the timer decorator can come very handy to many! (Eugene Yan)
The weekend forecast says sunny and 33°C. Way above my comfort temperatures. But with the Alps at our fingertips, we can regulate the weather with altitude. And that’s what I plan to do this weekend.
