The Data Value Chain: Seven Skills That Turn Data Into Decisions

This article is part of the Data Value Chain series

• The Data Value Chain: Seven Skills That Turn Data Into Decisions
• AI and the Data Value Chain: Where the Bottleneck Moved
• Unstructured Data and AI: The Knowledge You’ve Been Sitting On
• Seven Links in the Data Value Chain (Original)

I walked into Pete’s office with the pitch I’d given a hundred times. I was a few years away from my first Business Unit CIO role, but I had plenty of confidence in what technology could do for a smart executive. Pete ran a multibillion-dollar distribution company, and he was sharp – the kind of leader who preferred hard data over gut instinct and wasn’t shy about using it to hold his team accountable. I figured he’d love what I had to offer.

“Just tell me what you want the screen to say,” I told him, “and I can make it happen.” All the dashboards, all the KPIs, whatever he wanted at his fingertips. The usual technology lead-in.

Pete wasn’t enthusiastic. He joked that with enough information, he’d make his team miserable – “asking a million questions and calling them out whenever they filter the results and protect me from the truth.” We both laughed. I knew his team, and arming Pete with granular detail was going to create some interesting conversations in the hallway.

But then he got serious. “I don’t want to be the only person asking questions.”

He explained what he meant. Every day, a manager brings him a standard report. He spots something – sales down in a region, inventory building at a location, on-time delivery slipping for a product line. He asks a question. The manager goes away, digs into the data, comes back with a solid answer. Pete looks at the new report, sees another anomaly, asks another question. The manager goes away again, comes back again with another answer. And so it goes.

“The manager sees success,” Pete said, “because she’s able to provide the answers. But that’s not success to me. The manager should be the one to ask the questions.”

What Pete wanted wasn’t a better dashboard. He wanted people who could look at data and get curious on their own – who would walk into his office with observations and questions instead of waiting for him to point at a number. “Build something that helps people become smarter, more curious, and more insightful,” he told me. “Find a way to inspire people to ask the next question.”

That conversation stuck with me through four CIO roles and a couple of decades of building data teams, because Pete wasn’t really talking about dashboards or reports. He was describing the full chain of skills required to turn raw data into real decisions – and he’d put his finger on exactly where most organizations come up short.

The Data Value Chain

Over the years, building data teams across manufacturing, consumer products, and distribution, I kept running into the same pattern. Every organization that struggled with data was missing something different – but the categories of what was missing were remarkably consistent. A pattern emerged that I started calling the Data Value Chain: seven distinct links, each requiring a different skill set, that together describe the full journey from raw data to business value.

Think of them as links in a chain. Break any one of them and the whole thing falls apart.

Insight is where it starts – that spark of imagination required when looking at a challenge or opportunity, figuring out what metrics or measurements might lead to real value. This is the person who knows the interesting questions, who understands the business well enough to know which numbers actually matter. It’s not a technical skill. It’s pattern recognition born from deep domain experience.

Architect is where the technical thinking begins. This person designs the infrastructure – databases, storage, communication, access – to handle the flexibility, scale, and sustainability the business needs. Good architecture anticipates questions that haven’t been asked yet without over-engineering for questions nobody will ever ask. It’s a judgment call, every time.

Generate is the hands-on work of pulling actual data from sources. Connections to internal systems, external feeds, devices that have never been metered before. This step has gotten dramatically easier with modern tooling, but it still requires someone who understands both the technology and the data well enough to know when something’s missing or malformed.

Store covers the physicality of data management – engineering the storage to handle volume, maintain performance, and keep costs reasonable. Cloud has changed the economics here, but “cheap to store” doesn’t mean “easy to manage.” Someone still has to make smart decisions about what lives where and for how long.

Process is the grunt work that makes everything else possible. Scrubbing, matching, normalizing, augmenting – the tedious, critical discipline of keeping data clean and complete. This is especially true for master data and metadata, the connecting tissue that lets different data sets talk to each other. Most data quality problems aren’t technology failures. They’re process and ownership failures.

