“That Won't Work”
meetryanflowers.com
meetryanflowers.com
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.
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.
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.
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.
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?
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.
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?
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.
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.
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
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?
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
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.
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.
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.
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.
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.
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.
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 .
So no, this isn't contrived. Some cultures are just pretty blunt.
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.
This is not me trying to say “that won’t work” :)
https://www.youtube.com/watch?v=BKorP55Aqvg
An expert "That Can't Work" early saves a lot of time.
A lot of these debates about interpersonal issues come down to personality differences of Jung types.
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.
> At this point you have to decide whether it's really worth the energy or not.
Basically I see this as a benefit
The written design defends against, “this is just a toy” even if you’ve thought it through for countless hours.
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.
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.
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.
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.
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.
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.
Ok, but in the context of work conversations, though. I still think more of them can be recovered than our instincts first tell us.
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.
I wonder if they started out as "That Won't Work" people, but evolved better defenses?
...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.
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 skills of the team members rarely mattered as much as that one 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.
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.
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.
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.
https://research.msu.edu/workplace-negativity-can-hurt-produ...
Is this the one you're referring to? It states that:
> Employees who point out problems in the office may help the company improve, but could be hurting themselves in the process.
Couldn't find the link to the actual paper though.
I suppose this is just the manifestation of the best way to motivate an engineer being to tell them something is impossible.
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 :)
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.
Here is one example: https://ieeexplore.ieee.org/document/1250910
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.
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.
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.
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.
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.
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.
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.
https://www.goodreads.com/quotes/285436-in-the-beginner-s-mi...
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 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.
-- Richard P. Feynman https://www.atomicheritage.org/key-documents/feynman-los-ala...
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.
-- Feynman 3: The Bomb and then Depression http://kenschenck.blogspot.com/2014/08/feynman-3-bomb-and-th...
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).
https://old.reddit.com/r/dredmorbius/comments/2fsr0g/hierarc...