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.

> He's describing critical & low effort cheap shots.

The examples he used included: the plan depends on a different team providing labour and that team is not on board, the business plan for the idea does not make sense.

I suppose they are low effort in the sense that they are very basic 101 criticisms, but i wouldn't call them cheap shots.

Literally no plan is ever going to work if it involves the labour of others without their (or their supperiors) consent. It seems to me a very valid criticism to make. That doesn't mean its the end of the idea, it means you need to have a plan to either get the other stakeholders on board, or a plan to do it without them.

It's not a plan, it's an idea. You're shooting down an idea for not being a plan. The best person for coming up with the idea will probably also come up with some of the pieces of the plan, but they're unlikely to be the best person to figure out all of it. That's why you have a company not a sole proprietorship.

> You're shooting down an idea for not being a plan.

If you are pitching an idea out of nowhere, than i think it better have a semblence of a plan, otherwise you are just wasting everyone's time.

Like maybe its a bit different if you are brainstorming for an acknowledged problem, but that is not what the article made it sound like.

The article made it sound like the idea was being pitched unsolicited, with no clear problem it was trying to solve and no clear plan on how to do it. After all 2 of the so-called cheap criticisms were people asking why we want to do this ("the customers aren't asking for it") and how are we going to do it when it has dependencies on stakeholders who have not bought in ("devops doesnt like it").

Why would anyone care about such an idea? Like if you want to work on something by yourself, you dont have to convince anyone, but if you want other people on board, you are going to have to answer basic questions. Questions like: what benefit would implementing this idea bring me, and will my effort on this idea be a waste because neccesary stakeholders aren't on board.

There are a lot of details that can be sorted out on the way. Things like, why would we even want to do this in the first place, is not one of them.

> If you are pitching an idea out of nowhere, than i think it better have a semblence of a plan, otherwise you are just wasting everyone's time

Depends on context. Shooting the shit is valuable.

And shooting down shit is also valuable. It is fine to have ideas without thinking them through, and it is also fine to criticize those ideas without thinking through the criticism. That is how we figure out how the ideas could work.

The problem with this is, that the article literally says:

> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.

If they did that much upfront work, it's more than an idea. And if it's that easily shot down, they should have done even more upfront work and probably slowly gotten others involved.

Honestly, it sounds like someone so desperate for credit, so worried that someone will steal the idea, that they feel compelled to unveil it in a large gathering that was convened for some other purpose. And that never goes well.

Ideas truly are a dime a dozen. If one gets shot down, then you can reflect whether that was warranted, and try again with the same idea if not.

If you're really emotionally invested in it, as the guy writing the article seems to be, then you damn well better have more than just an idea, and you should understand enough about human nature to slowly try to bring individuals onboard to help before you put it out in front of a big crowd.

No one should care about devops’s consent when they’re given a work item that comes from someone higher up on the org chart. Their consent is willful employment. Similarly, no one should care about an engineer’s consent when given a work item in a similar context.

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.

These are all risks. Not all risks need to be mitigated, but some can be. Others can be accepted. Saying “Python is too slow for production scale, but our goal is a small proof of concept,” is a valid answer even if it doesn’t “solve” the complaint. And if you don’t even have that answer, then the burden is not your problem. The lack of due diligence is.

These are the table stakes of uncertainty, not delving into every little pocket. If the language and ops are under question, this sounds like an entire new project or significant extension. The bit of time it takes to answer all those questions is worth it.

>On the other hand, demanding an answer to every little pocket of uncertainty creates a huge burden that prevents exploration.

How do you explore an idea, other than trying to shoot it down and seeing if it survives the shot?

By proceeding with things that will gather more data—such as prototyping, or further independent research—vs spinning indefinitely on "hypothetical" discussion-only shots.

How do you know if it survives the shot without that, if it's just person A saying "I don't think Python perf will be an issue" and person B saying "I think it will"?

> How do you know if it survives the shot without that, if it's just person A saying "I don't think Python perf will be an issue" and person B saying "I think it will"?

That is the point, knowing that it is a point we want to test is valuable. If person B there didn't say he thought it would be an issue you probably wouldn't have tested it, it was valuable for him to say that.

You can fire the shot and then patch the hole at the same time, proposing solutions to the same problem you pointed out, rather than just shooting and letting one person handle defense from every attack.

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.

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

sure, and the time for that is before you bring them to potential critics.

unless a meeting is intended as a brainstorming session where any thought, no matter how unformed, is welcome, meetings are not a time to present your initial unexplored thoughts to colleagues, bosses, or other departments. take a couple days, think about it without spending other people's time, try to imagine people's objections and have answers to them. then present. shouting things out in a meeting before you've considered and come up with answers to the most obvious counter-arguments is just a time-waster.

