Data Teams - Work Smarter, Not Harder

A Guide to Reducing Team Workload While Increasing Data Quality

Throughout my career, I’ve worked on a few different data teams, each of them being very different in how they operated. Some teams moved way too fast, sacrificing quality. Some teams worked too slowly, not driving nearly as much impact as they could. It’s a fine balance to strike- producing high-quality work that leads to actionable business decisions and building a data stack that can scale well into the future. 

Luckily, I now work on a team that has found the sweet spot. We build data models and dashboards that can scale as the business grows while prioritizing what the business needs most. I’ve found a few major differences between the most efficient data teams and the ones experiencing burnout and low productivity. 

1. One is reactive and the other takes time to pause and ask clarifying questions.
2. One prioritizes stakeholder requests while the other prioritizes foundational work.
3. One codes wherever metrics stakeholders ask for, and the other takes the time to streamline metric definitions and business language.
4. One empowers stakeholders to find answers to their own data questions and provides them the resources to do so, while the other doesn’t.

If you can focus on these three points- being thoughtful in your questions, prioritizing foundational work, creating a shared language, and empowering stakeholders to be data-driven- then you can quickly increase the quality and impact of your work while reducing your data team’s workload. 

Stop being a yes person and learn to ask more questions.

It’s easy to say yes to every Slack message asking if you can pull a piece of data, or add a field to a reverse ETL sync. However, seemingly small tasks like these end up eating away at analytics engineers’ and data analysts’ focus time, leaving them no time to do the planned, foundational work. Requests for additional dashboards or data fields added to tools like Hubspot end up creating more tech debt that someone will later need to take time to clean up. Doing things fast only creates more work in the future, when it should be the opposite. 

When we say yes to requests without thinking through long-term implications, we create a messy data environment in which stakeholders quickly lose trust. We rush to complete all of the small tasks we agreed to have done by a certain date, neglecting the quality that comes with taking our time and being thoughtful about the work we are doing. While this makes you look efficient for the time being, it only comes around to bite you in the butt when an unexpected error pops up due to a lack of oversight (trust me, I’ve been there!).

How can you fix this? Start slowing down your response time, pausing before answering a stakeholder question. Think through the problem they are asking about and ask any clarifying questions that help you get to the root of the request. 

For example, if a stakeholder asks you to add a dashboard showing the number of customers that have converted on a certain social media ad, ask the following questions in return: 

• What problem are you trying to solve?
• What solutions have you already tried? What did you learn from them?
• Is this a one-time thing or something you plan on using long-term?

These questions will help you learn more about the problem, the different solutions available, and what they have or haven’t already looked at. Sometimes, what the stakeholder asks for isn’t the most optimal solution! It doesn’t make sense to blindly complete a request when you are the resident data expert. Your expertise is appreciated and expected, so make sure you take the time to understand the problem they are solving. 

Taking the time to pause and ask questions also helps weed out “nice to have” requests from those essential to doing business. Stakeholders won’t want to answer too many questions about a request if it’s not vital to their work. 

Find a balance of foundational work and ad-hoc requests. 

Data teams often feel burnt out because they’re saying yes to too many ad-hoc requests and not focusing on the work that excites them and really moves the needle. I’ve seen too many hardworking, smart managers get burnt out because they’ve taken on too much, promising everything to everyone. Not only is it overwhelming to have every stakeholder coming to you with all of their problems, but it can leave you without a sense of purpose.

As data people we want to be solving challenges and building a better data stack, but this is nearly impossible when you're bogged down in ad-hoc requests. No engineer or analyst wants to feel like they aren’t contributing to creating a better data culture within an organization. 

Data teams only make true progress when they make time for the foundational work that matters 3-5 years from now. Foundational initiatives include:

• Building out a reliable data stack
• Coding core data models to power reliable metric calculations
• Documenting everything being built
• Building efficient data pipelines

If these efforts aren’t prioritized, they will naturally fall to the back burner and you’ll wake up years from now wondering what happened to all of your plans. How do you prioritize foundational work over ad-hoc requests? Create a sprint planning system where half of the tickets assigned to your team are ad-hoc requests and the other half focuses on foundational data work. 

Planning (and sticking with the plan!) is the key to success when prioritizing the right tasks. Use a planning system that works for your team and ensure that you stick with the allocated percentage of ad-hoc tasks vs foundational tasks; I think 50/50 works great. Move additional ad-hoc requests to the backlog and do not add them to the sprint if you are already at your capacity! 

With this new system comes a culture shift in how other teams interact with the data team. It’s important to communicate this with your stakeholders so they understand why you need to do this. Help them to see the future of data within the company and how these initiatives will make working with data easier for everyone. 

