Dealing with Non-Technical Stakeholders in Data Science Projects

We’ve all been there. That one person you work with frequently who probably means well, but oh man do you just want them to leave you alone sometimes. 

They ask so many questions that don’t make sense and demand to know exactly what you’re doing and how you’re doing it (even though they have no chance of understanding the cool shit you’re doing). 

They want it done yesterday, to an unattainable standard of production, cut seventeen different ways and already answering the follow up questions that have absolutely nothing to do with the original request.

The worst of the worst: they try and micromanage you.

Unfortunately these people exist in every company, and they’re not going away anytime soon.

We need these people, believe it or not. They’re the ones who can give us some great problems to solve, and when we do, are our greatest proponents and cheerleaders for our discipline.

It’s in our interest, both personally and professionally, to forge good diplomatic relations with these beings from a non-technical background. When done well, working alongside your stakeholders can be incredibly rewarding, and allows you to focus on the things that you’re good at, letting them take care of the bits you just don’t want to do.

So how do we deal with these frustrating, but ever present colleagues?

Fighting back against stupid requests

This is where a lot of the frustration starts. A lot of the time, stakeholders don’t actually know what it is they want. 

Sometimes they’ve just heard about a technique or project that another team, or company is doing. They want it. They don’t know what it is, but they want it.

Other times, they might have seen a chart or report and panicked about it, and asked for some very specific information, but they don’t truly understand what they’re looking at.

And then, of course, they might have a reasonable idea of what the end product is that they want, but they’re also trying to enforce unnecessary details upon your requirements.

All of these problems share a fundamental similar problem: they’re trying to define too much outside their knowledge area.


  • Take control. Don’t let them reel off a list of requirements and demands.
  • Talk to them. Understand the problem, the background, what they’ve seen and what they’re thinking about.
  • Get the context of the problem.
  • Understand what their ideal outcome is, but also what their acceptable outcome is.
  • Are they time constrained? This will greatly affect what you should and shouldn’t promise.
  • Take your time to think about what is feasible. Don’t overpromise, do you have the data, the time, the resources to do this?
  • Explain to them what you can do, and how it will solve their problem.
  • Be confident in owning your knowledge space! They’ve come to you for your expertise and abilities.
  • Figure out measures of success that you can both aim for, and your stakeholder will understand.

Now, this is the ideal. You’re going to have some troubles getting the info you need out of some people. Impatient, arrogant, aloof stakeholders are the f**kin’ worst. But try and make things easier for yourself from the start, it’ll pay dividends.

Maintain your autonomy


That’s pretty much it. Once you’ve defined your problem from whatever scraps you’ve gleaned from your stakeholders, you can outline a rough plan of attack. But………. Don’t let yourself become micromanaged and owned by them.


  • Say “thanks, I’ll go away with this and come back with my high level approach.”
  • Don’t say “yes” to everything.
  • Go and take some time, draw up a few ideas about what you might do.
  • Don’t drive straight into the problem unless this is suuuuper easy.
  • Talk to a few like-minded colleagues, friends who might have done something similar and can offer some general advice.
  • Be open with your stakeholder about the potential limitations of the problem, so they’re not blindsided.
  • Set up a regular but infrequent update schedule – you own the communication proactively, not then constantly draining your time.
  • Have at a minimum a vague idea about timelines. 
  • Make sure you include contingencies for iterations, review, write up and presentation if necessary.

Make the MVP first, details later

We all want to make amazing products that come with all the special production systems, error checking and automated features that means we can sit back and watch our masterpiece fly.

However, it’s best to take an engineering approach, and build up iteratively.

This isn’t strictly a way to deal with the stakeholder, but if you get this right it’ll really smooth over the whole process with them as they’ll be able to offer concise feedback each step.

What’s your MVP? Minimum viable product.


  • What is the most basic, minimum effort, quick turnaround product you can build? Build that.
  • Sometimes I don’t even make sure to satisfy basic assumptions first go. If it works mechanically, it’s an MVP.
  • Now go and figure out if this is “acceptable”.
  • Fix any basic assumptions, minor issues.
  • Are there any easy data improvements you can make? Volume, scale, some simple feature engineering?
  • Can you try a different model type or system?
  • Write up a few notes on your iterations as you go so you can explain simply at your catch-ups what you’ve done and how progress is going.
  • It you’ve reached an acceptable outcome for your stakeholder, you can call a hard stop on your project.
  • Keep any notes and write up any potential solutions or spin-offs you’ve thought of as you’ve been working.

Make sure you’re the one presenting your work

Time and time again, I see good data science work being produced. You’ve done all this work, figured out some cool novel solutions, and are genuinely proud of your output. 

You’ve even put a nice presentation together, complete with colours, shapes, buzzwords all over the place and an executive summary.

Then, it gets taken away from you and someone else is “socialising” your work to reaaaally important people around the business.


This is your work, you did it (perhaps in a team, in which case you all did it), and some asshole is taking the credit? Not only that, but how are they going to answer all the tangential and weird offshoot questions? They weren’t there, man!

Maybe you’re a bit of a quieter person, and you’re not as comfortable presenting. That’s fine, but in most cases, you at least want to be present and represented fairly.


  • Present it to your immediate stakeholders, get it good! They’ll be more happy with you presenting to others.
  • Offer to present it before they take it away.
  • If you need to, show them how they can’t answer a few sneaky questions that you can.
  • Put your name on the presentation just in case. Let them know it’s you! (As long as you’re happy with it…)

But make sure you can explain at their level – MOST IMPORTANT

This should be pretty obvious. If you’re going to present anything that you’ve done, no matter what it is, you need to present it differently to each type of audience. 


  • If you’re presenting to technical peers, include some of the cool techniques you used, and prepare for more technical, detailed questions.
  • If you’re presenting to your line manager, include more detail on how it fits with the team, who it’s going to, what the request was; background context.
  • If you’re presenting to the immediate stakeholder, make sure you focus on what they asked for, how it translates, a high level summary of what you did, and how it solves their problem, and what they could and should do now.
  • If you’re presenting to super senior people in the business, keep it even shorter, morr catchy bitesize sentences, and infographics they can cling on to. Keep it ideally about 5 minutes, 15 at most.
  • Don’t be afraid of offering recommendations.

Share with everyone else

You’ve done the work, planned it end to end and executed successfully! Maybe you didn’t do everything you do it wanted to. That’s fine though, just gives you ideas for other projects.

The next best thing is to find other people, other teams that would be interested in your work. It could directly benefit them, they might have similar problems that they can take inspiration from your work for, or maybe they’re just interested from a professional point of view.


  • Share in the appropriate internal social media/communications thread.
  • Talk to similar minder teams and bring up your work if you think it’s relevant.
  • Write up a technical summary presentation you can send over as an initial read.
  • Have the exec high level presentation on hand ready to send over as well.
  • Shout from the rooftops if you’re proud!
  • If it’s super cool, super technical or super impactful, maybe there’s a place at an external conference you could present at.
  • Make sure to clear it with your manager first for confidentiality restraints.

Go out into the world and be friends!

We’ve covered off a lot of tips on how to deal with non-technical people in a project situation. From start to finish, hopefully these points will help you maintain some control in the process and not become too enraged with the people who are super valuable to the project but can be incredibly frustrating to deal with.
Remember, you’re all there for the same reason: make some cool stuff and have a good positive impact. Working together should always be advantageous, and sometimes we just have to take a bit of time to try and understand how we can be more productive with the other side.