Don’t Lead a Data Team Before Reading This

Recently, I heard 2-to 3 data leaders say that the default state of most data teams is failure. But I don’t think most data teams are set up for success to start with(I also don’t believe that failure is the default state).

I do however, find that many data engineers, analysts, and scientists get thrown into the role of Head of Data or perhaps director and don’t get much in the way of coaching or advice. 

There is just the expectation that we will do a good job because we were a good individual contributor.

So I wanted to start to put together a list of what you need to know and do to be successful as a leader in the data space.

This ranges from taking even more time to understand the business to being intentional on how you hire and place talent.

So if you’re thinking of leading a data team or perhaps already are this is for you!

Understand the Business

If you're doing these in any sort of priority order, this should be number one. - Tom Rampley Head Of Data At LastPass

There’s always been a lot of talk about the business needing to become data fluent and not enough talk about how data professionals need to become business fluent. 

How?

You must talk to and understand the business while doing your own research on your industry operates. Someone has to act as the liaison between the business and data, and it's likely going to be whoever is in charge of the data team. Otherwise, you'll have a hard time building what the business needs.

Yes, the business should have a light understanding of how to read charts and understand some basic data concepts.

But there is a line and it’s probably easier for a data professional to learn more about how a sales funnel works or how a patient is processed in a hospital and how that translates into the data. You’re literally staring at the data that is a derivative of the business.

To add a little more in terms of understanding the business. I really liked this comment that Veronika Durgin had about making your data team irreplaceable.

Data teams become critical and irreplaceable when they are working on critical company initiatives - Veronika Durgin VP of Data at Saks

If you want to be part of company initiatives and not just be an ad-hoc help desk, you’re going to have to get into the weeds of what goes on in the business.

In the end, the business won’t be getting into the weeds of how your data infrastructure works.

The Business Doesn’t Care About How You Solve the Problem

“Never talk about data technology, infrastructure, or queries with people outside the data team -- they just don't care.” -  Ethan Aaron CEO of Portable

Never is perhaps too strong. There is, as often in many topics, nuance.

Jeff Nemecek the Director of Engineering & Architecture at The Walt Disney Company made a great comment here covering some of that nuance, stating that:

Instead of using a vendor reference (Snowflake, Kafka, AWS, S3, Airflow...) speak of functions (data warehouse, streaming events, process orchestration, data pipeline) in ways a business person can connect with. The purpose is to help them understand the complexity of your work with clarity, not confusion. Why is it going to take a month to get the new product line integrated into the daily reports? They often need to understand the functional steps, but not the details of the underlying technologies.

I’ll add a few follow-ups. First, make sure everyone is on the same page in terms of what the words you use mean. I have seen teams struggle to move forward with projects because no one clearly defined what they meant when they were referencing their Postgres instance.

Was it a data warehouse, ODS, a database. I heard every term get thrown around. Not everything fits into a perfect box, so sometimes you just need to define it, its general function and move on. 

Second, just to make a point clear,  if you ever have to open up an IDE or start explaining why a query doesn’t work with the C-suite on the same phone call, you’ve likely f*cked up.

When you speak to the business, it’s not about you and your technical problems. The business wants to know what you’re doing to move the project forward, to drive the outcomes they are looking for you to help them look good in front of shareholders or their boss, and everything you think is important isn’t (unless you’re blowing up your cloud bill). Then they are suddenly going to ask you about specific technologies.

Overall, you need to communicate with the business about what the business cares about, this means the functional components and business outcomes. You still want the executives to be able to ask questions confidently without needing to understand all the technical details.