If you’re looking to grow your analytics skills, should you focus on technical acumen such as database modeling and statistics, or business strengths, like working with stakeholders and communicating goals?
It’s a question I get often from aspiring analysts, and a good one—they see that providing value to the organization is indispensable to their desired role, and that crunching the data is just a means to the end. And after all, one can only focus on growing in so many areas…what’s the better knowledge investment?
To answer this question, I’d like to (appropriately enough) cite data from research advisory Gartner: by 2022, 90% of corporate strategies will explicitly mention analytics as an essential competency.
Data is now a core lever to creating business value. Craig Mundie, senior advisor to the CEO at Microsoft, put it like this: “Data are becoming the new raw material of business.”
Mundie’s declaration echoes that of British mathematician Clive Humby, who stated that “data is the new oil.” As more experiences become digitized, more data is collected. But that data is only useful when it’s been “refined:” not only cleaned and transformed, but placed into its proper business context.
“Data is only useful when it’s been ‘refined:’ not only cleaned and transformed, but placed into its proper business context. “
This close pairing of data and business means that analysts can comfortably grow their technical proficiency and business acumen at once, particularly in how they provision their tools (in particular, when choosing between open source and proprietary solutions), and how they work cross-functionally to connect business value to data.
Ultimately, an analyst can only communicate business value insofar as they have a technical command; but this technical command is of little value outside its business environment to begin with.
You Are a Customer of Technology
As an analyst, you’re often seen as a supplier of reports, insights and so forth. But it’s worth remembering that to make those deliveries, you’re a customer yourself – of data technologies like spreadsheets, databases and business intelligence tools.
You may not be responsible for budgeting, selecting or deploying these applications. But how you deliver your products and services is undoubtedly shaped by the business models of the vendors whose tools you use. You can unpack the consequences through a combination of technical and business skills.
The Growth of Open Source
As a burgeoning data analyst, have you used R or Python? What about PostgreSQL or SQLite? If you’ve worked with any of these, then you’ve worked with open source software.
According to software company and open source pioneer Red Hat, open source is “designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.” This open source software is free – compare this to proprietary, “closed source” programs like Tableau or SAS.
In the past, many organizations were hesitant to adopt open source for fears of security breaches, intellectual piracy, and so forth. In fact, Microsoft famously waged a crusade against open source for many years – former CEO Steve Balmer in 2001 even went so far as to compare the open source operating system Linux to a “cancer.” Flash forward a decade later, and current CEO Satya Nadella put up a slide declaring “Microsoft ♥ Linux.”
What changed?
As Red Hat (which coincidentally offers Linux-based products and services) goes on to explain in its definition of open source, open source is “often cheaper, more flexible, and has more longevity than its proprietary peers because it is developed by communities rather than a single author or company.”
Microsoft and others came to appreciate the rapid execution and iteration on open source projects, as product lifecycles have continued to decline during the digital era.
The distributed, flexible and asynchronous nature by which open source is often built only became more of a benefit during the coronavirus pandemic, as teams had to adopt similar methods of collaboration.
In fact, cloud-based code management provider GitHub, where many open source projects are hosted, found a 40% year-over-year growth in open source project creation between April 2019 and April 2020. GitHub holds the code for many of the most popular open source analytics packages, such as R’s ggplot2 and Python’s pandas. (GitHub, as it turns out, has been owned by Microsoft since 2018.)
All that said, there can be some amount of risk for relying on a software that is not commercially supported and is maintained by volunteers, who may not have any succession plan in place for their project. I myself have run into bugs within open source packages that caused incorrect results. Fortunately, I caught them before I used the results in a presentation.
Proprietary vs. Open Source: A Technical Choice with Business Impact
What does any of this have to do with the technical versus business skills divide? You’re likely to work with many tools, from spreadsheets to databases to BI systems. Some of these may be open source, some proprietary.
If you use open source, you’re likely to find one freely available package (likely out of tens of thousands) to kickstart whatever your use case may be. At the same time, that package may be in a beta state at best. Proprietary tools are likely to be more vetted, but at the expense of speed to delivery and variety of tools.
Understanding the pros and cons of each framework, you’ll be more productive and anticipate possible technical roadblocks. Your stakeholders may not care about the licensing of the software you’re using to conduct your work – but they might care about turnaround time, project risk or cost.
Is developing an intuition about open source versus proprietary tools a technical or business skill? In many ways, it’s both.
The Data Is the Business
Whether it’s a discussion about what software to adopt or how to design a product, technology has become so embedded into an organization that it can be hard to extricate the two.
As discussed, data has become the raw material of business. But, like cash, good data doesn’t just grow on trees—someone needs to collect and analyze it with the needs of the business in mind. And that’s where you come in as an analyst.
The burgeoning market for wearables technology provides a useful case study here. Say your organization wants to develop a smart wallet (And yes, there is actually such a thing… look it up!). While the wallet may have some aesthetic appeal, its main value driver is the data that is collected and used to personalize the customer experience.
“As a data analyst, you can help both gather the data requirements of the product and evaluate its potential profitability.”
As a data analyst on this smart wallet project, you might work with user experience researchers and product managers to design and map the user’s journey: how they will use the wallet, and where will the benefit be? What additional features could help?
Importantly, you’ll also have to figure out what sort of data needs to be collected, and how it will be transmitted. You may work with engineers or product designers to develop that last part. From there, you might work with finance to determine pricing and feasibility of adding various requested features.
What’s inherently powering the business value in this example is data—without the data, the smart wallet wouldn’t offer much added value over a regular one. As a data analyst, you can help both gather the data requirements of the product and evaluate its potential profitability.
You stand to be of tremendous value on such a cross-functional team where no one can succeed unless by leading with data. It’s hard-pressed in such a situation to parse technical from business value here.
Technical Expertise Requires Clear Communication (and Vice Versa)
Here’s another way that it’s hard to untie these skills: as an analyst, the better you know the ins and outs of your methods, the more you can spell out what the results can and can’t tell your stakeholders.
Inferential statistics provides some great examples here: for example, a FiveThirtyEight journalist found that even very few professional scientists could translate the meaning of a p-value into everyday terms.
Yet scientists and business practitioners alike often rely on this measure alone for making decisions. As an analyst, you would never let your business partners act solely based on some key performance indicator (KPI) that no one can explain; why should it be any different for you?
By taking the effort to deeply understand the mechanics of a subject like inferential statistics, you as an analyst are in a better position to communicate the right findings in their proper context to your audience. For example, in my book Advancing into Analytics I provide two ways to communicate the same findings to an audience:
Imagine you were a research analyst at a bank reporting the results of this study on home prices to management. These managers wouldn’t know where to start conducting a t-test if their careers depended on it—but their careers do depend on making smart decisions from that analysis, so you want to make it as intelligible as possible. Which statement do you think will be more helpful?
- “We rejected the null that there is no difference in the average sale price of homes with or without air conditioning at p < 0.05.”
- “With 95% confidence, the average sale price of homes with air conditioning is approximately between $21,200 and $30,800 higher than those without.”
Same results, communicated with different metrics—and it’s only with technical knowledge that such a distinction between what these metrics mean can be made. At the same time, framing this distinction in the right terms requires communication skills as well. You could, like so many scientists in the FiveThirtyEight article, know all about p-values but be unable to explain their value to a general audience.
Analysts require an aptitude to deliver what an audience will really care about in a medium that engages them. The deeper your technical skills run, the better you’re able to interpret the results. And the deeper your business skills, the more capable you are to put these into a relevant context. It’s hard to get far in one without the other.
The Two Lungs of Analytics
To close on my reflections of the interoperability of technical and business skills, I’d like to draw an analogy between learning analytics and, of all things, weightlifting. Weight machines are used to isolate and strengthen a certain muscle group. Working in isolation, one muscle group at a time, has its benefits for the same reasons it’s good to stick to one task at a time instead of multitasking. But any trainer will tell you that such isolated motions are unlikely to be encountered in the real world; free weights offer an alternative that more realistically approaches everyday weight strength needs.
The same goes for analytics skills. Isolating technical and business skills for the strength of growing each has its benefits. But when you get to a job, they’ll become so intertwined that it will be hard to tell them apart. Don’t sweat too much on separating out your skill set; instead, look at the ways that technical and business skills are like two lungs for today’s analyst, working together at all times.
* * *
Want to build up your business acumen, communicate more effectively with stakeholders, and advance your career in data? Register for Pragmatic Institute’s new course, Business-Driven Data Analysis.
