Yes, the story is an urban legend, the budget goes up every time it's told, etc. But I think the important lesson here is not really "line worker outsmarts expensive consultants", its really about <i>incentives</i>. The consultants are incentivized to do good work (they want to keep a good reputation and potentially get more work) BUT they are also incentivized to charge as much as possible ("value-based pricing" is the term the industry loves) which means they will often try to convince you your problem is more complicated than it actually is<p>Similarly, the line worker is likely (correctly) to believe he won't be paid much more if he works harder, so his primary incentive is to just reduce his overall workload as much as possible and still get paid.<p>The best solution (and I believe a bunch of research backs this up) is to better incentivize your line workers and reward them appropriately. I know one study in particular that showed broad-based stock option ownership among employees was correlated with stronger company results, while options concentrated just among senior execs was not correlated with business success.
"The worker who'd placed the unapproved fan on the production floor was finally identified. They were counselled and sent to three days of mandatory retraining to ensure they understood that no further incidents of changing procedures outside of the formal change-approval process would be tolerated, and the installation of unapproved equipment was grounds for dismissal. The note on their file blocked any promotion, but the economy meant they couldn't change jobs. Eventually the learned helplessness and bitterness set in and they started amusing themselves by adding things from the break-room fridge to packages being shipped internationally. Five years later, they and everyone else were laid-off when a competitor figured out how to get otherwise unemployed people with cars and phones to deliver things for less than minimum wage."
After reading the problem definition, my reaction was: you'd either weigh it and use a solenoid to kick it into a defect box, or you'd use air to knock the empty boxes from the line.<p>I've seen both methods in use on production lines; so I assume that this story is something made up by someone trying to sell some kind of consultancy service?
Obviously an urban legend, and one of a series of legends in which a menial worker comes up with a simple solution to an apparently complex problem. Snopes has details on some of the others:<p><a href="https://www.snopes.com/fact-check/blue-collar-innovation/" rel="nofollow">https://www.snopes.com/fact-check/blue-collar-innovation/</a>
Even as an apocryphal parable to illustrate something about the extravagance of the solutions found by extravagant processes, doesn't this kinda fall short? The $20 solution is only found as a response to the $8M solution, which introduced a measurement and an incentive. I read this as suggesting that (a) workers closest to the situation can offer solutions if (b) measurements are in place and incentives are aligned and (c) they're given enough freedom to deviate from top-down processes.
From other comments I get it's a "urban legend" and it's meant to prove a point, but I guarantee anyone who has worked in a bigger manufacturing facility involving people has heard a similar story or has experienced one. Working as a production engineer I heard and experienced several, even though the sums in question were not nearly as big.<p>When I read the story, my initial thought was that there would be a link pointing to Toyota or Kaizen:
<a href="https://en.wikipedia.org/wiki/Kaizen" rel="nofollow">https://en.wikipedia.org/wiki/Kaizen</a>
<i>Point Kaizen - It is one of the most commonly implemented types of kaizen. It happens very quickly and usually without much planning. As soon as something is found broken or incorrect, quick and immediate measures are taken to correct the issues</i>
Sorry but this was stupid to me. Most of the weighing systems out there are going to use the bell alarm to actuate a pneumatic arm to push the offending box off the line to a reject pile.<p>What you actually will find is they will have an over and under bin so you can find out if you are over or under filling. It is a requirement by law that they weigh the product on a "legal for trade" scale if they are claiming it contains a certain amount.
The company would already have the weighing equipment in place, maybe farther up the line where the tubes are filled. They would simply have to move them down to the end of the line and change the weight range to add in the weight of a box and any other things added to the box and toothpaste tube.<p>I get that it is a thought exercise but wanted to add my 2 cents.
I think there are a lot of lessons here. Here is what I got:<p>One is that the simple $20 solution was discovered, but it may never have been. There was an element of luck in that. How often has that been the case in software? I see it all the time.<p>Given there is an element of luck, to maximise luck you want to pull in ideas from many places. Line workers are a great source of ideas. You can then apply a filtering process to decide which idea to try out. The fan idea would be tried out due to it being a low hanging fruit sort of fix.
This reminds me of a true story (yes, true not "true" I was there). I was a manager and representing my development area and my boss was there to greet the new client. We were a consulting firm, so of course we were paid to build things. The director of architecture was there, and he comes up with this plan to charge 100k for a solution of various needs. Surprisingly the client said no; they can't afford it, and we didn't get the business. The business was kind of shocked the company said no, then my boss sarcastically pointed out that everything they needed could be solved with Google Drive and 15 minutes on their phones to set it up.
A lot of people of viewing this as a positive story. I’m not sure I do.<p>Empty boxes are still making their way to the end of the process where a hack is being used to fix the outcome.<p>The problem of the empty boxes still exists. In fact, it could be many problems down the line.<p>I saw an interesting comparison of mechanics vs engineers where (no intended slight to mechanics) mechanics will fix the behaviour but engineers will perform Root Cause Analysis.<p>While I agree that the expensive consultants don’t provide much value, and the solution fix is affordable and nicely and lateral, I don’t think this is what you’re really want.<p>I draw comparisons to the endeavours that Tesla is making to more efficient manufacturing lines.
This reminds me about one of the topics that has been bothering me along my career as a technical
pm: when is the diverge part of the design process is finished? per my experience, many orgs underestimate the benefits
of “people thinking” and overestimate the benefits of being able to forecast when the solution will be available. And this, imho, is key when talking about startups vs corps... corps worry about the process because they can afford a subpar (8m) solution.<p>Ofc i’m being pedantic here and things are always more complex but... I have one question. How do you say in a safe way: We need more time because I FEEL that maybe, there is a 2$ solution for
this problem.
These are the stories that non-engineers like to tell themselves to feel smarter. Especially managers like to think they have more common sense than engineers.<p>But reality is that engineers are the ones who know most about the subject, they know the details how everything interacts with each other.<p>I had meetings with managers that thought their common sense could help me, only ending up me explaining the most basic of concepts to them.<p>Same with the NASA pen story vs pencil.<p>Most projects fail because of stupid managers that don't trust their experts. Not because engineers can't see the forest through the trees.
To me this is a story about reliability.<p>On two levels.<p>On the technical solution level the weight+discard solution is much more reliable. (let's ignore the stupidity that the expensive solution stops the production line. In the real world it would just blow out the wrong ones using compressed air) They have logs from the machine for auditing purposes. They have a very simple to understand knob (the threshold weight) and they can use that to adjust the system to changes in their product. The fan has none of this. If an empty box goes through nobody will know what to change. Maybe the conveyor was a bit stickier that day? Maybe someone set the fan to the lower speed? How to adjust the fan setup when we are making packs of tiny tubes for a hotel?<p>That's one level of reliability. The other is the organisational reliability. The CEO has the empty box problem. He wants it solved. He can commission an engineering firm who comes up with a solution. It will cost a pretty penny, but if the CEO is worth his salt he can write in performance requirements in the contract. They know they will get a working solution. Alternatively the CEO can go down to the line, he talks with the people there, he tells them about the problem. He offers an incentive for the solution. Let's say $2k. Someone proposes the fan solution, someone proposes to tune the filing machine more, someone proposes to measure the pallet of boxes with the forklift before shipping. How will the CEO know which one to pick? All solutions sounds very reasonable to him. Even after they picked one solution, how does he know it is working as intended? Who does he go to complain when a defect slips through?
"How a plan becomes policy"<p><a href="https://web.archive.org/web/20160531101830/http://ogun.stanford.edu/~bnayfeh/plan.html" rel="nofollow">https://web.archive.org/web/20160531101830/http://ogun.stanf...</a><p><pre><code> In the beginning was the plan.
And then came the assumptions.
And the assumptions were without form.
And the plan was without substance.
[...]</code></pre>
There's a ton of these stories around. I think they're great. I don't get all insulted by them; even if they are meant as such.<p>In my experience, robust is simple. The best code is the code I don't write. The eraser is my best friend.<p>If I want to write code that has the fewest bugs, I need to write the code with the fewest lines possible.<p>Every line of code is what I call a "trouble node." That's a place where a bug can happen.<p>I also need to take the simplest, most straightforward approach possible. Horse sense is valuable, and a lot of my horse sense comes from painful lessons.<p>When I'm writing code, and I find myself starting to rabbithole one kludge over another, I often have to stop and just wipe the slate clean.<p>Take off and nuke the site from orbit. It's the only way to be sure.<p>When I was working for corporations, this was never an option, and I (and my team) always paid the price. Since working on my own, I've done exactly this a dozen times over.<p>It's great.
I feel that being practical in the engineering is one thing but an overemphasis on practicality could also be dangerous in that it could build up technical debt down the road to the point of no (easy) return. Therefore a balance has to be struck.<p>Though the top comment's interpretation about the difference between the incentives of consultants and regular workers, and how workers should be rewarded more for good work, is very interesting and definitely rings true to me. The importance of proper incentives/reward mechanism is overlooked in many companies, which is a shame.
I love it, as soon as I read first part, I started over engineering solution. And at the end I was wow, so simple ... someone told me long time ago truly genius things are simple.
It's a great anecdote but good manufacturing organizations have long realized that you need engineers, managers and the workforce on the floor to constantly communicate and get everyone to pull together. One big problem is the culture clash between white and blue collar, unfortunately.<p>And every once in a while outside consultants aren't the bloodsuckers they are made out to be.
<i>Due to the way the production line was set up, sometimes empty boxes were shipped without the tube inside.</i><p>Fix the root cause of the issue and you won’t need duck tape and bailing wire everywhere to fix all the proximate problems. Lord knows what the rest of this nightmare environment of “fixes” looks like.
We undermine line workers in Software Engineering world as well. We tag them as "hackers" or "folks who take short cuts" or "don't do good job" when we see an unconventional solution. We need to understand the perfect solution differs from case to case.
Cool story. Here's a real one, if anyone's interested...<p>A Tiny Mistake
<a href="https://pastebin.com/gZa36S0K" rel="nofollow">https://pastebin.com/gZa36S0K</a>
I misread the problem definition, assuming the problem was that the boxes were partially filled (e.g. 29/30 items shipped). How would you solve that in another way than a scale?
Reminds me of Daryll from the office. Blue collar innovation. There's talent at every level in corporate hierarchy. What it needs is flattening the hierarchy.
I always wonder... where does this faith in "blue collar thinking" over fancy-pants engineers come from?<p>Why do people think the engineer wouldn't suggest a fan?<p>Obviously it's an urban legend... but it just makes me wonder what makes it so repeatable, similar to how everyone's heard the similarly apocryphal story about how NASA invented a million-dollar pen while Russia got away with pencils just fine.<p>The reason I wonder, is because sometimes I worry that this supposed "faith in common sense" is really just an "anti-expert" bias that is precisely the kind of thing that leads to disbelieving climate change, antivaxxers, not wearing masks, and anti-intellectual populism generally.<p>Especially in 2020, I wonder if this is a kind of thinking that shouldn't be particularly encouraged... :S
<i>Topically</i>, the presumed explosion danger from hydrogen fueled aviation is also eliminated by installation of electric fans.<p>But they do need battery backup.
the line worker that came up with the idea probably didn't even know that engineering was spread thin and external firm was hired to find solution. Even if he did, his idea would have been thrown out.
> <i>A Short Story for Engineers</i><p>JFTR, Every time I see such titles it curios me: which type of Engineers it directed for: Software, Civil, Social, etc.? It should be clarified in the title, because all of them are different.
I read comments and many are saying "is it urban legend" I do not think so, we underestimate people ability to complicate things and make mistakes.
Does anyone remember story how NASA lost 125 million orbiter because measuring unit mistake>
<a href="https://www.simscale.com/blog/2017/12/nasa-mars-climate-orbiter-metric/" rel="nofollow">https://www.simscale.com/blog/2017/12/nasa-mars-climate-orbi...</a>