Analyze is where domain expertise comes back to the table. Unlike Insight (which starts with a blank canvas), analysis works with what’s been collected – understanding the data model, looking for patterns, answering the original questions while remaining curious enough to spot new ones. The best analysts don’t just confirm what they expected to find. They notice what they didn’t expect.

Present is the last mile, and it’s typically the least appreciated. How do you take a complex idea, expressed in data, and create reports and visualizations that communicate the hidden messages to the people who need to see them? This isn’t chart-making. It’s storytelling with numbers – and it requires a completely different skill set than anything else in the chain.

The Bookends Problem

Here’s what I’ve learned building data teams across four CIO roles: the hardest links to fill aren’t the technical ones. They’re the bookends – Insight and Present.

The middle of the chain (Architect through Analyze) requires genuine technical skill, and I don’t want to minimize that. But technical skills are screenable. You can test for SQL knowledge in an interview. You can evaluate someone’s experience with data modeling or cloud architecture. You can look at a portfolio of analytical work and gauge competence. It’s not easy to find good technical people, but at least you know what you’re looking for.

Insight and Present are different. They’re the points where the chain connects to reality – to the source and use of information – and they demand a kind of thinking that doesn’t come from technical training. Insight requires someone who understands the business deeply enough to know which questions are worth asking. Not “what data do we have?” but “what would we need to know to make a better decision about this specific problem?” That’s not a data skill. That’s business imagination combined with enough technical literacy to know what’s feasible.

Present sits at the other end with a similar challenge. You need someone who can take a complex finding, expressed in data, and translate it into something that changes how a decision-maker thinks. That’s not chart design (though that helps). It’s the ability to read a room, understand what your audience cares about, and lead with the one insight that matters instead of burying it on slide 47. It’s communication as a strategic act, not a reporting exercise.

Most organizations hire for the middle and hope the ends take care of themselves. They don’t. You end up with teams that can build beautiful data infrastructure and run sophisticated models but can’t connect any of it to the decisions the business actually needs to make. Pete’s frustration – managers who answer questions but never ask them – was a symptom of this exact gap.

The Purple Squirrel Trap

So organizations go looking for the one person who can do it all. The industry has a name for this: the purple squirrel – a candidate so rare, so perfectly qualified, that they might as well be mythical.

And sometimes you find one. Someone brilliant at asking business questions and designing data architecture and writing elegant queries and building compelling visualizations. These people exist. I’ve worked with a few. They’re typically hoarded by their organizations – peers in the industry won’t even share their contact information, let alone admit they exist.

Here’s what happens next. The purple squirrel builds sophisticated infrastructure that only they understand. They answer business questions, but only the ones they find interesting. They create dashboards that require a PhD to interpret. They become indispensable, which feels like success right up until they leave for the next opportunity. And they always leave for the next opportunity.

When they do, the entire data capability walks out the door with them. The architecture they built? Nobody else can maintain it. The models they created? Nobody else knows what assumptions went in. The relationships they built with business stakeholders? Gone. You’re back to square one, except now you also have a pile of technical debt that nobody understands.

Any process that depends on a single person is a risk. This is true in manufacturing, in customer service, in product development – and it’s especially true in data, where the chain of skills is so broad that concentrating it in one individual almost guarantees fragility. You can’t find the full Data Value Chain in one person. You have to build it across a team.

Building the Orchestra

If you can’t find the Data Value Chain in one person, you have to build it across a team. Think of it less like hiring a superstar and more like assembling an orchestra – different instruments, different strengths, playing from the same score.

The technical roles are the easier part of the recruiting puzzle. You can screen for data architecture experience, evaluate someone’s pipeline engineering skills, assess their comfort with cloud platforms and analytical tools. These skills are trainable, too. A reasonably talented person with solid technical aptitude can learn a new database platform or pick up a new programming language. It’s a matter of time and investment.

The harder part is staffing the bookends – and this is where most hiring processes fall apart, because the skills you need at Insight and Present don’t show up on a resume. You can’t screen for curiosity with a technical assessment. You can’t test for business imagination with a coding exercise.

