How to say No to idea given by team member, when I know from my experience that it is going to fail?

Question

I have a very hardworking team, and I like when they try to think about a project with broader perspective. I want to respect their contribution and don't like to refuse their ideas, but sometimes I know that a given idea is going to fail when executed, as per my past experience.

Executing and proving the idea, will take lot of time and resources. The idea may be good enough on paper to explain and very much convincing. But if I try to tell them that it is going to fail, and we can't use your idea for this project, then that is kind of demoralizing for them. What would be the best step in this situation?

The current scenario is:

We are working on data science project and suggestion by team member is logical and convincing if we look at it in greedy method.

Executing it will take considerable amount of time and team effort. I have suggested him to work on it side by side by taking small but stratified data sample and get output. and have suggested some checks in further stages, which I have doubt on. Here I have taken this decision because we don't want to miss out that 1% chance of my doubt being wrong. And time and effort of only one resource is being utilized on this idea which is manageable.

Answer 1

You do this by presenting the thought process that led you to this conclusion - not the conclusion alone.

This gives the team, or the individual, a chance to offer their perspective regarding your concerns. You might find that there are viable solutions to the problems you anticipate, which you did not think about.

Ask prompting questions that highlight these problems, and let the team think it through. Then add your own experience and recommendation. This way you can make a strong case.

Trying to shortcut the discussion will leave others feel unrecognized or left out, and may make your own position seem unreasonable. Instead of strongly insisting on a conclusion, let the team clearly know why - then they will understand why you hold a strong opinion.

If everyone is reasonable and constructive, you should arrive at a reasonable conclusion. If the idea is indeed prone to failure then you will be able to demonstrate this through your argumentation, and the consensus will be similar. You might also find that the team/individual had viable solutions for your problems, and having discussed them, might be able to avoid your past mistakes. The original idea might also pivot into something different, more viable. Let them take your valuable perspective into account, but also allow yourself to be surprised by good thoughts and solutions.

This way nobody will feel left out, unrecognized or demoralized, but involved, their perspective valued, and the conclusion will feel natural (not forced) and reasonable.

Answer 2

I am an idea guy

I am the person who will come up with dozens of ideas a day for various things. 1-2 I will write a one pager about.

However, I am also conflict averse and am exactly the type of person to be careful about sharing them lest I annoy someone and can easily be convinced to keep it all in my head. So I sympathize with your employee.

Solution. Just tell me why.

Take two minutes and tell me what factor I missed. Either I will go back and fix it or come up with a new idea. A missed factor is a challenge for an idea guy to overcome. A flat out no indicates that the intention as well as the idea may be unwanted.

Answer 3

Consider using the Socratic Method, asking questions to lead them to the same conclusion you hold.

"Novel idea, Vikas. What about authentication?"

"Okay, how do we get the security keys to them?"

"Oh, so we can't do that unless they're already authenticated via the old method. Drat. Well let's put this idea aside for now. Does anyone else have an idea they'd like to share?"

Answer 4

Ask them to create a Proof of Concept (PoC) for their idea. They will gain some experience and if you are correct will see it fail as you predict.

I've seen PoC's built like this, that address existing problems from very start. This has lead to new learning and new fixes for old issues.

They may have answers that you've not yet explored yourself.

Answer 5

You're not going to be always right about what's going to work, and what's going to fail. Even if you have decades more experience

Just as an example: a few years ago, my boss had an idea of how to accelerate a process with automation. He did a bit of research and concluded that - given the technology we were using - it wasn't possible to implement. A few days later, I had the same idea (in hindsight: probably he told me about his idea, I forgot, then had this "new" idea in my head by just remembering parts). Of course he immediately told me that it was impossible. I wasn't convinced, did a bit more in-depth research and found a way that actually did work. A few days later we had a first prototype.

The moral of that story: don't dismiss ideas because you think it can't work. Raise your concerns about the idea in a dialog, challenging them to prove you wrong. There is a chance that there is a way and you wouldn't want to miss out on finding it.

