How to properly point out fault in others ideas?

Question

Context: I work in an IT Company and have recently been promoted from developer to a management position. I am managing a team of developers with really creative minds. We hold team meetings weekly to discuss possible solutions to different development tasks. Everybody gives many ideas and it's always a very communicative session.

I usually think out of the box and always analyze every solution provided. Most of the unorthodox solutions always have some shortcomings. When I was a developer, pointing out issues to the management in the meeting was a habit of mine and almost everybody expected me to find some issue with every idea.

Problem: Now that I am at a senior position, I can't afford putting down every idea presented by someone, fearing people might stop speaking out confidently. I would like to know what methods can I use to decline ideas without making them lose confidence?

PS. Sorry if this is in the wrong stack section, I couldn't think of a better site to discuss this.

Answer 1

Here are some simple practices I use:

• ask questions, don't point out problems. "Hm, what will happen if X and Y, tho?" rather than "Yeah, but if X and Y, it will all come crashing down."

• use the first person plural, not the second person. "What if we", not "What if you".

• get into the fairly-frequent habit of asking "ok, what are the possible pros and cons of this approach". Don't do it only when you have already spotted a problem. Do it sometimes even when you are pretty sure that the possible downsides are mild and low risk. The goal is to get your team to start routinely thinking about that themselves.

I'll also second a couple of suggestions that others have made, that were difficult for me when I made that transition:

• don't respond quickly. Give the team time to process & identify things themselves.

• don't intervene to prevent every problem. (This one was really hard for me.) Sometimes, you have to let things go wrong, so your people experience the consequences & learn from experience. Of course, as a PM you have to choose these cases wisely wrt project risk.

Answer 2

Developer D says that she has a solution for frobnigating the meridian widjet.

Manager X sees a problem in that the foobar widjet will be twonkled. X decides not to allow D to frobnigate the meridian widget. D says it will be fine if the foobar widget is tweaked first, but X has already made his decision. Consciously or not, since he'd already made his decision, he'll come up with some way to explain why tweaking won't work. D, disgruntled, goes back to her desk and comes up with an ugly hack to fix the problem (or, even worse, twonkles and tweaks without her manager's agreement).

Manager Y sees the same problem. He asks D if she's considered what to do with the risk of the foobar widjet being twonkled. D replies that it should be fine if they tweak the foobar widget. Y asks if they've considered that doing so will dribble the doohickey. After a bit more back-and-forth of open discussion, a mutually-agreeable solution is found. (Or a mutually-agreed infeasibility.)

Don't be Manager X. Also, don't jump down your Team's throats with problems (or solutions). If they haven't considered an issue yet, give them time to do so; even time to go back and research for a few hours, if necessary.

Answer 3

There are two sides to this:

First, to what degree is it still your role to do this? If you're doing it, is it giving an excuse for others not to step up and fill the spot?

If you need to (say the team is going to walk into a disaster and no one sees it) you can try asking questions. "Will this handle the number of concurrent users we need." will obviously go over better than "That approach will run terribly."

The other thing I've found is that you should just be respectful of their decisions. Ask the questions if you have concerns, but if they say "Yes, this will perform fine." then respect that and let them run with it. They may be wrong and have to change it later, but letting the team make their own mistakes and learn from them pays off in the long run.

This is, of course, all subjective due to the nature of the question, but it's based on my experience making that same switch.

Answer 4

"Poacher turned gamekeeper" is the phrase that comes to mind.

You delighted in being "that guy" when you were a developer. Perhaps it even marked you out as a candidate for this managerial role. Now you have other responsibilities, and you can't be "that guy" any more.

You've identified a couple of your old skills that are still relevant to your new role.

• Analysis
• Communication

Keep doing that. But remember that your new role is to create strength out of these discussions, rather than show how good you are at finding weakness.

Use those same skills to get your team of developers to identify the weaknesses themselves, and more importantly, find solutions. Guide the discussion rather than dominate it.

Your role now is less to do with "declining" ideas, and more to do with "choosing" the best ideas.

Answer 5

Managing developers means you are the team lead of those developers. As a team lead, it is important to note that no suggestion is invalid, incorrect or insufficient. Little fragments make a rock.

Hence, during your weekly team meetings, get someone out of the team to take note of every idea suggested and issues detected. After everyone has spoken, take the note and discuss everything by appreciating their inputs and enhancing their suggestions.

It is obvious that you are the decision-maker as the team's manager, but make their opinions count; even if you feel a hitch about a particular one, appreciate it and tell them how you feel about it.

Then go ahead to make them know "not you" but "we are" going to implement it. i.e allow them make their mistake... if there is any mistake to be made at all. People learn from their mistakes.

Try not to dominate the meeting with your own ideas, even if they are well-analyzed and important.