I’ve found that the interview itself is your best screening tool, but you have to ask the right questions. Not “tell me about your experience with Tableau” but “How do you evaluate and quantify value to the business?” Not “walk me through your analytical process” but “What key training did you need to become ‘smart’?” And my favorite: “How would you train your replacement?” That one separates the people who have internalized what they know from the people who are just executing a playbook.

I once asked one of my best project managers how she became the person everyone wanted on their toughest assignments. Her answer was disarmingly simple: “You just dive right in, and figure the answer out for yourself.” Standard training got her the basics – screen navigation, core workflows, where the menus live. But what made her indispensable was everything after that. The online help system. The knowledge base of previously answered trouble tickets. Google. She built her expertise by solving problems nobody assigned her, one question at a time.

That’s the pattern I’ve seen repeated across every successful data team I’ve built. The best people aren’t produced by training programs. They’re developed in environments that reward curiosity – where people have the ability, the permission, and the responsibility to answer questions and then follow up with a few of their own. You’re looking for folks who can see something odd in the data noise (a funny pattern in help desk tickets, a recurring process error, a trend that doesn’t match the narrative) and feel compelled to pull the thread.

You’re probably not going to find this in the same person who’s brilliant at data pipeline engineering. And that’s fine. You’re not looking for one person. You’re building a team where the business-curious analyst and the infrastructure engineer and the visualization specialist each bring their piece of the chain – and where they’re talking to each other often enough that the links actually connect.¹This is where Data Mastery and Team Dynamics intersect in the Building Blocks framework. The data capability is only as strong as the team that operates it.

The Next Question

Pete’s challenge has stayed with me through every data team I’ve built since that conversation. Not because it was complicated – it’s actually disarmingly simple. He didn’t want better technology. He didn’t want fancier dashboards. He wanted people who could look at information and get curious.

That’s what the Data Value Chain really measures. Not your data infrastructure, not your technology stack, not your analytics platform. It measures your organization’s ability to move from curiosity to insight to action – and it exposes exactly where the chain breaks. Most of the time, it breaks at the ends. Not because the people there aren’t smart, but because organizations haven’t invested in the skills that connect data to business reality on one side and business decisions on the other.

The good news is that you don’t need to find a purple squirrel to fix it. You need a team – a group of people with complementary skills who, together, cover all seven links. Some of those people you’ll hire. Some you’ll develop. And the ones you develop, if you put them in the right environment, will surprise you. Give curious people access to data and the permission to ask questions, and they’ll build expertise that no training program could deliver.

The framework has held up remarkably well since I first started thinking about it. The tools change, the platforms evolve, the buzzwords come and go – but the seven links remain. You still need someone who can ask the right question, and you still need someone who can make the answer matter.

What’s changing, though, is where the hard work lives in the chain. AI is starting to reshape the middle links in ways that shift the balance of the whole framework. But that’s a conversation for next time.

Want to build data capabilities that actually deliver business value? Join our community of executives and practitioners who are navigating Data Mastery and the other Building Blocks of a connected business. Subscribe to the Maker Turtle mailing list for frameworks, case studies, and practical guidance you won’t find in a vendor pitch.

Related Articles

• Data Science and the Art of Persuasion (HBR) – Scott Berinato argues that effective data teams need six distinct talents, including storytelling and design – a parallel framework to the Data Value Chain.
• 3 Ways to Build a Data-Driven Team (HBR) – Why the ability to ask the right questions matters more than raw technical skill when building data capability.
• Six Key Skills for Turning Data Into Insight (Grant Thornton) – A complementary take on the non-technical skills required for data-driven decision-making.

Recommended Books

• Storytelling with Data by Cole Nussbaumer Knaflic – The definitive guide to the “Present” end of the Data Value Chain: making data communicate clearly and drive action.
• Competitive Advantage by Michael Porter – The original value chain framework that inspired the Data Value Chain concept, applied to business strategy and competitive positioning.
• Don’t Think So Much by Jim MacLennan – Jim’s expanded treatment of the Data Value Chain, team dynamics, and other frameworks for navigating digital transformation.