Be honest: There can be a certain joy in having more knowledge than others. Those of you who are older siblings know what I’m talking about. Having an advanced ability to analyze, interpret and navigate the world puts you in a pretty privileged position. If you can predict outcomes in a way your little brother can’t, not only do you win a sense of mastery, but you get the admiration of little bro to boot. Grudging admiration sometimes, but admiration nonetheless.
That being said, if you’re approaching your enterprise in the spirit of sibling rivalry, you likely have the wrong frame of reference. There’s mutual benefit to be had from making your organization better able to understand its environment: Your organization as a whole should become stronger and more adaptable, and you in turn have the opportunity to emerge as a leader.
Building data literacy is one way to move your enterprise forward. We’re not talking about giving everyone a full-blown analytics toolkit here. But at the least, you want people to understand how to reverse engineer the insights you give them.
The right steps for building data literacy will vary from organization to organization, but keep the following in your back pocket as you move forward:
- Share the Data-Information-Knowledge-Wisdom (DIKW) model. Granted, it’s not perfect, but it lays the groundwork for careful and considered examination of data and what it takes to use it well. The point isn’t to be able to perfectly articulate the difference between knowledge and wisdom, but to illustrate the ways in which we move from disparate pieces of information to a more coherent, interpreted and applied view of one slice of the universe.
- Draw the data big picture(s) for your organization. This isn’t likely to be a detailed model (although you’re free to go there as well). Instead, it’s a simplified representation of the types of information that your organization cares about. In particular, give people a view as to:
• How the types of information relate to each other.
• How information flows through and is generated by your organization.
• Which parts of the organization affect which types of information.
• Where they themselves fit into your organization’s data practices.
- Explain your tools. You know what? Some people’s eyes are going to glaze over, and that’s all right. Others are actually going to pay attention. Put things in laypersons’ terms. If you’re going to give people the high level on how cluster analysis works, don’t spend five minutes belaboring the difference between Euclidean distance and cosine similarity. Keep it simple. Focus on the fact that you’re using basic geometric and trigonometric concepts to calculate the distance between data points and to determine which of them “belong” together. The details can come later to those who are inspired to keep digging.
- Don’t feed the magic. Tempting as it may occasionally be to be obscure, you’re better off explaining in the long run. Don’t overstate your team’s abilities to analyze and interpret the data that comes your way – and if someone else sets their expectations too high, set them straight. Make the mechanics of what you do clear, along with the strengths and limitations that go with your practice. That’s the core of a prolonged and mutually satisfactory relationship.