> "I haven't heard any customers request this." "We can't use Python for that, it's too slow." "That introduces too much complexity." "We tried something like that before and it didn't work." "DevOps won't want to support another service." "People are used to the way it works now."

> None of these people are wrong or stupid. And none of them have added any value.

Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.

No customers requested this? Prove that there is a market that wants it.

Can't use Python because it's too slow? Show a proof of concept that is fast.

Too much complexity? Demonstrate that it's the minimum amount of complexity to achieve all the requirements.

Tried it before unsuccessfully? Explain what's changed since then.

DevOps won't want to support it? Burn down the company and start again: you've managed to undo everything that the word "DevOps" is supposed to convey.

People don't want change? Nah, people like change when it is obvious to them that the change is good. People don't want bad changes, and their justifiable default assumption is that a new change is a bad change. You'll need to overcome that.

And if you can't convince these acknowledged correct-and-smart naysayers, then be glad you didn't chase that rabbit. Come up with a new idea tomorrow.

There is value in critically evaluating ideas and possible endeavors. On the other hand, demanding an answer to every little pocket of uncertainty creates a huge burden that prevents exploration. It's one thing to be exhaustive in the criticism by examining individual scenarios, evaluating cost benefit in a measurable way, etc. That doesn't seem to be what the author is describing. He's describing critical & low effort cheap shots.

Congrats, you've killed the idea in its infancy because you demanded answers to questions before it could even walk.

Ideas need time to be explored, and given a chance.

That all sounds fine if they're not the kind of naysayers that will just let the company collapse around them rather than risk putting one of their own ideas out there on the chopping block. All too often nothing is the worst thing we can do, and there are a lot of professional do-nothings out there.

you're right that a good idea should be able to survive scrutiny. The issue I'm describing isn't "someone asked a tough question". It's when objections pile up so ast that nothing can survive long enough to be properly evaluated. That's not a rigorous process, that's just a kill zone. The difference between a productive and unproductive kill zone comes down to culture. Teams that default to "here's why it won't work" end up very efficient at producing nothing. The teams I've seen do this well still kill ideas but they just do it after giving them a fair shot. The proposer has to do their homework but the environment has to let them get far enough to do it.

> People don't want change? Nah, people like change when it is obvious to them that the change is good.

I agree with more or less everything but this one.

I would modify it.

People don't want change? Nah, people like change when it is obvious to them that the change is good for them personally.

You can introduce a change that would be great for the organization and customers, but totally eliminate the current project a team has been working on unsuccessfully for years. You will be shot down no matter how good your idea is. And many times, there is no way to turn it into a "win" for the team that you need to win over to your side due to politics.

So shooting down ideas - for that team - is indeed a skill. A self-preservation skill. I've seen teams able to employ this skill for nearly a decade where it was obvious to any outside observer there were numerous ideas that would eliminate their need to exist altogether.

> Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.

Power assymetry and tenure are a factor. So is "culture eats strategy for breakfast" realities in organizations.

e.g. Change of pandemic messaging in early 2020 from "covid transmits by droplets and fomites and 2 meters and handwashing keep you safe" to "covid is airborne and fills a room like smoke" (and multiple mitigations around that) was attempted in groups by multiple expert scientists and ultimately took years when it needed to be done fast. One key moment: https://www.google.com/search?q=%22where+is+your+evidence+li... You can come with evidence for those tough questions to support your position, but one grandee scoffs at your suggestion in the meeting you networked hard to get and there's no recovery.

> Can't use Python because it's too slow? Show a proof of concept that is fast.

Python is slow though, and for many use cases it won't work.

For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python. Something like that would even be slow in much "faster" Node.js.

Some stuff you can't really use dynamic langauges for, if you want it to be performant. Low-level stuff usually, of course.

To your point, you could showcase how Python might call out to other languages like Rust, and show why it's convenient to keep some stuff in Python.

> People don't want change? Nah, people like change when it is obvious to them that the change is good.

I agree with some of what you said, but just want to point out that you're doing the very thing you criticise here.

I think lots of people genuinely don't want change. Hopefully you have great answers to my objection.

In general, I've found the question of "who needs to provide evidence first?" is one of the most casually ignored and maliciously manipulated questions in so much professional discourse. The answer is often implicitly "the person with less role power" which by itself is a terrible answer.

> Can't use Python because it's too slow? Show a proof of concept that is fast.

The burden of proof is on the other side. Prove that Python is too slow for the intended usecase.

>DevOps won't want to support it? Burn down the company

Still true but you seem to blame the ops. I've been in a job where every dept was allowed free for all tech budgets. They would hire incompetent consultants to dump 3000hrs of work on devops then do it again next week and complain about how devops never gets anything done. Then 5 other departments would do the same thing.

You know how 99% of the work is in that last 5% of the project. Thats how all those consultants would leave everything.

I’m hearing exactly the negative talk that this post is talking about.

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.

> it is now your job

I don't care about my job anymore, that's the problem. One too many good ideas has been shot down, one too many stupid ideas has been pushed through. If my manager and a huge chunk of my coworkers are simply incompetent, then trying to convince people to do something smart gets old very fast.

[dead]

[dead]