89

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.

Improve this question
1
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Dec 11, 2019 at 12:52

7 Answers 7

Reset to default
230

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.

Improve this answer
12
  • 39
    Indeed. If this approach failed in the past, hopefully you know why it failed back then. Ask them what their new plan does to prevent the same thing going wrong.
    – ObscureOwl
    Commented Dec 10, 2019 at 10:09
  • 21
    Generally agreed, though there are some aspects that come down to practical experience and weighing of potential things that could happen, e.g. the general company members accepting a new feature. While that feature might look great on paper, experience might be that office workers will not pick it up for behavioural reasons. You sure can say that, but it will not always convince people from whose perspective the feature makes total sense and they surely will get it right such that it is irresistible. So, fully support this approach, but would add that sometimes you have to be the bad boss.
    – Frank Hopkins
    Commented Dec 10, 2019 at 12:51
  • 8
    Presuming this answer (and the others like it) seek to address the "how to say no..." part of the question, it runs the risk of appearing disingenuous if you are advocating "saying no" by engaging in a faux-"what should we do?" debate. "Discussions" where we "all agree" that a dictated course of action is best are commonplace such that employees usually spot the ruse, and they resent it because the intervening faux-debate wastes their time and demands that they engage in the building of the lie aimed at them. If you're dictating a "no" at least grant your employees the courtesy of honesty.
    – benxyzzy
    Commented Dec 10, 2019 at 14:21
  • 3
    @perenniallydisappointed this is not about proving something or 'being right' it is about convincing people and about leading. I'm just saying that reasoning and explaining and discussing are good, but as a boss sometimes you have to go by experience and decide by authority (if there is time, best after listening and providing your experience).
    – Frank Hopkins
    Commented Dec 10, 2019 at 14:58
  • 7
    @FrankHopkins, if you're not open to discussion and are going to reject the idea on the basis of authority anyway, there's no point in pretending otherwise.
    – perenniallydisappointed
    Commented Dec 10, 2019 at 17:26
48

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.

Improve this answer
2
  • 12
    Unless you are being paid to come up with dozens of ideas every day, quite likely the intention is unwanted, because you are not actually doing the job you are employed to do. Over the past 20 years or so, I've got rid of a couple of people not because their endless stream of ideas were necessarily poor, but simply because giving them the consideration they deserved would have been far too disruptive to the business as a whole.
    – alephzero
    Commented Dec 10, 2019 at 18:21
  • 12
    @alephzero sounds like a communication problem or a poorly defined role. it should either be obvious up front or communicated early on whether these ideas are useful or needed. in this case, the OP states "I like when they try to think about a project with broader perspective"
    – aw04
    Commented Dec 10, 2019 at 19:17
29

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?"

Improve this answer
3
  • 20
    "When we tried something similar on [antique project] we got hung up on [hard issue]. How are you going to address that?"
    – dmckee --- ex-moderator kitten
    Commented Dec 10, 2019 at 18:15
  • 20
    "The Socratic Method works best when you get to write both sides of the dialogue." "Really?" "Yes." "I see, it's so convincing now."
    – Daniel R. Collins
    Commented Dec 11, 2019 at 1:55
  • @dmckee That's how I have dealt with similar situations myself. Establish prior relevant experience, explain problem encountered that I believe will be in this example too, ask if they have any thoughts on it. If it's a hard-stop problem, this will cause a rethink, but otherwise they may have a solution in mind. It keeps the discussion going rather than being a "no that won't work, try something else" approach that kills the conversation and demoralizes people.
    – Ruadhan2300
    Commented Dec 11, 2019 at 9:33
9

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.

Improve this answer
1
  • 1
    Or, if there isn't time for that just write up a one page summary of the idea.
    – Robin Bennett
    Commented Dec 10, 2019 at 13:18
9

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.

Improve this answer
5
  • A good manager will accept they don't know everything. I've been in too many situations where my experience and knowledge could have easily avoided issues in a project, but it was rejected out of hand because of other people's previous bad plans that didn't work but were vaguely similar.
    – computercarguy
    Commented Dec 10, 2019 at 20:47
  • I recommended HUGE cuts in the size of our multi-executable project by dynamic linking instead of statically linking hundreds of copies of the same libraries. Senior engineer vociferously swore it wouldn’t work. Another guy went behind his back and did a build that way and it worked.
    – WGroleau
    Commented Dec 11, 2019 at 1:12
  • @WGroleau, What you are saying is true, but what if that project was not doable alone by 'going behind his back'. If it requires team effort and considerable amount of time to execute entire project and time = money.
    – Vinod Sawant
    Commented Dec 11, 2019 at 5:38
  • Point is not that he could have been right but that a guy whose judgment (or politics) got him into a position of trust was wrong.
    – WGroleau
    Commented Dec 11, 2019 at 8:14
  • @VkS this might be the case, and of course it's a valid reason to postpone or cancel such an endeavour. Just make it clear that you're not discouraging innovative thinking by providing clear reasons why you can't spend the resources etc. If employees are only ever hearing "no", they will become unmotivated very quickly. And the trick is to not just say "yes" to everything instead, but to sit down with them and discuss, then decide together (ideally).
    – stefan
    Commented Dec 11, 2019 at 10:13
4

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.

Improve this answer
1

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.

Improve this answer
6
  • 7
    This has the problem the accepted answer pointed out, "Trying to shortcut the discussion will leave others feel unrecognized or left out, and may make your own position seem unreasonable."
    – JollyJoker
    Commented Dec 10, 2019 at 15:02
  • This has the effect of the boss/manager assuming that they are better than the people below them and the employees can't come up with anything novel to address or completely avoid the same old issues.
    – computercarguy
    Commented Dec 10, 2019 at 20:43
  • 1
    @computercarguy If the boss knows about that problem and the employee doesn't, then the boss is better. If the employee didn't cover how they'd fix that known issue, and they can in fact fix it, they've learnt a valuable lesson for the next round of suggestions - refine their idea (or the presentation of it) and try again.
    – Graham
    Commented Dec 11, 2019 at 0:27
  • 2
    @Graham, that requires communication of the actual problems with the suggestion between the suggester and the manager. This answer doesn't allow for it, or much of it. Without that communication, you don't really know who actually does know more more about it. I've had suggestions put down immediately before "because it was already tried and failed", without any explanation on why it failed. Hearing the reasons from other people, I learned that my idea was considerably different and wouldn't have had those faults, but it wasn't listened to because of that "history".
    – computercarguy
    Commented Dec 11, 2019 at 0:49
  • 2
    @computercarguy That's why the key line in this answer is Unfortunately, we can't implement it because [some of the basic reasons]. And knowing that, if it does in fact fix those problems then the suggestion can go back in the box with a better explanation of the solutions. I agree that your experience was bad, but this answer is saying how not to treat people like your manager treated you. :)
    – Graham
    Commented Dec 11, 2019 at 1:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .