We’ve become a society of data hounds. If all people, everywhere, were suddenly endowed with perfect health, we might no longer need doctors, but we would still need data engineers and scientists to report on the impact of this radical change.
The skills of the data professionals who give us information are rightly admired. To start with any real thing, extract representative data, organize it, summarize it, improve it, and report the results involves skills ranging from measurement, to data modeling, to database design and maintenance, to data querying, to predictive modeling and artificial intelligence, to visualization and reporting.
That is such a diverse ecosystem of skills that when I’m asked, I encourage those looking for talent to look at people first, and skills second. It’s hard to know precisely what skills we’ll need next year or even next month, but a good team member with the ability and willingness to try something new will be an ongoing asset – maybe not this instant, but in the long run.
Technical skills are tremendous, but we can forget that an 85% skill level gets the job done about 99% of the time. And what makes technical skills really valuable – a growing knowledge of the context and workings of any organization – not only lie outside strict technical domains, but are actually enhanced when our team members help us in different capacities.
And what is the most critical technical skill in the process of information processing? Perhaps the skills we ask of our user communities, often without entirely realizing the burdens we put on them.
Our data ecosystems comprise a miniscule slice of reality – a slice that is often relevant, but a slice that is guaranteed to be incomplete. Users must first ask questions within the limits of our data system – not necessarily their reality – and then by experience interpret results correctly, surmising the uncertainties, limits, biases, and context in the answer which appears on the screen.
Because building data systems is a challenge, we can forget that our users both start and finish the information-processing sequence. As good as data systems often are, they are never complete “answer shops,” and it is our user community who must fill in the blanks. Incompleteness might comprise the greatest challenge for many users. Data systems are often quite good at delivering factual data – telling us what, who, when, and how much – but less good at how or why.
However it’s how and why that often drive our interest. It’s the difference between knowing which sales team (who) sold the most, and the underlying reason for those sales, which could be a function of region, the sales team, new products, good fortune, or a combination thereof. We’ll probably answer the “who” without a problem, but proving causation is a bigger challenge – we may need to accept that our data doesn’t tell us what we want to know. I often see users challenged to resist the temptation to interpret, beyond what the data tells us. In a real sense, our users must become informal data scientists, restricting and separating data-based conclusions from hypotheses based on experience. It’s a true skill, requiring time and experience.
Like our data-producing colleagues, our best information consumers may be those team members who are always willing to try something new – in this case, to view new information in a manner informed by, but not dominated by, prior experience. It’s a little like getting a new pair of shoes – we’ll give them time to break in, but they have to work for us in the long run. Ultimately, we’re the ones who know if the shoe does, or doesn’t fit.
I can testify that it’s not a joyful moment when a user community says they cannot consume a data product, but that’s far better than having the work lie unused. The data business really is the people business, and it’s only worthwhile when people are actively using our outcomes.