When my team switched to this same system, we were able to finally begin building out core data models that we’d been wanting to focus on for years. This planning style finally gave us the heads-down focus work that we needed to really make strides in how our data stack powered the business. Now, we are almost finished building out two core data models that will give the business reliable insights that they’ve never been able to get in the history of the company. 

Urgent requests that were unplanned will still come up. When this happens, communicate tradeoffs, emphasizing that this new task will replace another planned task. Ask the stakeholder what is more important, putting the decision of what you work on for them in their hands. 

Prioritizing foundational work pays off! It may take some time for stakeholders to see it, but when you deliver something valuable to them, they will understand why you had to change the way you were working. 

Dedicate time to streamlining metric definitions and business language.

A lot of the back-and-forth meetings and Slack conversations that we know all too well stem from the lack of a shared language between teams. One team can define a metric differently from another team, leaving the data team confused about how to code a single source of truth. This makes it impossible to provide high-quality, reliable work or leaves metric sprawl in dashboards, creating distrust in the data. It’s a lose-lose situation for everyone. 

How do you cut down on all the back-and-forth? Set up a meeting with leaders from each business team to talk about your North Star metrics, deciding on a single shared definition. 

Instead of continually going back and forth like a boomerang, wasting everyone’s time, bring the right people in the room to talk about your most popular metrics. Have everyone write down what that metric means to them and then discuss the differences. 

Simply bringing different perspectives together can provide a lot of clarity on how something should be defined. Taking the time to do this upfront, before a certain ask pops up or someone inquires about two numbers not matching, will save you loads of time communicating back and forth. 

Many teams simply lack the time and space to have conversations like these. Since data teams typically sit at the center of an organization, they are a great team to help facilitate it. They get a chance to ask all their questions while stakeholders have a chance to bring up their concerns with how others are defining a certain metric.

This exact conversation was key for how we defined an active subscriber. Growth, marketing, finance, and engineering all defined an active subscriber differently, making it impossible to provide data that made sense to all teams. Taking the time to settle on one definition gave all teams the clarity they needed to move forward in their work and made the data team’s job a lot easier when it came to providing the necessary code to support this. 

Provide stakeholders with the right tools and documentation. 

It can be easy to want to oversee everything that happens with data within an organization, as data teams know best the things that can go wrong. However, if you don’t want to feel overloaded by a bunch of small data requests, you need to empower your stakeholders to use data to answer their own questions. Not every small ask needs to go through the data team, as that is not sustainable for a team focused on building a solid data foundation. 

Teaching stakeholders to be data literate requires work upfront, but it is work that has infinite pay-offs in the future. It’s important that you start by asking them what they’d love to do on their own and getting a good grasp on where they are at. Some stakeholders may feel comfortable with basic SQL while others prefer Excel. Some may not feel comfortable using either tool! This will help show you what’s possible in terms of self-service analytics. 

How do you empower stakeholders to use data once you understand where they are at in terms of their data literacy? Document data in a way stakeholders can understand, giving them access to the documentation and teaching them how to use it. Choose a tool that gives them what they need to feel comfortable using data.

I’ve found that many of my stakeholders are comfortable using Excel but find it too slow for all the data they want to use with it. Gigasheet is a data tool with an Excel-like interface that allows stakeholders to get the insights they need on large volumes of data. It gives them the flexibility to explore data in the way they are most comfortable with but also provides safeguards like data governance that prevent any data from being deleted or overwritten.

Gigasheet is powerful because it connects to data warehouses like Snowflake, Databricks, and Redshift, still giving full control to the data team while providing flexibility that enables stakeholders to get the answers they need, fast! 

Conclusion

On my previous data teams, I was constantly fighting fires only to never move the needle in an impactful way. We were giving the business everything it needed yet still falling short due to the lack of core data products we were providing. Now, following these principles, my current team has made more progress than ever while increasing the overall satisfaction of the team. 

Remember- work smarter, not harder. Follow these three principles and you can see a similar return on your efforts:

• Pause to ask questions
• Balancing foundational work with ad-hoc requests using sprint planning
• Create a shared language between all teams 
• Empower stakeholders to find their own answers using tools like Gigasheet

With these changes, our team has made more progress in the last year than in the last five. We’ve achieved: 

• Less burnout and more focus time 
• 3 core data models that give stakeholders metrics they can trust and we can confidently explain
• More confidence in the data we provide stakeholders in dashboards and external tools 

When you work strategically, you’re able to accomplish more in less time and with way less stress.