But if it's just a difference of opinion, then it's fine to propose another idea but it should remain a professional and technical discussion and agreement. But also be supportive of other ideas that aren't your own. I see too many people think other people's different ideas won't work because their ideas are better.
Almost all the problems we encountered with the project where things that happened as a consequence of me not shooting down random ideas before said CEO managed to get them started. Whenever I came back from PTO, or conference, etc. I regularly discovered that the CEO had split the already direly understaffed team to work on yet another brilliant idea that would make no sense before we even had our product.
A few of the brilliant ideas I managed to shutdown: a reimplementation of git, a home-made bug tracker, a novel abstract interpreter for a programming language that didn't work yet, a transpiler between the old programming language used in-house and the new one, a Google Docs clone, a home-made IDE, a mechanism for storing source code as structured data to a database instead of a flat file...
Things I didn't manage to shutdown: a custom NoSQL database, a home-made project tracker, a homemade front-end framework, a custom HTTP server, a custom standard library, a new type system, ... all of which were distinctly inferior from what was already available, and could possibly have become much better, with years of development which we couldn't afford.
The company managed to release a first version of the product and folded a few months later, out of funding. Of course, shortly before that, I got fired for "blocking" the development of the company.
My conclusion? Yeah, sometimes, "that won't work" is a matter of survival. But if someone needs to throw away their career by being the "that won't work" person, the company risks ending up full of yes people.
I would probably go with "that's not a good idea" for the latter.
For the former, when brainstorming solutions, never shut down ideas. That's the whole point of brainstorming! If you want to point out downsides, try a variant of "I think you're on to something there, but how would we handle $DIFFICULTY?"
The brainstorming process is designed for generating alternatives, it's not suitable for choosing between alternatives, that needs to be done in a critical "anti-brainstorming" mindset.
Edit: do you mean you're using C and replacing stdlib.h? If so, yeah that sounds like a bad idea
He said, "give me a month".
I said, "don't waste your time".
He said, "give me a week?"
I said, "okay, you can spend a week on it, but after it doesn't work, please do it my way".
Much to my surprise it worked, and much better than my way would have.
After looking it up, I was surprised to find that, yes, it did indeed work like he thought it did, and his proposal was viable.
We all have to eat our hats sometime; no one can be right all the time.
- "that won't work, 60 %" (which could mean a healthy debate is the quickest way to settle the issue);
- "that won't work, 80 %" (which probably makes a timeboxed attempt the best way to settle the issue); and
- "that won't work, 95 %" (which signals something really wonky is at play. If two intelligent people have such firm yet different opinions, it's possible at least one of them has completely misunderstood the problem in the first place, or there's some other unexpected gap in knowledge.)
Of course, for that to work, we have to calibrate everyone's sense of uncertainty and keep validating their opinions to make sure 70 % really means 70 %.
No one one spoke up to disagree with him. In fact, the CTO was in the room at the time. This guy (the CTO) was always evangelizing about innovation. Not a peep out of him after watching someone's idea shot down.
This event and others made me realize that "that won't work" was an integral part of my company's culture. I guess it's about risk. In a company culture like this, there is no upside for a manager to try anything new.
While it’s easy to fall into that trap. 90% of people wouldn’t have given them the week in the first place. I think you deserve some credit for realizing that you ‘might’ be wrong.
My approach to it happening has always been two-fold; Firstly when talking about it I would tell the story - I hated the idea, wouldn't work etc - but the other guy was better than me and made it work. I lean into the mistake, make sure others know it happened.
That leads to part 2 - everyone and most of all myself need to know I am not omniscient. Someone needs to tell me I also have bad ideas. Sometimes other people have good ideas I don't like.
Most of all I encourage people to have and share lots and lots of ideas. 90% are bad (mine included) but if we can isolate the good 10% we'll do OK.
It's not that you need to say yes to things, it's that you need to sit with it a minute, and challenge your objection internally / try to creatively get around the fatal flaw you perceive, before voicing your opinion. Sometimes you'll actually be wrong, other times you'll invent something that works in response. Sometimes you'll be right, and you can raise the objection after you've put in a little internal work.
This isn't the case if, say, someone suggests something as outlandish as "we should just invent a new compression algorithm that works on all possible inputs." But then, that's not something a peer or someone resembling a peer is likely to say.
Yaaas please, this so much.
Boiling down engineering decisions into dispassionate lists of tradeoffs is an important skill, but early in my career I erred too hard in this direction. Coworkers who spoke without thinking "won" every time and I got stuck digging us out of the holes they led us into even though I had seen the holes from miles away. This happened several times before I learned to trust myself and stand up for my own ideas even if I wasn't 100% confident in them. That's an important skill too.
Ultimately you want to set up a feedback loop that looks for evidence that you are erring in one direction or another and corrects appropriately, but by now we have descended into the realm of completely generic self-help :)
Then you've missed then point you were responding to, which was contemplate first, advocate later
All you have to do is bring up the issue that you think kills the idea, you don’t have to issue a judgment.
If people can’t see that it kills the idea, then either you are wrong and it can be mitigated, or again you are wrong and it is not the issue you think it is, or you are right but you are dealing with a group of people that can’t see reason, which is something you would want to know anyway.
If the someone calling out the showstopper isn't the final approver or able to sway the group that it's a showstopper then suggesting a follow-up validation to demonstrate the showstopper can be a good strategy.
Instead of "what about <showstopper>?" you could say "I think that might be a reasonable solution. What impact will <showstopper> have on it?" and now you've validated the good and brought up the potential showstopper without shutting down the conversation about it.
It is asking asking a legitimate question in a neutral manner. It’s not supposed to be a microaggression. Asking a legitimate question should provoke discussion, unless discussion is fundamentally broken in your current environment, which again would be good to know.
In other words, don't ignore the atmosphere and end up killing it. Which is kind of the point of the article, I feel.
This is super condescending.
We very often have discussions around which solution we take. Often we take the one that we don’t like as much but we know how to make it work. The other solution designs are kept so we can revisit them sometime (or as reference for when somebody says “why don’t you…?”) with fresh minds and then see a new way around the problems we saw before.
In my experience the “<showstopper>“ is almost never a law of physics but a shortcoming of a dependency, either it’s implementation or architecture, or just some assumptions that are or have become invalid later on.
I think in general, not just in the workplace, people are very fine-tuned to noticing false compliments or underhanded criticism, and it's always worse than just playing it straight.
That's you. Plenty of other people will defend whatever they come up with regardless and need to protect their fragile egos.
Something might not work, and if you know it won't and know a way that will, sure interfere (hopefully with tact), and steer the conversation towards a more likely solution.
But, if you only know why it won't work, but not of anything else that could work, than it seems useful to discuss further, but can't it be made to work?
The example that comes to mind for me is a non-engineer suggesting we relax important security constraints in a meeting with non-engineering decision makers present. In this case, the entire line of thinking is that it's acceptable to e.g. store unhashed passwords in the DB and not implement CSRF protection if it gives the team time to do other tasks, and it needs to be made clear that it's totally unacceptable to trade speed for safety.
It's almost always possible to explain why you shouldn't make a bad tradeoff like that, though.
So I was limiting the advice to engineering teams brainstorming solutions together.
Yes: I "only" know why it doesn't work... something I would hope would have extreme value, as I am not simply telling you "you are dumb" and refusing to discuss it, even if you don't understand the math or physics involved and thereby can't tell the difference; and I don't have something else for you that does anything similar: if I had any hope this was possible, I assure you I would be dedicating quite a lot of our resources towards figuring out how to pull it off. I will even admit that maybe, just maybe, you are correct, and what you want somehow can be done because everyone who has ever studied this before is wrong... but it isn't going to anyone on our team--not me, and especially not you, who figures this out--so let's spend our time talking about things that aren't a waste of our time and money. Am I a "negative Nancy"? Sure... if that's what you want to call someone who uses their time effectively."""
-- someone who has often been in the situation of having to have this conversation about the same scant handful of "obvious" ideas over and over again, often times for years (essentially, until the project is scrapped)
4 weeks for a brand new fuel cell is a bit short, but you can just buy them on the open market.
He didn't know that I had some "trial by fire" experience in previous jobs, and I calmly stood my ground. What he was proposing violated the second law of thermodynamics.
Thankfully the person running the meeting proposed tabling the idea. But it remained in the product requirements document for the duration of the project.
I learned that sometimes math and physics are best discussed privately. ;-)
Would you have preferred to remained silent and afterwards having to implement a physical impossible concept?
Also seen the ‘actually it was fine, the objector was just in a bad mood and couldn’t see past their own prior experience and was being a pain in the ass’ more times than I can count.
Which is why hopefully you have senior leadership that can see through the BS and get things moving in a workable direction.
I used to cut meetings up in a brainstorming phase, in which it was not allowed to say no to anything, and a filter phase, in which we narrowed down proposals to the viable ones.
Are there times when someone has to say TWW? Sure. But that should be reserved for situations where it isn't possible to redirect the conversation along more productive avenues or a potential solution is being ignored in favour of one that just won't work.
Instead try: Hey that would work if xyz were true. Result: people can think about why is xyz false, how do we flip xyz to true?
In my experience, “sometimes” means “very rarely”. The reason often has more to do with personality than any sort of technical obstacle.
The problem I often have is not with stuff that clearly just does not work. The problem is the stuff that "sorta maybe works" and then keeps working until it doesn't. You can't really prove it won't work, because hey, it does work. There's always some convoluted way of getting it to keep working.
It's really tough to make the argument that further down the road when the software grows, the scale grows, or the requirements change, the proposed solution won't be easy to adapt or won't be as robust/reliable. This is the really important stuff. I would say that investing in things that just never work at all and can't be made to work is more rare, probably still happens, but more rare.
A discussion that explains why it's a bad idea with the person arguing against the idea actually listening to the creator's defense is much better. Quite often people recoil at being told abrasively "that won't work" and end up taking the view that the person calling them out doesn't get it. Whereas a discussion where both sides have a push-and-shove to get to the conclusion sticks in the creator's mind and might even get them to stop pursuing it.
Pointing out said flaw obviously is the responsibility of the person calling TWW.
The last thing I want is an engineering team of yes-men, who don’t want to be ”bad team players”, and thus keep cheering ideas that Just. Won’t. Work.