The important purple people outside the data team

When to bring people from around the company into the data team and what to consider before doing it

Some of the best hires I’ve made have been people elsewhere in the company who’ve wanted to move to a data role. They may work in customer support and have become the go-to person for data related questions in their team. Or they may work as an account manager and have built superb dashboards used by everyone in the sales team.

These people bring a unique combination of having a deep understanding of the business and a drive to learn about data. And you’re in luck - in many cases they want to make a move to the data team.

They naturally align themselves well to solve real problems that drive ROI for the business. They understand the impact of automating a tedious process around scoring customer health because they know how painful it was to do that manually. And they understand why a 3-month project to measure the impact of a marketing campaign on sales doesn’t make sense because the sales teams systematically don’t log calls on time.

You likely find yourself working with some of these people and may have already made an effort to integrate them into the data team.

Wherever you fall on the scale, I recommend being deliberate about how you work with them to create the best outcomes for the data team and to give them the best opportunities for career growth. When done well, they will function as extensions to the data team, help solve important problems and handle ad-hoc requests.

Practical tips for creating success with people outside the data team

Start by mapping out who these people are. If you’re in a management role you can ask your team and they’ll know.

I’ve found these steps to work well

• Map out everyone doing data-like work outside the data team and have your team select which ones have the most impact and are most eager to learn

• Invite a few to be part of data team rituals. Give them a mentor on the data team and invite them to your offsite and weekly team meetings. This gives you a better sense for how they work and gives them a chance to learn

• If it’s a good fit on both ends and their manager agrees, you can consider bringing them onto the data team. If you do, I suggest doing a 3 month probation period where clear expectations are set 

If you find this working well, consider making it into a more formal data rotation program that anyone can apply to.

Common pitfalls when bringing in people from outside the data team

Unfortunately it doesn't always work out when people are brought into the data team. I’ve seen a few common pitfalls that you should be on the lookout for as early as possible

• They have a hard time letting go of the work from their old role and keep getting bogged down by DMs or operational work from previous stakeholders

• They struggle to change their mindset, don’t take the time it takes to learn to do things the right way the first time around and end up cutting corners

• They don’t have the right level of support in the data team and are not onboarded well

Be sure to do what you can to ensure they’ve the best possible setup for success and use the 3 month probation period to raise feedback with them early on so they have a chance to improve.

What happens when you have entire data-like teams outside the data team? 

Engaging and bringing in people to the data team is a win-win. If done right, you’ll get a lot of value and help eager and ambitious people make a move into data. 

The situation is more complicated when you start seeing entire teams outside of the core data team who are doing data-like work. These people are often brought in to do business critical work such as making the forecasting model that determines which support agents should work when or building data models to determine the credit score of customers. 

If done wrong, these teams bring the risk of deterioration the reliability of data and can lower the quality of decisions made across the company. 

Data reliability is only as strong as the weakest link in the chain. 

You can think of it as an equation:

Data reliability = lowest(upstream data quality, data model quality, dashboard quality, …)

In the example above you could have a situation where

• Rigorous logging of calls in the CRM (sales team)  = high →

• dbt models with high test coverage (data team) = high →  

• Scrappy LookML code with logical errors (sales ops) = low

Regardless of the quality of the upstream and data modelling layer, the data used to make decisions is low as quality is only as strong as the weakest link.

In the same way that you can’t build reliable data on top of flaky data from upstream producers, you can’t confidently rely on data-driven decision making if decisions are made with downstream teams not following the standards you expect. 

“Data-like teams frequently work on high importance business problems but too often the data team is not informed or involved in their work. Sometimes senior stakeholders circumvent the data team to move faster but end up creating long-term data debt”

It’s important to mention that in no way should data work be exclusively for people in the data team. In fact, the more people that engage in data work the stronger a data culture you have. However, you need to be clear of where you expect high quality. That may mean that you create a rule that for the most critical use cases of data, the data team needs to at least be informed. 

How to spot teams doing data-like work

Here are some signs you should look out for to spot teams that you might want to bring in closer to the data team.

A group of sales ops analysts making dashboards with scrappy LookML code used by hundreds of people without the data team being aware of it.

An operations team maintaining a forecasting model that determines when the shift of workers starts and ends built in Pandas, being run manually each morning on a local machine.

A business strategy team that decides to use Google Data Studio for a dashboard for investors because someone used it in their previous job although the data team policy is to use Looker.

A credit analyst team who’ve started to develop their own dbt project for data models used to decide which customers are allowed to borrow money.

Before you know it, business critical decisions will be made by people using dashboards and data models that the data team had no idea existed.

You need to build a system for when teams and individuals should be in the core data team and when they should remain independent. 

High overlap: You risk ending up with a mess that will eventually come back to the data team to fix. You should consider making them part of the core data team with the same expectations and onboarding you’d have for anyone else.

Some overlap: The quality of data and decisions heavily depend on them but the work is too different from what the data team does. Invite them to some of the data rituals and pair them up with a mentor from the data team.

Little overlap: It’s great that they’re building their own dashboards but you shouldn’t invest much time here as you risk spreading yourself too thin. Instead, offer to do office hours and a monthly training on Looker best practices.

If you’ve experience with how to best bring in data-like people from outside the data team and create a chain of reliable data, I’d love to hear from you