The "Dark Arts" of Stakeholder management
November 2021, updated January, February + March 2022, January 2023
What do successful collaborations (with stakeholders, colleagues, mentors, managers, etc.) look like? Great question! They're partnerships, where each party trusts the other(s) that they're doing good work (and work with them to get there if they're objectively not) -- and helps each other be successful.
This is easier than it sounds! As an advisor, mentor, educator and advisory board member, I've collaborated with 100s of stakeholders. Here's my advice on how to help you get there -- to build trust and rapport with your current -- or next collaboration, whether you're managing up, sideways or across.
If a collaboration goes south, depending on the circumstances, it may negatively affect your collaborators, colleagues and even the company's bottom line, which in turn can affect your performance evaluation. Here's how to try to avoid this: by aiming to get on the same page with your collaborators as much as possible -- so that there are no surprises, for anyone.
Statement of the Problem
One thing that's always rang true for me, in my career in Data (and developing data products):
The biggest pain point when it comes to developing data products is -- not data! -- but cross-team alignment, whether that’s around communication styles, priorities, deadlines, deliverables, something else, or all of the above.
In my blog post on "How to Deliver Business Impact with Data", I shared my strategy for successful kick-off calls with prospective (internal or external) collaborators, where at the end of the call you’re on the same page and know where to go next. The blog ends with recommendations on next steps, including having check-ins in place.
Now that you’ve landed that coveted data product -- or client -- what can you do to make sure the collaboration (and check-ins) are a success? Or, if the kick-off call -- or check-in -- didn’t go as expected, what can you do better next time?
Here's my advice, based on my many collaborations, for how to get on the same page with someone in a way that also builds trust and rapport.
"Meeting" Definition: As an aside, with more and more companies going remote, I'll loosely use the term "meeting" to mean a way to connect; it need not be in-person or over Zoom, and includes async communication in Google/Notion docs, Slack check-ins, etc.
What do you need to be on the same page about?
Having collaborated with many stakeholders over the years, the #1 thing that I’ve found that works for me, to get myself and my collaborators (back) on the same page throughout the data product development lifecycle -- is to understand, both:
what I need to know to be able to collaborate successfully (e.g. which I share in my blog post on "How to Deliver Business Impact with Data") and
what my stakeholder/collaborator’s needs to know to be able to collaborate successfully, which includes their preferred communication style -- or how they prefer to receive and share information (which I share below).
From "How to Deliver Business Impact with Data", this includes:
Context around the statement of the problem/ask
Outcomes and actionable next steps around what behavior change we're trying to achieve
What the smallest step to take to help us make the decision on next steps
What we also need to be on the same page about (with more advice on how to do so below):
What the check-ins (for intermediate updates) look like: where? how often? when? format?
Blockers (or potential blockers by date X) and pivots
Risks, opportunities, limitations and trade-offs
Iterations (if any) and scope
The goal is to not surprise/blindsight the stakeholder on the day that the (intermediate/final) deliverable is due.
How do you know if you're on the same page?
Stakeholders are not surprised with the deliverable, the steps it took to get there, and what the next steps look like.
This actually happens: I was presenting a deliverable and its summary, and the stakeholder was able to "predict" the next slide in my deck (sight-unseen).
This also happens: If at the end of an intake with a prospective client (which may span multiple calls), we're not on the same page about:
most immediate and high impact needs for the product/business, and
actionable outcomes for the collaboration, and
what the smallest step towards that goal looks like),
I don't propose an engagement, but share advice on things they can try instead.
Please note: It may take a (small/large) number of iterations in ironing-out what your understanding of each of your stakeholder's style is. Each stakeholder's style may be slightly/very different -- and valid, because it works for them.
(Pre-COVID) One of my old managers preferred to hold bi-weekly 30+ minute check-ins on projects over Slack.
(Pre-COVID) Another manager preferred to hold monthly check-ins over lunch.
How do you actually try to get on the same page? What do those iterations look like in practice?
Challenge 1: Stakeholder Wants to Meet More Often
Symptom: Stakeholder is not on the same page about the direction and progress of work.
Solution 1: Check to make sure you're providing all of the needed context around the direction and progress of the work. That is, does your (sample, async/sync) update include:
Reminder that we care about X
Example: We care about X and that the numbers are accurate
Example: We care about X and that we get an answer by tomorrow
Example: We only care about the magnitude of X, so that we can decide on next steps for Y; we need an answer by EOD
Summary of work: found A and C, which will help us impact X <this way>
Next steps: Since we care about the numbers being accurate, we have remaining questions 1 and 2 on B, will try W, Y and Z next -- would you agree?
Appendix: To get to A and C, I did M and tried to get around blocker on B via V and it only partially solved the problem. Will try W, Y and Z next
And that as soon as blocker B happens, let your stakeholder know about it, along with what you'll be trying next to either:
Try to get around it via V or
Changing direction RE looking for B at all (!)
What you don't want to happen is, if you change direction on B when your stakeholder was not aware and took next steps in their work assuming B will be done -- when that's no longer the case -- you'll (inadvertently) blind-sight or surprise your stakeholder(s) -- on the day of the deadline -- that you won't be delivering on the original ask, because the project went in a different direction or because you've been blocked for awhile. You'll immediately lose rapport.
Please note: This approach/solution is a good first start for check-ins, but do get feedback from your stakeholder to make sure that the updates are really tailored to their needs, which be to stay informed r align on next steps, or something else entirely, or all of the above.
Solution 2 (AKA Iteration 1): (Especially if Solution 1 is not working) Just ask! I tend to frame it as "Are you able to share more context about the request? Are you looking for more frequent updates?"
This is especially true if you already do a daily Slack stand-up (or similar, that they have access to) -- ask what's missing from your updates that they'd like to know more about.
Solution 3 (AKA Alternative Iteration 1): (Better yet) If you're feeling you're not on the same page with the stakeholder, proactively reach out! I tend to frame it as:
"I'm getting the feeling we're not on the same page, do you prefer to have a quick sync to discuss?" or
"We haven't talked in awhile, I'd like to give you an update and ask for input on next steps. When works best for you?"
Challenge 2: Stakeholder not Replying to Questions
Symptom: Not understanding communication style of your collaborator -- and you're reaching out in a way that either is not resonating with them -- or it's not the most convenient for them.
Solution 1: I highly recommend asking about their communication style and preferences during the intake/kick-off call. It’s a question that rarely gets asked but is so important for the collaboration that it builds almost instant rapport.
You'll learn that some really prefer to have a quick, clear summary of the ask/CTA at the top, followed by bullets with more context -- and some really prefer a detailed summary of the work before they recommend the next step. You won't know until you ask!
TIP: Some managers will share their READMEs; others will share their DISC Profile test results; others will have more specific preferences.
Please note: I've found that asking my collaborator for for feedback/input on a suggestion for scope and next steps helps us collaborate better on the end goal.
If you forgot to ask, watch for:
What words do they use when they talk about their needs? Are you using them as well -- and talking to those specific pain points?
Example: Do they mention needing Docker (probably not) -- or do they mention the need for reproducibility/self-serve?
Where do they prefer to share updates and how often? Do they prefer asynchronous communication or are meetings more effective?
Example: One of my managers preferred to meet over Slack.
When they reply/share: is there a time of day that works better for them? A specific format?
I’ve found that if I need more clarity, reaching out to summarize our thought process/assumptions and making specific suggestions or asking for specific clarification, makes it easier for someone to reply “yes, we’re on the same page” -- than it is for them to write out their thought process
How do they prefer to receive information?
Working with executives, who tend to check emails on their phone, I've found that they tend to prefer short and to the point messages, ideally starting with an executive summary impact to business if is/isn’t done, with bullets/links for further details (depending on executive) -- and include what their action item is.
TIP: Notice which one of your collaborators sends 1-sentence emails with no greetings -- or just a few words?
TIP: If there are no clear action items in emails now, that’s an added-value you can bring.
Solution 2 (AKA Iteration 1): You forgot to ask the questions shared on Solution 1, but have an idea on what their style and preferences are. Reach out (in your stakeholder's preferred style) to confirm. You can frame it as "it will help us collaborate better" -- which it will.
Solution 3 (AKA Alternative Iteration 1): Just ask! You can still frame it as "it will help us collaborate better" or "it will help me get you an actionable result faster" -- which it will.
Challenge 3: Business Question or Impact not Clear -- or the Request is "Everything"
Symptom: You think that it may take many weeks or even months to get an answer, and/or may include your applying the state-of-the-art ML to be able to begin answering the question for the first time, or -- it's not even clear what you are trying to achieve and why, expectations are misaligned.
Solution: To get on the same page, I highly recommend asking questions (which I share here) during the intake/kick-off call to get on the same page about all aspects of the data product, including deadlines.
If you forgot to ask -- or realized you had more questions, if you understand how your stakeholder prefers to communicate (and if not, see advice in "Challenge 2"), reach out in their preferred style (and format), to share what you think the business question is, and the scope of work to help iterate -- and ask if you’re on the same page.
It’s easier to get input from your stakeholder when you ask specific questions or provide a recommendation for next steps.
When proposing next steps or ironing-out the scope of work, think about the smallest step you'd recommend to take now, that will help you make the decision on next steps, to get you closer to your goal? (Jen Buzza calls this smallest step, the "wash 1 fork" step.)
If it turns out you're still not on the same page, ask follow-up questions. I tend to frame it as: "We're trying to get to X (where X is the highest-priority business initiative for that quarter). When in the past, I've had experience getting to X, I did it via A, C and D. To get started, we'll focus on customer activity in the last week. Does that sound like a good first step? If not, are you able to share more context?"
Challenge 4: Losing Sight of End Goal
Solution: If you know you have high attention to detail (like I do), to make sure we get back to the "big picture", it helps to:
Think of this as ~5-page slide deck covering the executive summary of actionable, impactful findings and then showing how you got there (on a high level):
Why: Statement/visualization of the business problem, including any context
What: Actionable findings
How: 1-2 proposed next steps to discuss
Appendix: Any assumptions
Any content should be tied back to the business outcomes we are trying to reach.
That is, would you rather see a task-based update like this: did XYZ and fixed bug ABC?
Or would you rather see an outcome-based, self-contained update (with links for more details):
Our goal is to get to X, so we started doing Y and found Z, that will help us with X this way.
Our goal is to get to X, so we'll focus on fixing bug Y next and try A afterwards.
Share the deck/information before the meeting -- to not blindsight the collaborator and to get input during the meeting. Even then, during the meeting, don’t assume that they remember the context (there’s a lot going on!) -- ask if they need a refresher on the context and/or the statement of the problem.
Cater to your audience and what their needs and preferences are.
What problem are they trying to solve with data?
Is your audience more visual? (Probably.) If yes, can your slides contain more visual summaries?
If you're a start-up founder that just got their first round of funding (congratulations!), consider adding a timeline to delivery of whatever it is you promised in your pitch deck that got you the funding, and update investors on the timeline and progress accordingly.
Challenge 5: Deliverable Doesn't get Used -- or Doesn't get Used as Expected
This is super frustrating! You've put in a lot of work. If the deliverable doesn't get used -- or doesn't get used as expected, you might have a "Challenge 4: Lost sight of the End Goal" or "Challenge 3: Business Questions was not Clear".
Example: If the collaboration went well, but the stakeholder didn't end up using the work.
Example: Stakeholder wants further and further drill-downs until there's no one left.
Solution 1: Let's take a step back and re-assess:
What was the stakeholder looking for in a result? What did they want to do with it?
Was the result actionable? That is, was your stakeholder able to use the work you delivered to be able to change the customer's behavior in a way that impacted X?
Then following advice in "Challenge 3", discuss your ideas for next steps on how to make the deliverable actionable.
Solution 2 (AKA Iteration 1): Just ask! You can still frame it as "I saw that we ended up not using the work.
Are you able to share more about how you were thinking we'd be able to change our customers' behavior on X?
Is there's anything else that you were looking for, that was missing?
What I can do better next time, to help us collaborate better?"
Challenge 6: Stakeholder Wants you to Read their Mind
Symptom: You don't have all the information you need to decide on next steps. Depending on the stakeholder, you get the feeling that the stakeholder is too busy to reply (try advice in Challenge #2) -- or requests for more context are not welcomed.
If it's the latter, Solution 1: Let's take a step back and re-assess:
What's going well? What else is not going well? What else can be improved?
Is there anything that you "should have" known by now that you don't know, because it wasn't shared?
Are there assumptions you made about the direction of the project that you haven't shared with the stakeholder?
Then try the advice in "Challenge 3: Business Questions was not Clear", reach out to your stakeholder, outlining:
Statement of the problem and desired outcomes
Assumptions you're making (around industry, customers, time frame for analysis, why starting with simplified analyses, etc.)
EX: What's worked in one industry may not work in another, because the customers and/or product is different and solves different pain points.
Do their care about: accurate answers vs quick turn-around "good enough" answers?
You may need to remind them that they can't have both, because of the Project Management triangle of trade-offs: "quality of work is constrained by the project's budget, deadlines and scope".
Randy Shoup's talk on "Communicating effectively with your business partners" (11:11 mark) has talking points on this topic, to more effectively navigate those conversations.
Deadlines and check-ins
If you don't know what these can be, make an educated recommendation -- and ask them to confirm that you're on the same page. Framing this request as check-in to make sure that you're on the same page -- will help you get there, and will also build rapport. Chances are, you'll get: a "yes" back, more context, or a request for a meeting to discuss the plan further. All wins!
Depending on your other priorities, you may also need to first make it clear that you won't get to start on this for (say) 2 weeks because of higher business priorities X, Y and Z. And then you'll spend a time-boxed amount of time, say 2 hours, making this educated recommendation for their review.
Challenge 7: Stakeholder is Surprised about the Direction the Project went in
Symptom: You get asked, why did you end up doing X and not Y? Or why did you do project X and not project Y first?
Solution: try the advice in "Challenge 1: Stakeholder Wants to Meet More Often", because you're not on the same page about direction or next steps for the project, or what the priorities are among the projects you're juggling.
Challenge 8: Stakeholder has a "Quick Question" or asks "Why are Things Taking so Long"
Symptom: You're not on the same page about scope, challenges/blockers, or trade-offs around complexity, risk, accuracy or what the final deliverable should look like.
Solution: Is there a way to visually illustrate where the complexity in the project is, so that it's easier to get on the same page?
Example: I talk through an example of working with multiple data sources in a discussion with Locally Optimistic on Data Products (at 20:24)
Example: Visualization Nate Sooter put together to justify the need for an Analytics Engineering team at his company
This is especially true if this is the first time you're using a data source , and especially true if it's the first time trying to use multiple data sources for the first time -- and don't know what's there or not, or what the quality is, or even you'll be able to join them together.
This is especially true if this is the first time you're trying to answer this question (by creating a metric or a baseline) -- or if there are other higher priorities. Does your stakeholder know about this? How have they handled similar questions in the past about this?
And also outlining the points shared in advice in "Challenge 6: Stakeholder Wants you to Read Their Mind". This way, you'll be on the same page if, for example, the deliverable is a POC, or if the scope has been expanded to production-level, and you need to propose phases and iterations of deliverables for this collaboration.
Challenge 9: You've been Committed to Something you Didn't Know About -- it Kicked-off Yesterday (!) -- and you Don't have the Bandwidth (!!)
Anyone that's ever been my direct report has learned that I don't (and don't like to) assign tasks/projects to people -- because if I do, this exact thing may inadvertently happen.
Symptom: You're not on the same page about what else is on your plate, but you already knew that.
Solution: Connect with your stakeholder to let them know that "you've been committed to something you didn't know about, it kicked-off yesterday, and you're just finding out about it. What happened?" And let them talk.
Depending on your availability, you may consider proposing a collaboration on a scoped down version of the data product for a proof-of-concept as a first step, which will help you -- and anyone else -- contribute to the data product.
Alternative Solution: Loop-in your manager. Are you, your stakeholder, and your manager on the same page about priorities? If not, consider suggesting that your manager sync with your stakeholder first, then you can collaborate on the plan (mentioned in Solution 1 above).
Remember to propose the smallest step next step when ironing-out the scope of work, to get you closer to your goal.
If you don't already have an intake form for requests (either as GitHub issues, JITA tickets, or similar), consider trying them out; this will help you get context from the stakeholder before any work begins. Then the steps taken to iron-out the data product will be self-contained comments in the issue.
I have an intake form I ask every prospective client to fill out before scheduling an intake meeting. Based on the answers provided, I will occasionally email the prospect ahead of the meeting requesting more context, to make sure I'm the right person to talk to -- and cancel the meeting if I'm now.
At the end of the meeting, summarize next steps and who's doing what next -- and by when
Make sure email subject lines clearly explain the reasons for the email, e.g. is it an FYI or a request for a decision?
Remember: you and your collaborator are on the same team -- you want to improve the customers' lives (!). Other ways you're also on the same team: trying to get to X; want t find actionable ties to metric Y; or trying to move the needle on board goal Z
Remember: meetings with stakeholders should be more like discussion sections, and less like your lecturing
Remember: If stakeholder is expecting to hear from you by a certain date -- and you don't have an update or are still waiting on someone/something else -- please update them to say this; this tells them that you didn't forget about them, and are still actively working with them
Overtime (about 4-6 months), the relationship will change into a partnership. What you'll see happen is that stakeholders that used to come with you with requests to do X (e.g. transactional asks), will come to you with <context> and ask you what you think (!).
If you tried the above -- and you're still not on the same page -- loop-in your manager. Share what the pain point is, what you've tried, and what you're still not on the same page with, with your stakeholder.
You can do this! Don’t forget, the goal is to get everyone on the same page, every time! If it helps, it's always an area everyone can improve. :)
I know I’m on the same page with my collaborator when they can finish my sentence (!) about what the next step is. This way, it’s easier to develop data products, make/save the company lots of $$$, and be more visible. As a side effect, your resume or portfolio will have more actionable bullets. Good luck!
Thank you Adam Stone for the much better blog post title!
You may also like:
Talk: Tell me what you want, what you really really want: How to identify the real business question
Talk: Top 5 Reasons Why your Data Science Project Didn't Make it and How to Get It Right the First Time
How to Get Others to Adopt Your Recommendation, by Nancy Duarte for MIT Sloan management Review
How to do less -- and manage your stakeholders, by Alex Turek
How to collaborate in the modern data stack world, by Parker Rogers for Census
Growing Data Teams from Reactive to Influential: Measuring progress towards company-wide data maturity for advice on prioritizing, by Emily Thompson
(Book) Managing Up: How to Move up, Win at Work, and Succeed with Any Type of Boss, by Mary Abbajay
(Articles for Statisticians and Data Scientists) "The ASCCR Frame for Learning Essential Collaboration Skills" and "Asking Great Questions", by Eric Vance and Heather Smith
(Magazine) AmStatNews' advice (p.17, 18) on building mutual trust and finding common ground
(Blog) Reforge’s advice on "Managing Up - Lessons From Scaling Teams at Credit Karma and Lyft"
What is Stakeholder Management?, by MindTools
Data Literacy: Why do people not trust data and how can we overcome it? Tips from Patreon's Director of Data Science, by Stef Olafsdottir
Frances Berriman's' advice on communicating complexity through a Fruit salad: a scrum estimation scale
The Dark Art Of Stakeholder Management, by Steve Horton