James Governor's Monkchips

Data fluency isn’t just for tech anymore.

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

java devices

So data transformation is the new digital transformation. One of the critical aspects in building an organisation that can make more effective use of data than its peers is creating the right culture – not everybody needs to be a PhD,  but ideally everyone should be data curious. In my last post on data transformation I quoted Pierre Etienne Bardin of Société Générale:

“Data transformation is like digital transformation, it impacts everyone.”

I was struck by some parallels in this great First Round Review post, based on an interview with Looker founder and CTO Lloyd Tabb. The post makes the case for a more astute use of data, avoiding vanity metrics in favour of those that can really drive a business. In a restaurant, for example, why not use how full customers’ glasses are as a proxy for good, engaged service. This one really struck me – it can be really frustrating trying to catch a waiter’s eye in order to ask for another glass of water. But the job to be done is not them watching me, but rather making sure I have everything I need.

Over the years RedMonk has tried (sadly not terribly successfully) to help our clients avoid vanity metrics in developer engagement. Sun used to love to claim how many millions of Java developers there were in the world, but that didn’t ever translate into revenues. When a vendor tells me how many registered developers there are on their developer network my eyes start to roll. I have been part of these communities. What really matters is who actually does the work, and makes an impact. Generally a small number of people are making most of the contributions. What matters is how much time are general users spending actually using the network. Registrations are cheap. Downloads are also pretty useless as a measure (especially in the age of the CI build). Downloads don’t matter – what matters is whether people are using your software. Of course downloads or registered users excite the chief marketing officer, and of course hockey stick investors, but they don’t really help you build a business for the long term.

Tabb instead argues we should try and identify clarity metrics. We should also pay more attention to the outliers – why not given them a call and find out how and why they are using the service differently? His summary really spoke to me, in terms of the the jobs we need to do, and the data transformation.

“Data fluency isn’t just for tech anymore. Every department in every company must invest in it: customer support, design, business development. They should be parsing through data to find proxies. When they find an outlier, they’ve got to be ready to dive in. You can’t scale if there’s a line outside your data team’s door. Host an AMA about event streams and showcase your data scientists. Let people shadow the data team or embed data scientists in teams like design and customer support. I see a world where people can explore data the same way they find information via Google. When you first used Google, it took time to learn how to pull what you wanted out of it. Eventually, you learned how to get what you need — and when you did, you had this amazing click-through view of the world.”

4 comments

  1. […] Data Fluency Isn’t Just For Tech Anymore. […]

  2. […] How do we define engagement around that content? (are we chasing “clarity metrics” or “vanity metrics”) […]

  3. […] I really like the approach in this post by npm trying to work out how many users it has. It discounts raw downloads (not a good measure of adoption in the age of the build server doing downloads) but correlates across web traffic, by unique IP. How many packages per run, and per IP. It’s super important to not just settle on vanity metrics but rather to grope forwards with sanity metrics and then clarity metrics. […]

  4. […] have written before about the fairly shabby reliance on vanity metrics in traditional developer relations programs. Marketing wants big numbers, so you just end with a […]

Leave a Reply to glitch – developer engagement and telemetry as a service aka marketing automation comes to dev rel. - Enterprise Irregulars Cancel reply

Your email address will not be published. Required fields are marked *