From Average To Exceptional: 5 Skills To Help You Become The Data Expert Everyone Wants To Work With

Hi, fellow future and current Data Leaders; Ben here 👋

Today's post is a guest post from

Torsten Walbaum

, a former manager at big tech companies and Director at Rippling. Torsten also writes the newsletter Operator's Handbook where he shares in-depth guides on analytics and operations topics.

Collaboration between business and data teams is hard. Torsten has been on both sides of the equation, giving him a unique perspective on what makes some data folks more impactful than others.

In this post, he's sharing 5 key skills that will help anyone in data stand out and work more effectively with their business stakeholders.

Now let’s jump into the article!

---

Intro

A data team’s central purpose is not to do data work, but to drive business value through data.

Over the last 10+ years working at companies like Uber, Meta and Rippling, I have been on both sides: I was a “stakeholder”—running business teams relying on data teams for support—and I was leading teams of analysts and data scientists working with the business.

The hard truth I’ve come to realize: The value created by the data team is typically not equally distributed. Instead, a handful of stand-out individuals deliver most of the business impact.

Managers start to give all high-impact strategic projects to these individuals, and cross-functional stakeholders directly approach them instead of going through the official intake process.

As a result, these are the folks that get promoted quickly because they have broad support from business leaders in addition to their own managers.

So the question is: What do these people do differently? And how do you become one of them?

This post aims to shed light on what makes some people in data an order of magnitude more impactful. And more importantly, how you can apply these same behaviors on the job (as an IC, or by teaching your team).

To do that, we are going to cover 5 key skills and behaviors incl. detailed real-life examples for each one.

Skill #1: Always work backwards from the problem

Many data people think business teams just want someone who builds what they ask, reliably and quickly.

But over time, you’ll realize that business stakeholders often don’t actually know what they need. They deeply understand the problem they’re facing, but they lack the technical training to translate that into data & analytics requirements.

It’s your job to understand the business problems behind stakeholder requests and find the best data and analytics solutions to solve them.

This is crucial if you want to be viewed as a strategic thought partner instead of just an (interchangeable) execution resource.

Let’s look at an example:

Imagine you work at Uber, and a stakeholder asks you for a real-time reliability dashboard to manage their markets. Now, you might be tempted to start brainstorming ways to build that real-time data pipeline.

But you should first dig deeper into the use case:

If you stop here, the request might actually seem reasonable. Supply and demand in Uber’s marketplace change in real time, so real-time information seems helpful for balancing it.

But real-time data can be expensive and hard to get, so you should get more context before you proceed. Once you ask for details on the process, you realize that things are easier than you thought:

So based on what you learned, a few hours of lag in the data won’t affect your stakeholder’s ability to run their daily process; they’ll still have yesterday’s data available in the morning. No need to build a real-time dashboard.

I cannot stress this point enough. In the example above, if you had just built what the stakeholder asked, you would have over-engineered it.

But in many cases, you’ll end up building the wrong thing because you don’t fully understand the business use case.

For example:

• The data team starts building an attribution model by looking at the available data and thinking about modeling techniques instead of checking what decisions the Marketing team will make with it

• Data scientists and engineers start debating what features and data pipelines to engineer for a lead scoring model without understanding what kind of model output would be useful for the Sales team

In these cases, months of work can end up going to waste because your deliverable doesn’t address the business need.

Skill #2: Use frameworks to create clarity

One of the most painful experiences for any data person are ad-hoc investigations into metrics movements.

At Meta, we were doing a lot of these investigations even into seemingly small fluctuations. At a scale of billions of users, this can translate into a massive monetary impact.

The business was complex, so we had to pull in many different teams and stakeholders to get all relevant context. Unfortunately, with many cooks in the kitchen, investigations often end up sounding like this:

And so on.

The main problem here is that everyone is just guessing. Without a proper structure, there is no guarantee you’ll find the root cause. And even if you do, you can’t replicate that success in the next investigation.

