Don’t Lead a Data Team Before Reading This - The First Chapter
Aligning The Data Team with Business Objectives
Hello all! This is Ben!
I wanted to provide a short preface for this specific piece.
As I have talked with multiple data leaders over the past few years, I have often heard that they felt thrown into the position of leading a data team. I have also noticed that there remains a disconnect between the data teams and stakeholders.
In turn, I wanted to put together a book that helps cover key concepts for those looking to either lead a data team or be a more impactful senior-level engineer(and beyond). This book will cover everything from working with stakeholders, picking the right solutions, managing vendors, growing a team, and so on.
Although I did title this chapter, “The First Chapter”, it’s likely more of a second or third chapter. The theme is focused heavily around stakeholders - how to work with them, identifying what they need, and actually deliver.
If you have led a data team, I’d also love to hear your stories and integrate them into this book.
Please feel free to reach out(you can respond to this newsletter)!
Also, I want to give a very special thanks to Veronika Durgin, Celina Wong, Shachar Meir, Jordan Cutler and Jeff Nemecek for sharing your thoughts: both for the quotes provided below, and the chapter itself. (If I missed someone, please do let me know and I’ll make sure to add you to the next one).
This is also the very first piece I am paywalling up front as it is a far more extensive piece. So if you’d like a discount consider using the special offer below.
With that, let’s dive in.
Imagine you’ve just been put in charge of a data team supporting a mid-sized e-commerce company. I speak from experience.
In this scenario, let’s say the CEO brought you on board. We’ll call her Rachel.
Rachel is in a tough spot.
The business is struggling, navigating difficult market conditions. Sales are down 30% year-over-year, and Rachel may soon face hard decisions, including the possibility of downsizing the workforce.
Hopefully, you’ve done your homework and quickly identified some of these challenges, thanks to your access to the data. But now, let’s throw in another wrench as you step in to lead this data team.
The data infrastructure is a mess — built on an obscure, free tool with no documentation (true story). And now, you’re being asked to deliver numbers. The CEO needs to know where to focus her efforts: Where can she start to recover lost sales? What projects can be cut?
She’s looking to you for answers, but in the current state, you can’t provide them. Can you tell her that it’ll take eight weeks just to address some of these basic data questions?
Does she even have that kind of time?
Yes, you’re struggling to access the data efficiently and can’t fully trust its accuracy. But, Rachel is in a totally different position—she needs actionable insights now. Telling her that it’ll take weeks or months to overhaul the data infrastructure and build a reliable data warehouse likely won’t fly.
But we’ll revisit this story soon.
Communicating With Stakeholders
When speaking to directors, CTOs, CEOs, or any leadership, it's crucial to adjust your vocabulary. You can’t approach these conversations as you would when talking to fellow individual contributors (ICs).
As ICs, we love getting lost in the weeds — debating whether Polars is superior to Pandas (or perhaps vice versa) or why parquet files are the only logical choice for file formats. We can easily get wrapped up in the nuances of defining semantic layers or debating the differences between a data warehouse and a data lakehouse. I even recall someone going to great lengths to argue that Airflow should only ever be categorized as a workflow orchestration tool, not a data pipeline tool (which is technically true), even though we use it as a data pipeline tool in practice.
And that’s the point I’m getting to.
When communicating with the business, focus on functionality rather than technical details. Picture the classic scene of someone pushing up their glasses and saying, “Technically…”
That’s you, getting caught up in the specifics of technology. And everything you say after that sentence will likely go over most people's heads — especially the non-technical stakeholders — who, frankly, probably don’t care.
In fact, it’ll likely frustrate and confuse them, which is a bad outcome for any data leader trying to bridge the gap between the data team and the business. That’s why this first chapter is dedicated to “The Stakeholder.” Whether you call them the business, the C-suite, or something else entirely, these are the individuals who manage operations, finances, and the core aspects of the business that your data team is focused on amplifying and improving.
I actually had one hand-off meeting with another consultant, who, on a call with a non-technical CEO started to get deep into the technical weeds. Suddenly we were staring at a SQL editor, and the consultant was trying to handle the fact that their Microsoft SQL Server had run out of a memory.
And that was on a call that was meant to be a high-level.
At the end of the day, the business doesn’t care about the underlying technology — unless it’s something they can show off to peers or use to boost their stock price by leveraging the latest buzzwords.
There is nuance to the argument “the business doesn’t care about the underlying technology”. But we’ll dig into that more as we go along.
Bridging the Business to Tech Gap Is Your Job
“Success will often mean interpreting business needs, communicating a clear direction, defusing a looming crisis, convincing teams to agree on tradeoffs, or just being a good influence.” ― Will Larson, Staff Engineer: Leadership Beyond the Management Track
Running a business—or any department outside of data—requires a vast amount of specialized knowledge. If you’re the CEO, you’re tracking competitors, industry trends, and internal operations. If you’re leading operations for a supply chain logistics company, you’re not just tracking metrics but also monitoring truck availability, target fulfillment, and more.
Now imagine if these stakeholders also had to keep up with every technological shift and the day-to-day operations of their data teams. It would be overwhelming, to say the least. That’s where you come in.
Your role is to help the business understand what’s happening within their data team and how technological changes affect the company’s objectives.
Remember, you don’t want to make your business stakeholders feel inadequate — they’re smart. They’ve likely spent as much time mastering their field as you have becoming an expert in data.
And consider this: the business could probably function without you more easily than it could without a strong director of operations. While your technical expertise amplifies the business’s efforts, you’re not the one keeping the core business running.
So don’t get frustrated if your explanations go over their heads. It’s your responsibility to meet them where they are. If they’re more technically inclined, feel free to dive a little deeper. If they aren’t, keep the conversation focused on high-level.
But don’t just take my word for it. One person I’ve enjoyed speaking with on multiple occasions is Jeff Nemecek, who, at the time of writing, is the Director of Engineering & Architecture at The Walt Disney Company. He knows a thing or two about bridging the gap between technology and non-technical stakeholders. In one conversation, he said that as a technical leader, you should:
“Explain things in ways that give an executive the ability to ask questions, tinker, suggest alternatives, ask intelligent questions without having to know the technological details.”
To add to this, I have noticed that many data experts I have talked to are constantly utilizing analogies to help make it easier for their business counterparts to understand what is going on.
Your goal is to help them understand what’s possible and what’s not. Part of your job is to educate your stakeholders — not just to get them on board with your ideas, but to empower them to contribute their own insights.
In one case I was working with a VP and used a very similar example as Celina Wong used in the video above. The VP was trying to understand what a data warehouse was and the role it’d play.
“You can think of it similarly to a physical warehouse where you might have multiple suppliers, in this case your various ERPs, CRMs, and other similar solutions, send all their data. That way we have it all the products in one place where people can find what they need(people being analysts and data scientists). We also will create some form of standardized inventory naming convention so the all the people that want to ‘order from us’ can easily understand what the products are. This avoids our analysts and data scientists from going to each supplier directly”
Is there a lot more nuance to what a data warehouse is. Of course. But it helped frame our discussion so they could move forward with some level of baseline that can then be used to make a more informed decision.
If all you do is bombard your stakeholder with technical jargon, you’ll end up with a few predictable outcomes:
Confused stakeholders who don’t ask questions because they don’t want to seem uninformed.
Frustrated stakeholders who know they’re smart and will blame you for poor performance or communication.
Indifferent stakeholders who never cared much about being data-driven and make your work feel pointless.
Instead, focus on finding a common language — one that elicits excitement for your business counterparts because it shows you understand what matters to them.
And just as importantly, what doesn’t matter.
For example, they don’t care about the nuances between a data lakehouse and data warehouse. So, how do you help them understand what’s going on within the data team?
Keep them in the loop with a general understanding of how the technical changes and technologies you’re deploying will impact the business. Not just in technical terms — what does it mean for the business? Will these changes enable better decision-making or unlock new possibilities, like implementing new machine learning models?
Your job is to bridge the gap between business and technology because, while you’re focused on data, they’re juggling dozens of other priorities that may overshadow yours.
A Rose By Any Other Name Is a Data Warehouse
I get it. We have spent years, if not decades, understanding the nuances between different technologies. When someone mistakenly uses the word AI when they really should have said machine learning, some of us get triggered.
Many of these terms of definitions have real distinctions between them that when used incorrectly have consequences.
But it’s also important to recognize that many of the terms, technologies, and even job titles we use in data have been heavily influenced by vendors and other parties with their own agendas.
Consider terms like PL/SQL and T-SQL, Data Lake houses, medallion architecture, and analytics engineers.
Now, this isn’t to say these terms are inherently bad. Often, vendors and consultants merely coined a term for something that was already happening. But sometimes, we end up debating semantics that serve vendors more than they benefit our company.
And that’s okay—sometimes, it’s better to use the closest equivalent term rather than overcomplicate things. For example, Facebook calls its data storage platform a “data warehouse.” Is it a traditional data warehouse? Not exactly—their dimensions don’t always align with typical definitions, and they often use data types like directories and arrays that aren’t standard for most data warehouses. But functionally, it behaves like one.
I’ve worked with several clients where the business side struggled to define their own data warehouse. No one wanted to look uninformed, so they danced around the term with phrases like.
“Our ODS, Data Warehouse, database situation.”
“It’s really more than just a data warehouse.”
This lack of clarity makes decision-making harder. Without confidence in basic definitions, even simple decisions become complicated:
What solution should we migrate to?
Who should we hire?
Are we investing in building the right infrastructure?
Will this infrastructure last?
Will we be ready for the next wave of technology?
So how can you bridge the gap between the business and data teams more effectively?
Avoiding Technical Jargon
If you’ve worked in technology for even a few years, you know we love creating new terms, paradigms, and best practices. So much so that even we can struggle to keep up with the latest terminology.
This constant evolution is part of our world; it’s unrealistic to expect the business side to keep pace with us.
A classic example of how jargon can confuse is a satirical piece called “Turbo Encabulator.” Here’s a snippet:
“For a number of years now…we conceived idea of a transmission that would not only supply inverse reactive current for use in unilateral phase detractors, but would also be capable of automatically synchronizing cardinal grammeters.”
If that left you scratching your head, don’t worry—that’s the point. It’s a perfect illustration of how technical jargon can be utterly meaningless to most people. It alienates your audience and discourages them from engaging further.
I believe the data team shouldn’t be the only ones who understand the data infrastructure, at least at a high level. That’s why it’s so important to avoid technical jargon in the wrong situations. As an experienced data leader, your goal is to use language that helps everyone understand what’s happening. You need to meet your audience where they are.
Examples Of How to Explain Technical Concepts to Business People
Jessica Iriarte, a Director of Data Science at several organizations in the energy sector, offers a great example of how to explain technical concepts to business people or stakeholders who may be in a different technical space.
The energy industry encompasses various roles— many of which are highly operational or engineering-heavy and less focused on data science.
When I asked Jessica how she communicates with these stakeholders, she shared a practical approach. Rather than saying, “The probability of X is 90%,” she reframes it in terms that resonate with her target audience. For example, “This model will be within 10 PSI 9 out of 10 times.”
This subtle adjustment makes her insights more tangible to someone who spends their day monitoring PSI and gauges. Instead of relying on a model and abstract probabilities, she speaks the language of her audience.
Another strong example comes from
er and ’s piece, How to influence with data as a software engineer. They emphasize the power of comparison in framing conversations. Two examples from their section ”Comparison to something familiar” are:Out of our six cost centers, infrastructure is 70% of the total spend. I think we can drop that number to 40% of the total spend if we invest in <x> area.
We could go on five company-offsites in Italy with the amount we’d save from investing in <x> area of our infra-spend.
As data people we don’t just want to talk about cost savings of course. We also want to discuss how landing a new feature or changing pricing could lead to an increase in revenue.
By shipping this one feature we will see +9% retention and +7% engagement, which would get us to our Q4 target.
Like Jessica’s example, these comparisons ground complex concepts into familiar contexts, making them easier for non-technical stakeholders to grasp. The key is tailoring your message to the audience, ensuring they connect with your insights and outcomes.
How to Identify What the Business Cares About
If your first thought upon leading a new data team is, “What shiny new toys can I use?”—you might be heading in the wrong direction.
Don’t get me wrong, we all love shiny new toys. However, they can easily become distractions from what the business actually needs.
In some cases, it’s the business itself that distracts us—throwing around buzzwords and demanding solutions that may not be necessary or that the company isn’t ready for.
That's why, as you grow as a data practitioner, one of the key skills you must develop is the ability to identify what the business truly needs. This becomes especially critical as you get closer to the CEO. They don’t have the time or inclination to understand every emerging technological trend or how it could impact the business. That’s your job.
Your role is to advise and consult, proactively explaining the impact of technological changes they’ve read about. They may ask why the company doesn’t have a real-time Large Language Model (LLM) generating embedded reports and automatically providing key insights.
At some point, you need to evolve from a task-taker to a strategic player. If you want to be part of the company’s strategy, you need to understand not just the technology but also the business—and how that technology affects the company and the broader industry.
But that's far easier said than done. In the next section, we’ll explore how to identify what the business needs and look at examples of how successful directors and VPs have done this in the past.
Ask Why
Too often, when the business requests a real-time dashboard, AI, or another technically challenging project, we jump at the opportunity. Us data and tech folk love complexity and challenges, and we relish the chance to build a system that uses 20 different cutting-edge tools and four design paradigms.
But in our excitement to finally use what we have learned, we often fail to stop and listen. We don’t ask the right questions and dive headfirst into implementation. A few weeks or months later, after deploying the solution we were asked to build, guess what? We discover that it doesn’t meet the business requirements because no one really understood what those needs were in the first place.
Why? Because no one asked why.
That simple question could have prevented a lot of wasted effort. Although I’ve emphasized “asking why” repeatedly in my writings, it is the key to elevating your projects. You need to understand what the business plans to do with the results of your project. If it’s a dashboard, ask:
Who will be using this dashboard?
How will it help them in their day-to-day operations?
How often will they look at it?
Is this dashboard or report for a specific meeting (e.g., a monthly or weekly review of key metrics)?
These questions give you valuable context for developing your system. Furthermore, business stakeholders might request features like real-time data, machine learning, or LLMs, all of which may or may not be necessary. You won’t know until you ask the right questions.
But don’t ask vague questions like, “Do you need real-time data?” The answer will always be yes.
Asking broad questions that don’t clarify what an end-user really needs won’t help. They already told you they want real-time data—now, how can you help them clarify what they actually mean?
Take Ownership of Your Work
If data professionals don’t want to be treated like a cost center or mere task completers, they must take ownership of their work. This starts with genuinely caring about the tasks you’re given and questioning requests that don’t seem to serve the business.
If you’re asked to implement something that you believe is a bad idea, push back and explain why. If you see opportunities for improvement that haven’t been addressed, take the initiative to bring them up.
For example, consider a restaurant struggling to meet its financial goals. You might start with the following flow of reasoning:
The restaurant is currently underperforming by X%.
It’s only managing 1.5x table turns per night.
Service is slow, and the chef is often away from the kitchen
Dishes aren’t being cleaned fast enough and the chef is often jumping in to help.
This analysis points to a clear business metric: the number of table turns. A sit-down restaurant’s revenue is heavily constrained by three key factors: the number of seats, the average bill per table, and the number of times a table can turn in a day (how many times a seat can be utilized). This is assuming a sit-down restaurant.
As we’ve talked about before, these are the business levers, at least for increasing revenue. The only ways a restaurant can boost its top-line are by increasing the average bill, the number of seats, or the number of turns.
By identifying these levers, you can better understand what the business truly cares about—metrics that can be further investigated to improve overall performance.
It might feel tedious to keep asking why and digging deeper, but this process is crucial to transforming your data team from a task-oriented group into a strategic player.
Listen More Than You Talk
For the data and business teams to be truly aligned, they must talk to each other. Let me take a step back—at the very least, the leaders need to be in frequent, meaningful conversations.
Now, as a data engineer by trade, I’m not suggesting we overload anyone with meetings. Work still needs to get done. After all, if you want to frustrate any individual contributor, force them into hours-long meetings where everyone pretends to be productive.
But if you organize efficient meetings with clear goals, you can accomplish a lot. Especially if you’ve just been hired as a director or manager of data. You’ll need to set up meetings with the business to understand their pain points.
As Data Advisor and ex-Director of Data Engineering Shachar Meir put it, you should spend most of your time in the early stages speaking with non-data people. This helps you build a solid understanding of the business and identify where your data skills will be most valuable.
After all, data merely represents a derivative of the business. If you don’t understand the business and its challenges, you’ll struggle to add value. At best, you’ll build infrastructure for infrastructure’s sake—bridges to nowhere.
That’s a costly mistake that could put your career at risk. While many of us individual contributors have a bias for action, take a moment to pause and understand the business, the people, and where you fit in the bigger picture.
Seeing the Bigger Picture - Understanding The Business
In an earlier section, I mentioned that it’s your job as the technical expert to help the business understand the data and technology. On the flipside, as a data leader, you need to understand the business.
You need to familiarize yourself with the industry’s acronyms, trends, and competitors. Get a clear view of the big picture. Whether that means proactively asking the business for help to fill gaps in your knowledge or diving into industry articles and reports, you need to own your understanding.
The best data leaders I’ve worked with could zoom out to see the forest while also zooming in to catch the crucial details in the day-to-day operations.
The earlier you can start understanding the business in your career, the better. For instance, during one of my first interviews, I was asked about my plan to get up to speed on the industry I was entering. They knew I had limited knowledge of the space, and they wanted to ensure I understood the importance of going beyond just the technical aspect.
In this case, I was going into healthcare, so during my first few weeks (and months), I not only dug into the infrastructure but also studied various articles about how claims work, how hospital billing functions, common coding practices, and key industry metrics.
As data professionals, we must have a solid grasp of what the business is trying to achieve so we can create impactful outcomes — whether those are metrics, insights, or data products that people will actually use.
If we only build based on what we are told, we limit ourselves to the business’s narrow view of the problem. That’s why it’s crucial to understand the company’s current challenges, how the industry is evolving, and what the key stakeholders are focused on.
Tactics And Practice
Here are a few more tips to ensure you get on the same page with the business while also making sure they are aligned with what you are doing.
Set Up Initial Interviews with Key Stakeholders: At the start of any project or when you begin a new role, schedule one-on-one interviews with key stakeholders to understand their specific pain points, goals, and expectations. I recall a finance director who was hired to turn around an organization I worked for early on and spent their first few weeks interviewing almost everyone (including me, a junior at the time). They made sure everyone felt heard and understood.
You can ask questions like:
What are the top three strategic goals for your department this year?
What activities or deliverables does your team produce daily, weekly and monthly?
Where do you see your department in the next 2-3 years?
What long-term goals do you have that this project or role can help support?
Are there any processes or systems that you find particularly inefficient or frustrating?
What do you expect from my role or this project to help your team?
What would a successful outcome look like from your perspective?
Also don’t be afraid to ask questions about the individual person. Like where they see themselves in a few years, what are their own goals, etc.
Be Transparent With Reporting Out Challenges And Successes: All projects will face challenges or obstacles. Be open and transparent about what your team is facing. It can be tempting to minimize project delays and technical issues. But that doesn’t help the project get unblocked.
Set Up Weekly or Bi-Weekly Meetings with Key Stakeholders: Schedule consistent meetings with stakeholders to ensure ongoing alignment and communication. These meetings can be used to discuss project updates, address any issues, and gather feedback, which should be stated in the agenda. I also really liked how Jordan Cutler added that you need to “ensure people know why they’re invited” to meetings. Don’t just hold meetings—own them.
Post Regular Updates on Project Progress: I started doing this at Facebook, as it helped my stakeholders keep connected with the project. I’d send weekly or bi-weekly progress reports outlining what has been accomplished, what is in progress, and the next steps. Whenever possible, include visual aids such as charts, graphs, and dashboards to provide a quick overview of progress.
Don’t Lead A Data Team Before Reading This - The End Of Part 1
Thanks for reading!
This is only the first 2/3s of this chapter. The next part is written and will likely be released in mid-September. I just didn’t want to overwhelm everyone as this is already pretty close to four thousand words.
As I pointed out before, I’d love to hear your thoughts and if you are interested in sharing a story that you believe should be integrated into this book please feel free to reach out.
Especially loved the callout from Celine when communicating to nontechnical stakeholders, "Make it fun." The examples she gave were great too, trying to use analogies from the physical world that everyone understands to make the "virtual world" make more sense--like the lemonade stand example.
Thanks as well for shouting out the High Growth Engineer article on influencing with data (https://read.highgrowthengineer.com/p/influence-with-data-as-an-engineer) too, Ben 🙏
I remember using a similar example about "how many company offsites we could get" for how much money we're unnecessarily losing on our infra bill as an example of doing something similar to what Celine was suggesting. But I also liked the high-level point of "making it fun."