You must have very different kinds of meetings than I do. Unless you're going into that meeting with a rehearsed PowerPoint presentation, or there's a strict agenda that doesn't allow any time for exploration, I expect to hear imperfect-ideas-in-infancy. One of the reasons we have meetings is to allow collaboration to happen. It's a format for working together.

Yes, meetings vary profoundly in terms of their quality, purpose, and participation. For instance, is it a meeting of peers, or are managers in the room? If there's a large disparity of roles in attendance (e.g., junior engineers, marketing managers, and maybe one or two executives), it's different than if it's a true meeting of peers. And if managers are capable of attending those meetings without quashing collaboration, hats off to them.

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

Then go back, address the objections, and re-propose.

If you can't explain at least a little bit of "why this is worth at least digging into", that's on you.

If your idea is so in its infancy, that you can't explain its business case to people, even just hypothetically, than its too young to share.

Ideas are cheap. Everyone has them.

Sure, but it's sort of dumb for me to bring an idea I value to the table until I have answers to all the obvious questions.

I owe it to my colleagues to not make them the bad guys by shooting down an idea.

Really depends on the context I think, brainstorming session? Naysaying does have a habbit of stunting an idea's growth in the session. Sometimes you need to imagine you've solved a bunch of hard problems before you can explore the value the idea has.

I say this as a semi-reformed naysayer. I am critical of implementation plans, but let ideas breath a bit in a more exploratory setting before I start bringing up constraints.

Isn’t proving a market exists, building a proof of concept, etc, all examples of exploring an idea? Those seem like perfectly reasonable expectations.

If the proof of concept takes an hour to code up, or proving the market exists just takes a bit of googling, then sure, you can prepare that before the first meeting where you suggest the idea.

If the proof of concept requires spending a few days in the machine shop making jigs and parts, purchasing equipment, and a custom PCB, then I really hope you'll bring it up for discussion beforehand in a meeting. Ten minutes of discussion with colleagues might be as useful as several iterations of prototyping. Not so that they'll shoot it down, but because someone might say "oh yeah, we have a spare mcguffin from last year's demo that you can use, should save you lots of time."

If an idea is dead because it couldn't survive its first public outing, that's probably a good thing.

If you really believe in an idea, even if you first put it forward to the wrong hostile audience, you will have other opportunities to make your case.

In improvisational theatre, negativity is known as "blocking". It frustrates the imagination. It's very harmful to clowns.

> 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.

the "good for them personally" reaction is so true. It's almost like a team-level version of the inonvator's dilemma, where protecting the thing you already own feels more rational than supporting something that might replace it.

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.

> 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.

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

This is actually the only criticism from the article i think is invalid.

Very little in the business world is so performance sensitive that language (as oppossed to algorithms used) make a difference.

If it does make a difference, python is still probably fine for the prototype.

If its still an issue, just use another language. You are at the beginning of the project, its trivial at this stage to switch languages.

All the other criticisms i consider very valid. The language choice example is a stupid one.

> 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.

Actually, bazaar [0] (now breezy [1]) was a distributed version control system written in Python. It gained some non-Python bits over time, but iirc it was originally all Python.

As a (spiritual) successor to Tom Lord’s Arch [2] it was the second DVCS I used and, while slower than git, was performant enough for my needs at the time I used it.

Most distributed version control is IO bound, and Python isn’t terrible at that.

[0]: https://en.wikipedia.org/wiki/GNU_Bazaar

[1]: https://en.wikipedia.org/wiki/Breezy_(software)

[2]: https://en.wikipedia.org/wiki/GNU_arch

Mercurial was written entirely in Python for quite a while.

But more to the point, I doubt there are many ideas for which the choice of implementation language is core to the idea. Maybe that's how it was presented, but that's usually because you need a concrete realization of an idea in order for people to even get what you're talking about.

Lol, Mercurial is written in Python (and now some Rust).

Most of the time, when someone raises a hypothetical performance criticism, it is either to further their pet language or as a cheap shot to shoot something down.

>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.

what I meant with "DevOps won't want to support it" was someone saying this before DevOps had even been asked, and by someone who wasn't even on DevOps, who just assumed that they probably wouldn't like this sort of thing.

If this meeting doesn't include devs, I don't know what the context of anything in the article is supposed to be about. There are no major new ideas in business that don't involve software.

If it is not the case that "devs" is not functionally equivalent to saying "DevOps", then "DevOps" doesn't exist. You have an operations group, and you need their buy-in, so they should be invited to the meeting.

I read that as a frustration with the disparity between "you build it, you run it" and the enterprise-y habit to co-opt terms from free-roaming developers and stripping them of all meaning.

You can still have a central team of operators. When they're expected to deploy and support applications from development or procurement teams, I'd argue that's something else than devops for better or worse.

> 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.

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.

> 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.

> 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.

> 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.

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.