In this case, a simple issue tree (one of the most useful general purpose frameworks) can help bring structure into your investigation:

There isn’t a single correct way to decompose an issue. The important part is that:

1. You use a structure at all. That way, you can get everyone to think about the problem the same way and keep track of what you already investigated

2. Your structure is MECE (Mutually Exclusive and Collectively Exhaustive). That means it covers all possible options, and none of the options overlap

With the structure in place, nothing can throw you off track.

• A stakeholder brings up a new hypothesis? You can quickly check your issue tree and either add it to the right step of the investigation, or show them that you already ruled it out

• Leadership asks you when you will have an answer? You can see how many branches in your tree you still need to check and give them an estimate

Skill #3: Reduce complexity

Once you embrace the fact that all data work is ultimately supposed to drive business impact, you realize that anything that distracts or delays you from realizing that impact should be eliminated.

It can be tempting to want to highlight the complexity of our work. If nobody realizes how complicated this all is, how can we get credit for it?

But the reality is that people are either Simplifiers or Complicators. And Simplifiers will be rewarded for making people’s lives easier, while Complicators will be sidelined because people avoid working with them.

So, how do you become a Simplifier?

Avoid technical jargon

Using technical jargon makes it difficult for business stakeholders to understand you.

It doesn’t matter whether you use the terms correctly; if the other person doesn’t know them, there is a chance they’ll misunderstand you. And most people don’t want to show their lack of knowledge, so they likely won’t ask you to clarify.

So: Whenever possible, say what you want to say in plain English (and simple sentences).

Boil it down to the essentials

Your business stakeholders are busy. When they ask for a data tool or dashboard, it’s typically to make their lives easier and save them time.

If you respond by bombarding them with detailed analyses, difficult trade-off decisions etc., they’ll feel like you’re making it harder for them instead.

Here are a few things you can do:

Use simple visualizations

When you’re working on a system all day, it’s easy to forget how confusing it must seem to outsiders.

For example, in my last job, my team and I got asked to do growth and analytics work for an automated email system. From lead ingestion to enrichment and finally allocation to different email sequences, the system was complex — and there was no visual overview of it.

This caused a lot of confusion. Different teams had different levels of understanding of what was going on, and there were a lot of misconceptions.

The first thing we did, before doing any “actual” work, was create simple flow charts that showed the system end-to-end. For the first time, everyone had a shared understanding, and for months we kept getting unsolicited positive feedback from stakeholders.

Streamline choices

Sometimes, you need your business stakeholders to make decisions on how to move forward.

When you’re presenting them with a decision like that, don’t lay out all options and considerations in detail. That will just confuse and overwhelm them since they lack the necessary context.

Instead, do the legwork on your end to eliminate as many options as possible. Then, present the final decision with a focus on the business implications, not the technical details:

Skill #4: Communicate effectively

Even if you’re using simple language, communication between data and business teams is often challenging. But there are some simple tricks you can use to address these problems:

Communication best practice #1: Focus on the “so what?” and use the pyramid principle

When you’re communicating with stakeholders, you shouldn’t focus on what you find interesting to share, but what the other person needs to hear.

To make sure you get your message across, you should lead with the takeaway (the “so what?” of your message) and then add supporting arguments and data.

Besides making it easier for the other person to follow your thought process, you immediately seem more senior by adopting this executive communication style.

Communication best practice #2: Keep stakeholders in the loop

Data teams often feel like a black hole to business partners. You throw a request in their direction, and then you don’t hear anything for weeks.

Business stakeholders are the ones that are ultimately on the hook for hitting goals and metrics targets. So if they are waiting for the data team to do an analysis or build a tool and they don’t have any visibility into the progress, they get anxious.

• Are you actively working on the project?

• Are you building the right thing?

• Will it be done in time?

To address this, proactively send them regular brief status updates (e.g. via Slack):

There will be several immediate benefits:

• Your stakeholders don’t have to constantly check in, making both your lives easier

• People see that you’re “on top of things” and will trust you with larger, more complex problems

