Shooting down ideas is not a skill

If you are making the future yourself, why do you care what anyone else thinks? Just do what you want. Its your time and effort, nobody else has a claim on it.

In the context of the article, the author wanted other people to be involved with implementing his idea. If you want someone else to help, you are going to have to convince them. Nobody wants to put labour into an idea that is half baked, with no clear answer as to why we would want to do it or how we intend to do it.

> Stop thinking that finding a flaw is a contribution. It's half of a contribution at best. The other half is "and here's how we might solve that." If you're pointing out a problem without offering a path through it, that's not contributing.

So... finding a flaw is "half" of a contribution, but it also isn't a contribution?

Critical thinking is valuable. Yes, it can sometimes be counterproductive, but it can also be steered in a productive direction.

If someone criticizes something, ask them to elaborate. Why couldn't this work? What are the exact roadblocks? Is it based on prior experience, or gut feeling? If it's based on experience, how similar is the current situation to their past experience?

Chances are that after some prodding their criticism turns out to be a non-issue, or far less of an issue than they originally thought. In either case, the discussion itself often steers the group towards a better solution, so bringing up potential concerns, even if they're invalid, is often a good exercise.

The skill is aiming for the right moment to bring it up, having a bit of tact in the delivery, and not burying your head in the sand and being defensive (or offensive). Too often people attach their ideas to their identities, which is the root cause of why design discussions can be frustrating and nonproductive.

They used to have a lot of meetings. One of those meetings was called a “Design Review” meeting, or “DR.”

This was a big meeting, involving multiple departments, and usually involved hard-bitten, intelligent, and frequently, curmudgeonly, engineers, scientists, and managers.

It was their job to shoot holes in your proposal.

Making a presentation to a DR was a stressful thing, but it was also a highly effective forge. What came out of the meeting, was a robust, achievable project, with a solid plan, funding, and “on the record” support from all the teams involved. The idea would have real “legs.”

When you ask others to support your idea, you had damn well better expect them to be skeptical, and it’s a mistake to think of their skepticism as opposition. They often want to help you to make it happen, and anticipating problems, is a very important part of that.

https://littlegreenviper.com/problems-and-solutions/

You’re doing it absolutely precisely.

Knocking down this persons idea, giving all sorts or rational sounding reasons why this won’t work.

It makes you feel smart.

You contributed nothing.

All you did is dismiss and tear down and smash.

Look how clever you’ve proven yourself to be by stating how much won’t work.

If the engineer proposes an implementation the devops team doesn’t like, the devops team should come up with a counter proposal that still fulfills their requirements. And if their counter proposal fulfills the requirements but the engineer objects, then whoever’s at the top of both their branches in the org chart should be making the decision.