We could start by defining the types of roles that should exist in your data practice: a Data Engineer, BI Developer, Business Analyst and a Data Scientist. Arguably, that’s a bad premise. These roles often intertwine, resembling a Venn diagram, and are more intricate than one might initially perceive.

Building a data practice tends to be biased more heavily on organizational composition, rather than the technology. The issue lies not in the tools themselves but rather in the human aspect of the equation. A plethora of tools for handling data tasks is readily available, and the landscape has witnessed a significant expansion in recent years. The challenge is how to effectively use people in the space.

Purple people

“Who are the purple people?” Anna Filippova has an excellent blog We the purple people that identifies purple people (which was in turn inspired by Thomas H. Davenport.  

“The business people, the actuaries, know what data they need and can define requirements, but typically don’t have the skill set to design a data architecture that gives them the data they need. Technology people typically don’t understand the business requirements, but they can design the data architectures. It’s like the people in IT speak blue, the people in business speak red, but we need people who speak purple in order to create an appropriate solution.”

Building a successful data practice depends on having the right amount of purple in your team. The most valuable asset good purple people can bring is an understanding of what business is trying to do broadly.  They interview the people, and simultaneously interview the data. They create quick dashboards to understand the size and scope of the problem. They seek to understand before being understood. They form the linchpin of your team. These people are not inherently technical.

Of course, you still need data engineers or programmers to build data pipelines, integrations, and move things around. Frequently, those people don’t understand what they’re moving around, and that’s ok as their main priorities is to build reliable, scalable data pipelines.  

Request intake

We’ve seen it, when an answer is provided, five more questions are asked. So, when the floodgates open, how does your team keep up with demand? This depends on what the type of requests, and how mature the request is. Your business might task you with automating numerous Excel reports or streamlining manual backend processes. You might be called upon to enhance an existing report, typically with well-defined requirements. Meanwhile, they may also be asking “why did we lose revenue in this category”, which may be a new concern and a question that’s never been asked before. That’s where your purple people come in. The crux of it, is that you need to accommodate requests that are both exploratory, and break/fix in nature. The worst scenario is that if you take too long to provide an answer, the business will simply estimate the answer by other means and stop asking the questions.

Trust

There can’t be any business function without trust.  Building trust in a data practice is especially hard, often because data is the product of what and how people accomplish a task. Change the people, the data will change. Change what problem they are trying to solve, the data will also change. The objective of a data practice is to foster trust and create a feedback loop. After all, the data your team is dealing with is not theirs, but rather belongs to stakeholders in the business. A highly effective approach to cultivating trust involves consistently providing early and frequent feedback to business stakeholders on their data. Persuade them by showcasing the potential possibilities. You must persuade individuals that relinquishing control is in their best interest. How can you exert influence without accountability?

Value of data  

Data is most valuable at the intersection of different data sets. A deeper understanding of your business emerges when you integrate operational and accounting data, surpassing the insights gained from examining each component in isolation. While that might seem obvious, what’s not obvious is that the people who use those systems have different context, and different drivers. They may do things to accomplish immediate tactical goals for their business unit, and in doing so, break the shared insight of the organization.

Time to insight – How long does it take to get an answer, and how quickly can we get better?

What makes data different

Just as software has a distinct set of principals upon which teams execute (agile, storyboards, standardized test, DRY), data projects have their own unique set of challenges. Data projects look and smell like software, but the principals are adjacent, and are not the same. Often, data can be thought of as exhaust, where it’s simply a product of what the people in your organization are doing. Considering data as an asset offers a more effective perspective, allowing for more conscious and improved management practices.