Stakeholders: The most important relationship for analysts

Why managing your stakeholders is one of the most important (and overlooked) things analysts can do

One thing trumps everything else for the happiness and success in an analyst role; the relationship with your closest stakeholders. Tristan, CEO of dbt, wrote an article a few weeks ago where he had the realisation that he’s now a stakeholder to the data team. This topic has not had nearly enough discussion.

Having spent the past ten years working in data teams I’ve experienced the importance of the relationship between analysts and their closest stakeholders first-hand. Typically, it’s just one or two stakeholders that really matter. If you’re an analyst, you know who they are. Most often they lead your business or product area and have the ability to make decisions.

From the analyst's point of view, stakeholders can be awesome, awful, difficult, easy and everything in-between. The good ones make sure your work has impact, give you frequent feedback and share your work across the company. The difficult ones swamp you with ad-hoc requests and endless questions that never go anywhere. Your closest stakeholder is often the person who has the biggest voice when it’s time for the bi-annual performance review and a bad relationship can hold you back from progressing.

From the stakeholder’s point of view they may initially think of the analyst as someone they occasionally ask for data but it doesn’t take long before they too realise that the analyst is one of their most important relationships.

Me (in the middle) in my days as an analyst being brought along to a leadership offsite in New York by some great stakeholders

Unfortunately, the analyst and stakeholder relationship is often far from great. But it doesn’t have to be this way. Here are some do’s and don’ts for analysts and stakeholders for how to get the most out of the relationship. 

Do’s and don’ts as an analyst

Getting better at working with your stakeholders is up there with the most important things you can do, so take this as seriously as you would with any technical part of the job.

DO: Never bring numbers without context. Nothing breaks the trust with a stakeholder faster than showing numbers that reveal that you have no sense of the part of the business you’re in. This doesn’t mean that you’re not allowed to make mistakes but you should know a few ballpark numbers off the top of your head. For example, if you work in customer support you should be able to answer roughly the number of customer support tickets, number of customers, contact rate, cost per customer or a few other metrics that matter for your area. Practise these until you know what they are.

DO: Invest in getting to know your stakeholder. Spend time with them, ideally also outside of your regular meetings. Get a coffee together, understand what their priorities and goals are and how you can play a role in helping them reach them. Make them feel heard and have a way to check in how they feel about data. This could be a quarterly data-to-business review, a survey or something else. You’d be surprised how happy people are when they get to voice their frustrations.

DO: Share insights proactively. You’re often sitting on insights that are much more valuable than you may think. To you, it may be an obvious stat that 5% of customers account for 80% of cost. But sharing this, and then sharing it again can be really helpful. In reality, there’re only so many insights that matter and reexamining a few important ones every six month or so is time well spent. It can be as simple as having a ritual of looking through important dashboards each week and sharing a recent trend or development.

DO: Take ownership of data quality. Religiously care about the few data models and dashboards that are most important to your stakeholders. Put in time to spot check them each Monday morning so you notice issues first. This helps build trust and lets your stakeholders spend their time thinking about business implications and which actions to take instead. 

DON’T: Assume that a stakeholder knows how you’re feeling. Stakeholders are often busy people with many other agendas than data. Some come from different backgrounds where the data team is thought of as a support function. Instead of taking this at face value, don’t be afraid to tell them that things work differently here. Most stakeholders are welcoming this kind of feedback. 

DON’T: Ignore red flags for too long. If the relationship between your main stakeholder is just not working out don’t ignore it for too long. Let your manager know and if this doesn’t help, ask to be moved to a different part of the organisation as soon as possible. It’s one of the best reasons to change teams. If a stakeholder consistently fails to work well with analysts that’s a red flag and feedback that should be shared with the stakeholder’s manager.

Do’s and don’ts as a stakeholder

While there’s no well defined progression path for people in data roles, many eventually find themselves in the “stakeholder” seat. Coincidently, some of the best stakeholders I’ve had used to work in data roles. They typically have a greater appreciation for the hard work and are explicit about when data needs to be 100% accurate or just ballpark accurate. 

Here are some rules of thumb on how to be a better stakeholder to an analyst no matter what background you come from. 

DO: Bring the analyst to the table. There’s nothing that’s more empowering for an analyst than to be included in the exec meeting where the work they were part of is presented. Bring the analyst to the table and trust them with presenting their work

¹

. If this is not an option, at the very least share with them how the meeting went so they know that their work had an impact. If you have a leadership offsite and have an analyst prepare some work, invite them along and have them present it themselves.

DO: Shine light on the work analysts do. If you want to be loved by your analyst, make sure to share the work they do with others. Ideally in a public channel and use your influence to make sure the right senior people are aware of it as well.

DO: Involve analysts early. Don’t just bring in analysts to fill in some missing cells in a spreadsheet. Instead, bring them in early in a project so they understand the entire problem and can help you think about data from day one. You’ll be surprised how much value you’ll get from this.

DON’T: Assume it’s only on the analyst to build the relationship. You may or may not know it yet but the relationship with your analyst is one of the most important ones you have. Invest early in it, take the analyst out for lunch and be curious about how they work and the tools they use. This also applies if you don’t come from a data background.

DON’T: Assume you know what’s easy or not. If you haven’t worked in a data role you may not know that a “quick data pull”, when seen from the analyst perspective, can mean anything from five minutes spent getting data from a dashboard to weeks spent building a pipeline and extracting data from a source system. Be careful assuming you know how much time a task takes and never use the term “a quick data pull”.

These rules are not rocket science but the relationship between analysts and their stakeholders too often goes south. If you’re running a data team, consider making “how to work together“ an explicit part of the onboarding process. Both for analysts and stakeholders.

If you have any thoughts on this topic, let me know! 

1. Great article about that here: https://petrjanda.substack.com/p/bring-data-analyst-to-the-table