Or to put it another way:

Saying "no" means your employees learn that it isn't worth thinking about innovation and you yourself learn nothing.

Saying "that would be really nice, but what about potential issues X and Y with your idea?" means your employees learn that it's necessary to have a solid plan, plus you have a chance of learning other ways to achieve this task.

Answer 6

Who Knows?

+1 to @thonnor's suggestion of allowing a POC, and @stefan's observation that past experience is not always a predictor of future performance. I would try to approach the problem a bit more econometrically, like so:

If you had no other projects to work on, then you should let your team try The New Thing. Obviously, part of the problem is that you do have other projects to work on. Presumably, folks have given some thought as to how much value those other projects have. If The New Thing works out the way the team expects, then perhaps it should move to the front of the queue and be the first priority. But there is great uncertainty in the probability of success, and your "prior distribution" (to use a Bayesian concept) for The New Thing is low, based on your experience, while the team believes it is average to high, based on perhaps no experience.

Let's Make A Deal

The fair approach, IMO, is to gamble. In particular, engage in a game of chance with your team. The contest is to create a successful PoC. You and the team agree to a set of "success criteria" that will determine whether everyone agrees that it has good potential and has passed the blockers that you think will cause it to ultimately fail. Now, create a bucket of time, which is the only resource of intrinsic value, that we call "the bankroll". This is the total amount of time that your "organization" (the most self-contained portion of your org chart containing your team) is willing to spend on "bottom-up" projects (vs. the the default "top-down" projects) for the quarter/year (pick an appropriate time horizon).

The bet works as follows: the team can spend as many hours from the bankroll as they think they need to bet on their deliverables. If, after the agreed delivery date, everyone agrees that the deliverables have been met, then they get their "bet" back, which gives them "funding" to continue to develop their POC. Otherwise, they "lose" their bet, and they can decide whether to continue chasing it, spending down their whole bankroll until they are forced to quit, or to give up and wait for a better bet to place.

The Dealer

In this game, you represent "the house", and your role is to demand as much from each deliverable stage as you think is appropriate given the amount of risk/reward and the time being spent. Note that this does not mean you should push for the team to promise unrealistic deliverables. You should, in fact, treat the project like any other. If the team says: "Over the next two weeks, we want to bet 50 person-hours on The New Thing", then you should scale the deliverables to be equivalent in value to 50 hours of the top project in the queue. If they protest, just point out how you arrived at your valuation, and negotiate until everyone agrees on a bet that is fair.

Naturally, these valuations are subjective, but hopefully everyone can come to a ballpark agreement. For you, the thought process should be: "What would I have to show stakeholders instead of the normally promised deliverables that would still make them happy?" Obviously, the team is constrained by what they think they can deliver on time, and part of the challenge is to make the PoC small enough to succeed, but big enough to demonstrate value, even if they have to deliver it in several stages.

The Stakeholders

Also, it might help if you simply pitch the idea directly to stakeholders, so the team sees what kind of push-back you are likely to get. "Dear Stakeholders, The Team would like to try building a PoC for The New Thing over the next 2 weeks. We think it will provide X, Y, and Z, which compare favorably to Milestone N on Top Project. What is your feedback?" If the stakeholders say: "Yeah, we tried something like that before, and it failed because nobody wants to adopt a new process", then the team can see that their idea has cultural challenges in addition to technical ones. If the stakeholders say: "Yeah, that sounds like a good bet" then perhaps the broader support for the idea will help it succeed.

Answer 7

But if I try to say that it is going to fail and we cant use your idea for this project, then that is kind of demoralizing for them. What would be the great step in this situation?

Basically, you thank them for coming up with the idea, then explain the problem with it.

Something along the lines of:

"Thanks for coming up with the idea, X. It shows some great thinking. Unfortunately, we can't implement it because [some of the basic reasons]. Please keep the ideas coming though!"

You want to encourage the thinking process, even if the specific idea isn't viable in this instance.