• You can use the check-ins to get feedback on early drafts of your work to make sure you’re going in the right direction

Skill #5: Be pragmatic and make things happen

Many data people tend to be sticklers for accuracy and best practices.

For example, let’s say the business needs an analysis to answer a critical question within a week.

Knowing a proper analysis would take a month, a mediocre data person would insist that the request is unreasonable and spend the week debating the timeline instead of delivering something. As a result, the business would have to move forward without any analytical guidance.

A great data person, on the other hand, will find a “good enough” workaround to unblock the effort. They'll highlight the caveats and have a plan for a more robust follow-up analysis (if needed).

Our job on the data team is to help find the least bad solution within the constraints of the business. This doesn’t mean that we should ship work that we know is flawed to the point of being unhelpful, or completely ignore the scalability of what we build.

But it means that instead of insisting on the “perfect” solution, we have to be flexible and adjust to business realities. If you do, people will notice.

In one of my last jobs, I was in a calibration meeting. When it came to discussing a Senior Data Scientist and their “Exceeds Expectations” rating, we didn’t need much time. Everyone knew him as someone who simply got stuff done.

A Senior VP literally said “I’ve never heard him say ‘That’s not possible’”, and that settled it — the rating was approved.

Making things possible beats being “technically correct” every time.

TL;DR

Technical skills are important when working with data. But those that create outsized business impact, and become the data person everyone wants to work with, also stand out in other areas.

1. They always work backwards from the problem

   1. Deeply understand the problem your business stakeholders are facing before diving into technical solutions

   2. Then, once you understand the use case and requirements, help them identify the best solution

2. They use frameworks to create clarity

   1. For example, during investigations, use a structured issue tree instead of chasing random hypotheses

3. They reduce complexity

   1. Avoid technical jargon whenever possible

   2. Use simple visualizations to get a shared understanding of the situation

   3. Make decisions easy for your stakeholders

4. They communicate effectively

   1. Lead with the takeaway, then add supporting arguments and data (AKA the “Pyramid Principle”)

   2. Proactively keep your stakeholders in the loop on your progress

5. They are pragmatic and make things happen

   1. Instead of listing out all the difficulties of a project, focus on how you can make it work

   2. Offering a compromise / “least bad” solution is better than blocking the entire work stream

As always, thanks for reading!

---

Video Of The Week - Is It Time to Say Goodbye to Data Engineers? - The Data Engineering Dilemma

---

Join My Data Engineering And Data Science Discord

If you’re looking to talk more about data engineering, data science, breaking into your first job, and finding other like minded data specialists. Then you should join the Seattle Data Guy discord!

We are now over 8000 members!

---

Join My Technical Consultants Community

If you’re a data consultant or considering becoming one then you should join the Technical Freelancer Community! We have over 1500 members!

You’ll find plenty of free resources you can access to expedite your journey as a technical consultant as well as be able to talk to other consultants about questions you may have!

---

Articles Worth Reading

There are thousands of new articles posted daily all over the web! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!

---

The Tension of Orthodoxy and Speed

By

Joe Reis

Doing things “the right way” means being thoughtful and intentional in data modeling. This brings us to orthodox and conventional data modeling approaches. There was once a process that nearly everyone followed - intentional conceptual and logical modeling, having a shared vocabulary, modeling the business, and translating these models into a physical data model. The relational model has been the mainstay for transactional data used in applications since the 1970s. In analytics, Kimball’s dimensional model is the most popular approach, with Data Vault also prevalent in some areas. All of these approaches have an established way of handling data. There’s a “right way” to relationally or dimensionally model data. Each approach has a framework, a vocabulary, and a goal. Follow the convention, and you’ll have a data model that’s understandable by many people, performant (most of the time), and with minimal defects and higher quality. The latter point is key since higher quality often leads to the ability to move faster, as discussed a few months ago in The Quality Paradox.

Read More Here

---

End Of Day 164

Thanks for checking out our community. We put out 3-4 Newsletters a week discussing data, tech, and start-ups.