Sometimes a blunt ”that won’t work” is needed, to save the team valuable time. There is no point in exploring implementation details of a solution, if the proposed solution has a fatal flaw.
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.
90% of "that won't work" that I've seen in my career is really just "I don't like your idea, I like my idea better" in disguise. If something really won't work because of some fatal flaw or because it's truly a stupid idea, then sure you need to speak up.
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.
Years ago, I was leading the R&D in a start-up. The CEO was full of ideas. Some of them were very good, some really bad, most completely ill-matched to our priorities and limited resources. It quickly became clear to me that my job was being the "that won't work guy", in an attempt to make sure that we managed to finish our project before we ran out of funds.
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.
Interesting. I read the article as if it was talking about problems that needed solving. You're talking about ideas that (in the interests of the business) need shutting down.
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?"
Sure, you should not shut down ideas when brainstorming solutions, but there's a point between brainstorming and implementation where the ideas do need to be reviewed mercilessly. The problem in the parent poster's company wasn't that they brainstormed about a home-made project tracker, it was that they went through with spending development effort on that.
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.
It can be both, I read the comment you are answering to as problems that need solving. "A reimplementation of git" or "a home-made bug tracker" could be trying to solve the problem that they didn't have version control nor a bug tracker, but the proposed idea of creating one from scratch instead of using an existing one (in these clear-cut cases) is ill-advised.
In this specific case, both git and a variety of bug trackers were available and very usable. Neither project answered a precise problem we encountered. Both might possibly have answered problems we might possibly have encountered when scaling up, something that never happened.
Yes and I completely agree with it but sometimes you need to have some money coming in so you go along with it even if a team implementing a micro services architecture says with a straight face they won’t know what all will have direct access to my micro service data store but expect low double digits. The number I would expect was zero!
What do you mean by custom standard library? At a glance that seems like a good idea to me. A collection of internal and external libraries that we just install no matter what.
Edit: do you mean you're using C and replacing stdlib.h? If so, yeah that sounds like a bad idea
In my experience as a Dev Manager the easiest way to solve this is to put the expectation for coming up with a solution on the interjector or negative person. This is super effective in filtering the passionate contrarians from the the generally negative because it requires the person to do work, and the default to "no" people rarely will take on the responsibility.
Trying to be aware of your limitations and exposing those in your speech is one way of reducing the frequency of having to eat your hat. "If we do that, I think this would happen . . ." is so much more productive than "that won't work," because it allows you to start discussing the why, without the proposer feeling attacked.
That is why I think it's important we suffix our beliefs with a degree of belief. There's a huge difference between
- "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 %.
I had a manager tell me "it won't work" after I'd done a proposal that involved an algorithm taught in undergraduate computer science. I expected most of the team would recognize the algorithm and see how it could be applied.
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.
I don't disagree. I'm sure he believed it wasn't worth the time or effort. I'm sure the CTO didn't either. I was way behind them. They knew what I didn't know at the time: the company was not interested in investing in the project I was working on. They considered it finished.
Yeesh, after trying to block it multiple times and then telling them you still think it won’t work even if you’re letting them “waste” time on it, that’s some serious humble pie to eat! How did that go?
Yeah, I'm still embarrassed about it. Fortunately, we were all so excited about how well his crazy idea worked that he never held it against me. I was careful not to accept any credit whatsoever for how it all turned out, though.
> I was careful not to accept any credit whatsoever for how it all turned out, though.
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.
I'm not the OP but I have had similar experiences along the way.
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.
In my experience, saying "that won't work" as a direct response to anything a peer proposes is too early (or someone even resembling a peer).
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.
Whoops, you missed your chance to object and now you've just signed up to fix the hard parts of someone else's bad idea!
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.
Isn’t there a reasonable middle ground? One could just say what they mean: “I have some major concerns about this idea.” It doesn’t shut anything down while still communicating there is significant pushback.
Of course, and finding that middle ground is key to good communication. My point was that "contemplate more, advocate less" is only the correct advice if you're currently contemplating too little and advocating too much. The opposite situation doesn't just exist, it's common, especially among us nerds, and the cure lies in the opposite direction.
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 :)
That, plus most of the times inclined to say TWW, even if you are so because of a feeling, you can tie it at least intuitively to a use case, a specific part of the system that would be challenging etc. in these cases a good middle ground is to ask “how will that work for … “
I think rephrasing the comment (as the post suggests) in terms of "that might work if we can [resolve fatal flaw]" is a good suggestion, in that case. It's a much less negative way to point out the flaw.
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.
There's an important callout here that often someone's "showstopper" isn't correctly viewed as a showstopper elsewhere.
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.
If you just say "what about <showstopper>?" without offering a way to continue the discussion, then you might come off as TWWP. I would suggest that it could be phrased in a more constructive way, which was the point I tried to make in the article.
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.
> without offering a way to continue the discussion
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.
If you're in a brainstorm session for solutions (which is what this sounds like), keeping a positive flow is way better than halting to consider a neutral or even a negative.
In other words, don't ignore the atmosphere and end up killing it. Which is kind of the point of the article, I feel.
I suppose if you say it with a superior tone and act like you know better, sure. It's all in the delivery. If you ask it as a genuine question, assuming that you don't have the answer, then I can't see how it would be taken that way by most people.
No, it's not the delivery, it's the content and the fact that you're lying to save the other person's feelings. Specifically, the lie is that you think the solution is "reasonable" in the same breath that you raise an objection you believe puts it in serious doubt, if it's not outright fatal. You can deliver that in perfect sincerity and if I see what's going on, the condescension will come through crystal clear, because I'm not a child.
It doesn’t need to be a lie. You could be seeing that the proposed solution is way better than everything else out there including the existing solution. If only you could fix “<showstopper>” somehow.
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.
that sort of faux-diplomacy annoys me more personally because it always is blatantly obvious what the person is trying to communicate, and it sounds like it comes out of some kind of corporate PR training session. Like, if someone thinks what I does suck I always invite people to tell me so. If you're trying to sugarcoat it not only is it obvious that you think the idea sucks, you also think I can't accept your opinion, that's worse lol.
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.
As mentioned often "that won't work" is a good way to cut off all creative thought processes and should be limited, but there are definitely times when a quorum of uninformed parties are about to commit to 'an investigation' where someone calling it straight is appreciated
I'd agree with this. The article specifically mentions the need to analyze rather than jump to conclusions, and "That won't work!" is usually a case of the latter. If TWW is the result of an analysis, then it is definitely not what I was referring to in the article.
The post actually convinced me against what you're saying.
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.
Hum, arguably that's not the scenario that I imagined the article talking about. I feel stakeholder and business partner meeting don't really qualify as "team problem solving" in my mind.
So I was limiting the advice to engineering teams brainstorming solutions together.
"""No matter how many times it comes up, I can't build you a perpetual motion machine. I know it can't be done--and, more to the point, have explained why multiple times--and I would rather not the entire team continually have giant meetings attending to discuss how to build it anyway. It doesn't motivate me that you have found a customer for it, or that you have come up with a million ways it will make the world a better place: we have an actual engine that we are trying to ship here, and your insistence upon wasting my time and energy requiring me to explain over and over again why your perpetual motion machine is, at least, something that our team isn't going to come up with, is so far past distracting as to potentially be active sabotage when you convince our users that they should wait for it to be implemented, or get our marketing department hyped about the possible new markets it will open up for us.
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)
"OK, understood, these perpetual motion machines don't work. So once and for all let's do away with the motion. Luckily we have a new project which doesn't involve motion: we just have to ship a device which produces more electrical energy than one has to put in. Is 4 weeks enough? "
"Oh in that case we probably need some new hire with special knowledge. Like that new age engineer showing his free energy device on youtube. Or well, maybe not this one, he did not even to manage to hide the electric cables going into his magical maschine, but this one over there, publishing at infowar looks trustworthy"
I had that experience once. To make it more interesting, I was the lone physicist in the entire company, and a brand new employee in a huge meeting full of company brass. I told the product manager that something wouldn't work. He stood up from his chair and shouted at me.
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. ;-)
In relation to this, there's a great quote "The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data." by John Tukey.
The issue I’ve run across is the passive aggressive approach (aka what some people often mean re:tact) can delay having the direct conversation and then people spend the next 6 months noodling around hypotheticals until the original objector is worn down and says fine - and then the project fails because sure enough, it didn’t actually work. Seen it at least twice.
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.
The post argues (rightfully, I think) that even if the proposed solution has a fatal flaw, shutting it down does not save the team valuable time, because even if the solution isn't The Right One, its proposal can spark the creativity in others to come up with what is The Right One.
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.
That was my original response, but the author's point was about proposing potential solutions rather than affirming bad solutions. It isn't about good team players by being yes-men. It is about creating an environment where people are comfortable with proposing solutions that may work. Notice that the author was talking about redirecting the conversation rather than being agreeable.
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.
Did you read the article? You’re free to TWW, but rather than shooting the idea down you bring up the constraint that breaks the idea. Not: “hey that won’t work because xyz”. Result: people discouraged.
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?
Can't the fatal flaw always be duct-taped over? ;)
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.
Been in the industry for 15 years. I never met any situation like the one described in the post.
People say “that won’t work because X”, and others reply “yes it might work because Y”
Usually things end up with “let’s give it a shot” or everybody agreeing that it won’t work.
In a few rare cases, people disagree and the discussion can heat up, but eventually the thing that’s decided will or will not work, and resolution will come from there.
Please don’t just box people in non-existing “that-won’t-work” persona .
It reads as a strawman arguement; the first proposal is to let bad ideas get discussed since they might inspire good ideas like a reborn phoenix. But really, a good idea will likely inspire better ideas, without the baggage of a myth.
Been in the industry for close to the same time and it has come up multiple times in companies of all sizes (15 employees to 10k employees). It may be the culture (West and South Europe), but that didn't stop people from continuing the train of thought "hold on, let me finish".
So no, this isn't contrived. Some cultures are just pretty blunt.
I've been drilling into my kids' heads that far too many people think they are the smart ones by being the naysayers and by saying something won't work. It's lazy and it's useless. It's easy to pooh-pooh an idea and point out its flaws.
The smart and effective people are the ones who say "How can we get this to work?" That takes creativity and thoughtfulness. I have indoctrinated my kids to say "How can we get this to work" instead. I hope it takes hold as they grow older.
Funny video, but just for fun: you could write the words “red line” with blue ink and use carbon paper with no or transparent ink. Also you could draw 7 perpendicular functions on 7 lines... https://en.wikipedia.org/wiki/Orthogonal_functions
A lot of these debates about interpersonal issues come down to personality differences of Jung types.
I agree and like your philosophy, but it is also a bit of a trade off. There are lots of situations where spending time trying to make things work where you think they otherwise wouldn’t can waste time or cause further damage (like relationships).
It is all about the right balance. Also, there many things we "could make work" with a lot of effort, but mostly it is about finding a way to achieve better results with less effort.
My first response is "why?" From there we can explore what the actual problem is. If it's a rational "that won't work" with a plausible reason, we can just drop it there.
If I'm unsatisfied with their reasoning, I can either lobby for it if this person has influence enough to block it, or just ignore the person otherwise.
Unfortunately, in politics a good way to block something is to bury it in paper: "Hey that's great! Draw up a proposal and we'll bring it up next meeting!" For this you need to go full-on political, with all the crazy games that entails. At this point you have to decide whether it's really worth the energy or not.
I had one particularly terrible manager whose response to any new idea was "Great! Make a Github issue for it!" Some employees even made a meme of it. By the time my tenure there ended, the GH issue list was thousands of entries long with no action taken on anything, and no way to find anything in that huge pile anyway (basically a garbage dump by design). For these kinds of situations, don't expect to have any impact.
I'm not sure I agree with the the last 2 paragraphs. Maybe it could be abused by political types but I feel like making someone write out their idea forces them to think it through and sets up some filter for ideas. Honestly if you can't get your idea through something as simple as writing a proposal then how do you expect to it get through any other challenges that come up during implementation. Also, why aren't people following through on their great ideas? If they're actually so useful why are they sitting a graveyard of ideas?
> At this point you have to decide whether it's really worth the energy or not.
>Maybe it could be abused by political types but I feel like making someone write out their idea forces them to think it through and sets up some filter for ideas.
I think as your organization gets very big you need to do this to be able to have any overview, the problem is that when your organization gets very big this is also the time when political types start to use these tactics to gain more power.
Yup, there are good faith and bad faith ways to say "draft a proposal". I was continuing in kind with the "That won't work" themes of this article, speaking to the bad-faith situation where it's just a way to push the idea into a graveyard. If your manager is trustworthy, then of course drafting a proposal is an important step.
> Consider the incorrect solution, and unless you can come up with something better, say nothing at all.
I don't think this is a good conclusion. Some problems are just hard, and avoiding talking about hard problems because you don't have a solution is a great recipe for never solving hard problems.
Good communication skills can be helpful here. It's certainly possible to offer critical feedback without hurting peoples' feelings and without discouraging them. You can frame things to excite people about finding a difficult problem to solve, instead of sounding like a poo poo head.
I think this article is creating a false dichotomy. You can point out flaws in a constructive way, without destroying souls.
I've always been the "that won't work" person in whatever organization i've worked in for the last 35 years (fortunately for most organizations, I've been self-employed for the last 25 years). I think this article is needlessly negative. I view my "that won't work" contributions as the reason why it did work (eventually).
As others have noted, it's important that "that won't work" is accompanied by actual reasons (and reasoning). But it is often important to have a nattering nabob of negativity, especially with a younger cohort full of positivity and possibility and not a lot of battles fought. Most of the time, it can be made to work, but often that requires the injection of a voice mostly full of objections, problems, issues, overlooked items.
Like you, my superpower is to "look for trouble." For some reason, my mind looks for the potential weak spots in any plan, and I'm darn good at it. Of course, it's much easier to find them in other people's plans than my own...
Also, the nattering nabob of negativity is important in reminding people that prioritising the thing that probably won't work or is difficult to make work has the opportunity cost of not prioritising things that will work. Sure, the negative voice might occasionally deter you from finding an incredible solution, but the positive voices about ambitious ideas are always deterring you from focusing on fixing other stuff.
I view my lack of success as the "that don't won't work" person in one role as the reason why we had a number of half finished products that didn't work or didn't sell. At least if a team agrees to try something that probably won't work because the rewards are so huge (or the implementation is easy and it's just the results that are questionable) they've thought about the resources needed, and won't either give up at the first hurdle or plough far more into it than it'll ever be worth.
I'm reminded of the "sailing downwind faster than the wind" fiasco. One guy had an intuition that said it could be done, but everyone pooh-poohed it on energy conservation grounds until he built a full-scale machine and actually did it.
Perpetual motion machines (and unethical behavior, another good example in this thread) really do need to be shot down fast, but they're rarer than they might appear, and sometimes an idea that looks like PMM-level fantasy can be brought to reality by modest changes in its assumptions. I like the idea of literally saying "what about energy conservation?" If you say that and actually have an open mind, maybe you can figure out how the energy budget really does add up, and even help figure it out.
You still need to be prepared to deliver a hard TWW when needed. When? No blog post can answer this. It's a judgment call. As usual, there are no shortcuts.
> Perpetual motion machines (and unethical behavior, another good example in this thread) really do need to be shot down fast, but they're rarer than they might appear
They really are not, a stint at (or getting chummy with) the nearest patent office demonstrates it quickly.
The machine you mention is pretty much the exception that proves the rule, and unintuitive enough that yes it did really need a proper model.
> One guy had an intuition that said it could be done
There are dozens of guys waking up with the intuition that a PMM can be done every day.
Better to keep quiet than to criticize it without bothering to study it though. Unless your criticism is simply "most inventions that look like this are PPM so yours probably is too."
Another story of the same type was somebody trying to recover waste heat from shower drain water to put back into the shower water. It was poo-pooed for violating the 2nd law or something. But the poo-pooer neglected the fact that hot shower water is made from a mixture of hot and cold water, so the cold water could be heated by the warm waste water.
When I was an undergraduate, I suggested some ideas to my classmates that would now be called "static analysis". About 1/4 of them would reflexively respond with "That won't work: halting problem". They were vaguely aware that someone infinitely more clever than us had proved the impossibility of something having to do with code analyzing code, and so they considered the whole topic off limits forever.
Strangely they didn't emphasize that a concrete objection is necessary rather than just an unexplained rejection.
To me, "that won't work because" is totally fine, as long as they have a good reason.
The article says "incorrect solution".. I think this is also the wrong perspective. Ideas are not monoliths. The starting point is the specific reason you think it won't work.
A lot of times, the best ideas hinge upon solving some difficult problem, but they are rejected without consideration because other people in the room don't have problem solving skills and so see any proposal that requires problem solving as unworkable.
This is exactly what I was thinking. Saying "that won't work" with out a reason is a total dick move. But giving A reason can still spark ideas and conversation about how to work around that reason.
It's pretty close to a terrible response which is just the reason it won't work, such as "That'll take too long". Often it's a valid problem but one that can be solved except it shuts down the conversation by making it seem like a brick wall. If you don't immediately know how to solve the problem, it's hard to argue that "My intuition says we can probably find a way round that later".
There's also the "That Won't Work" person's sibling: the "I Don't See a Use Case" person. In my experience, "I Don't See a Use Case" people require more sophisticated tactics if you actually want to get something done while they're around, not least of all because they move the game to a harder field: "that won't work" at least states a fact, whereas "I don't see" moves us firmly into "belief" territory, and "a Use Case" invites us into the trap of dreaming up our own strawmen for them to tear down one by one.
I wonder if they started out as "That Won't Work" people, but evolved better defenses?
When I hear this phrase, I think of GNOME. Can't count how many times the developers of GNOME have knocked back perfectly sensible pull requests or feature proposals on this basis.
...often only to implement the exact same feature later when it appeared to be their own idea instead of coming from the outside.
It's just an excuse to be insular and shut anything down, which is their default response to anything coming from the outside.
I promise I’m actually curious and not trying to be difficult: is this the same as asking “what problem does this solve” or something different? I’d love a concrete example but I know that might be hard without using a real topic.
I think it could be the same but it doesn't have to be. "What problem does this solve" is a bit more generous as at least, on the face of it, it may offer an opportunity to provide an answer that will be received in good faith.
But I think this is less about specific phrases one might need to be careful not to say, and more about the kinds of default attitudes that can turn into ongoing impediments to the free flow of ideas. It's definitely possible ask "what problem does this solve" without becoming the "What Problem Does This Solve Person", and the same goes for the other phrases too.
The phrasing is less important than the attitude - if you're actually open to a use case to justify the request, I wouldn't care how you asked. If you want me to put a round in the chamber so you can shoot my idea down, I think I'll keep my user stories to myself.
I recall a study that seemed to show the productivity of a team can be predicted by determining if they had a negative person or not (they had a different term that I forgot).
The skills of the team members rarely mattered as much as that one negative person.
You need to be very careful about a label like "negative person".
I have been accused of being a negative person before. We had some tracking web application which had an editor which took very long to load on the web page and made it painful to enter new data. I was in a meeting and said plainly that the editor component "sucked". I was chastised by the manager for being negative.
Meanwhile as soon as I got out of the meeting, I googled it and found that there was an option to disable the graphical editor, which we did. Because it sucked (was unacceptably slow).
For many people, simply pointing out a problem is "negativity". Part of the reason it's like that is that many people have little to no problem solving skills or experience. So describing a problem is just noise, since there is nothing they can usually do to resolve problems.
Whereas someone who has a lot of experience solving problems knows that the first step to solving problems is to acknowledge that they exist.
> I was in a meeting and said plainly that the editor component "sucked".
When you communicate using harsh or even rude language many people will ignore what you said and respond to how you said it.
Communicate this way more than once or twice and people will permanently put you on the "pay no mind" list -- no matter how great your ideas you'll find yourself perpetually ignored.
I have met a lot of capable and productive people in the software industry who do not know this.
It wasn't rude, it was a good way to describe it. People who would write me off for using that word don't deserve my time.
You missed the point, it wasn't about that word or about me.
Which by saying that you imply that I was acting childishly. Culturally we are different then. That part of the system sucked as it was currently implemented. It was and still is an apt description. I will be happy if we don't attempt to communicate in the future, since we have a different culture.
Negative, unconstructive criticism is highly underrated.
Sometimes that’s all you need, and it’s a waste of time to try to embellish it, if the reporter is even qualified to do so.
I’ve never felt such relief as when a salesman pulled me aside to tell me the product sucked and for me to explain what the hell I was doing. Now I finally had an ally against all the yes men who were blocking real improvements.
It's not clear from your comment. It implies that it was not made by anybody on your company, but it doesn't assert it (and there are plenty of cases where one would google about something somebody nearby had developed).
And the GP is not missing your point, you are missing his. He is trying to point that if it was an internal development maybe your language was indeed rude (that really depends on a lot of context to decide). If that's the case, your manager may not be wrong.
This reminds me of one of my pet hates; you pose to the team an issue that needs solving, or perhaps you're in the middle of solving, and someone pipes up with "Couldn't you just X?", where X is the first thing any competent person might think of. Yes, sometimes we overlook the simple solutions and get caught in our own bubbles, so there is some value there. Personally when I find myself wanting to "couldn't you just" someone I start with more probing questions because I'm going to assume the obvious answer was the first thing tried/abandoned, which is why we're even talking about this.
I suppose this is just the manifestation of the best way to motivate an engineer being to tell them something is impossible.
If you didn't explain why X doesn't work, it's absolutely justified that people ask if that simpler solution X would work as well. Assuming you considered "the obvious answer" is unfortunately often not sufficient, as what's obvious to one person might not be obvious to another person.
The "just" questions have their place, but more often than not, I've found it there's more than one they use up the available conversation energy.
By the time all the obvious "justs" have been asked, and explanations why not for the n'th time have been given, the worthwhile meeting energy is exhausted and the original purpose of making a proposal is rendered pointless. You can see this outcome long before the end of a meeting too. If you see it coming at the start, maybe you won't bother making the proposal in the first place.
It's not a bad sort of question, rationally. It's more that it tends to be accompanied with dismissive, looking-down yet shallow thinking, when what you needed for a useful meeting was engagement with the "meat" of the issue, not shallow dismissals.
I knew someone who worked at a place where the word "just" in conversations was called out humorously with a silly noise, even when said by accident, to discourage it :)
I feel like I used to get the question a lot at my previous job. When it was from people without a technical background it made little sense and was usually just a waste of time.
When I got it from another programmer I didn't mind as much. Even if it should be obvious I'd already tried it, I know that the few times I've asked it myself it's because I'm genuinely curious why the obvious answer didn't work. Then again, I would probably word it differently.
I think corporate culture is an important part of it. I see a lot of comments in discussions like these which make it sound like technical discussions tend to be a series of passive aggressive jabs and office politics. I've never had a job like that. I've certainly seen more office politics than I would like, but it didn't creep into technical discussions.
The article reminds me of the "Yes, and..." rule from improv comedy. In replying to someone else's proposal, creating a habit of literally starting your sentence with "Yes, and..." is a way to build collaboration skills.
Finding a good solution and rejecting a bad solution is the same thing, both are positive steps towards the goal. In science this happens a lot. Some research is generated using a flawed procedure. Someone writes a paper criticising the procedure and demonstrating that it doesn't work. The procedure is abandoned and the critique saves a lot of scientific effort and funds from being wasted on empty pursuits. This is a big positive.
There was an article not to long ago on HN which talked about why the phrase "It turns out" is an intellectually dishonest argumentation tactic disguised as a passing remark, to make an argument completely devoid of any evidence sound as if it's backed by lots of (otherwise unstated) evidence.
I agree.
However, I find it works beautifully as a counter-attack to similarly dishonest argumentation tactics relying on lack of evidence for their punch. "That won't work" is one of them. All you have to do is say "Actually, I too had considered considered it would not work ... but it turns out it will!", and, voilá, end of diversion. Your opponent will either accept your dishonest "yes it turns out it works" tactic as fact, in which case you can ignore the naysayer and continue arguing your previous point, or your opponent will ask "why does it 'turn out' that it will work?", in which case you can turn their fruitless exclamation into a counter-question of "oh, many reasons, 'it turns out' ... what was the specific reason you felt it would not work?", lead yourself down a 'fruitful' discussion instead.
PS. The objective being, discussion. Not debate. If you're after debate instead, then maybe not the best way to counter this.
In my (admittedly limited) experience, Very Successful People say versions of "that will be really hard" very often, and say "that is impossible / won't work" effectively never.
I'm not sure if this is causation or correlation, or even which direction a possible causative link would flow in (eg being positive + open-minded makes you more successful vs. being successful makes you more positive + open-minded). But it's absolutely a pattern that I've noticed.
To generalise, the attempt to move the discussion from negative to a positive spin is really an attempt to harness the wisdom of crowds.
In my experience, subtle changes to working practice, team behaviour, meetings and discussions seem to have significant impact on the quality of work produced. I'm sure we've all been in situations where progress seems to be like pulling teeth, and other times when progress comes easily.
One other aspect - "It won't work and even if it would work we don't have the skills to execute it" has a strong prior probability. Easily 80% of attempts fail or are inappropriately skilled at the start.
That means someone saying consistently "this won't work" is (a) generally going to be right, so feel clever (b) very likely to miss all the big opportunities in life.
If you want to be really subversive tell them X is a great idea. But if you want to do X you have to do Y, and Y is impossible. Worked at Bloomberg for a couple of years. That was standard procedure to discourage any innovation.
A very good article, especially as I am often the "that won't work" person and I am aware of that and want to change. Only critique in the example at the end felt like everyone was already the "let's make it work" group without the "that won't work" person pulling down the bunch, I was hoping to hear an example of overcoming an "that won't work" person and turning them into a problem solver too!
OP/Author here. I think the takeaway there was my admission that I used to be a TWWP, but by not being TWWP, I was able to become part of the solution. I am glad you liked the article otherwise :)
If you are working with other people to figure out if a proposed solution could work, claiming "That Won't Work" is not a very constructive remark.
A far better way is to ask questions about the things that you consider flaws. It gives the others the possibility to give more information that you had not considered before or discover that they had not considered that problem. In both situations the group as whole has learned something.
I thought of "If an elderly but distinguished scientist says that something is possible, he is almost certainly right; but if he says that it is impossible, he is very probably wrong."
If anyone with experience says something can't be done, you shouldn't necessarily take it as the final word, but when someone says something can be done, or can be done better, that's where experience pays off.
I had to look up the quote, it was by Arthur C. Clarke, science fiction author.
As a soon-to-be-elderly and yet-to-be-distinguished scientist, I don't think we have a good answer for what to do about the fact that at any given moment, our present-day knowledge might be wrong. I think that science and science fiction have different and irreconcilable approaches to that problem.
In many cases, when I say something can't be done, rather than just leave it at that, I try to explain what parts I think are strictly impossible (this is actually rare), what parts are straightforward but require more effort than might be available, and what parts are likely to be legitimately hard due to the level of domain knowledge needed just to get started.
It seems to me there might be some conflating between 2 points going on in a lot of places:
Whether or not something will work in absolute technical terms.
Whether or not something is a good idea within the current business context.
Quickly distinguishing between which conversation you are having can moderate the discussion. I am prone to assume we are having the first conversation, which can occasionally cause friction with the business stakeholders.
One of the first experiences that was very interesting to me in this project at Princeton was to meet great men. I had never met very many great men before. But there was an evaluation committee that had to decide which way we were going and to try to help us along, and to help us ultimately decide which way we were going to separate the uranium. This evaluation committee had men like [Richard] Tolman and [Henry DeWolf] Smyth and [Harold] Urey, [Isidor I.]Rabi and [J. Robert] Oppenheimer and so forth on it. And there was [Arthur] Compton, for example.
One of the things I saw was a terrible shock. I would sit there because I understood the theory of the process of what we were doing, and so they’d ask me questions and then we’d discuss it. Then one man would make a point and then Compton, for example, would explain a different point of view, and he would be perfectly right, and it was the right idea, and he said it should be this way. Another guy would say well, maybe, there’s this possibility we have to consider against it. There’s another possibility we have to consider. I’m jumping! He should, Compton, he should say it again, he should say it again! So everyone is disagreeing, it went all the way around the table. So finally at the end Tolman, who’s the chairman, says, well, having heard all these arguments, I guess it’s true that Compton’s argument is the best of all and now we have to go ahead.
And it was such a shock to me to see that a committee of men could present a whole lot of ideas, each one thinking of a new facet, and remembering what the other fellow said, having paid attention, and so that at the end the decision is made as to which idea is the best, summing it all together, without having to say it three times, you see? So that was a shock, and these were very great men indeed.
Feynman, once again working best in conversation, ended up almost by accident in a conversation in Los Alamos with a seasoned theoretician named Hans Bethe. Bethe would bounce ideas off of Feynman, who being very loud could be heard to cry out, "No, no! That's crazy." From Feynman's recollection, Bethe always proved to be right. From Bethe's recollection, Feynman was probably the most ingenious person in the whole division.
Bethe was the scientist who discovered that fusion fueled the sun. Bethe said of Feynman that "he could do anything, anything at all" (87). He was put in charge of the computing division. You have to wonder whether the Manhattan Project would have ended before the war if Feynman hadn't have been there.
My own experience is that there is a hierarchy of failures in problem resolution (or if you prefer: a requisite chain of successes), beginning with the realisation that you have a problem. Reality gives no figs whether or not feelings are being hurt, and if your culture won't permit others to point out that there is in fact a problem, your culture ... is part of the problem. Identifying solutions is several steps removed from identification of a problem (let alone diagnosis of cause).
Author had an idea, someone pointed out a flaw in the idea, author reduced that down to "that won't work!" and went on a crusade against "thatwontwork-ers". It's a nice TEDX talk I didn't sign up for.
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.