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.
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.
If you are a high-level exec, the domain you have, the levers and pulleys available to you, are asking your direct reports to investigate the issue and come up with a report on the problem and generate potential solutions, which will then be discussed and evaluated in meetings–at a very high level. To somebody on the ground level, the domain of the problem is "what do I have around me to save time? oh, I have a fan, let me use that. Done."
I think your point about incentivizing workers is part of it. This story reminds me of the This American Life piece about the NUMMI plant where Toyota worked with GM to teach them the Toyota way of assembling cars. [1] Part of the Toyota Way is to empower the individuals at the ground level to own the process and to improve it. The interviews are surprisingly emotional for something that's "just work", but I think it shows how empowering people to own and improve their everyday gives them agency.
Parables are dangerous, because they sound good and appeal to common sense, but it turns out that in real life common sense is often not correct. Common sense works best when applied to situations encountered in the ancestral environment and does not necessarily convert over well to systems engineering.
I was occasionally replacing one of them to QA a SW tool, and was pretty slow and clumsy comparing to them.
I'd say overall their resourcefulness or "practical engineering" did some 1-5% impact on throughput.
My anecdote: a close friend's brother was working as a laborer on a pipeline dig. One day work halted for a couple of hours, during which the construction supervisor and engineer were huddled over some plans.
My friend's brother saunters past, looks over, and says "there's your problem," placing a finger on the plan. Then he walks on.
He had seen a triangle with angles not adding up to 180 degrees. He was right - that's where the problem was.
That all being said, I think this sort of tale can still be a useful tool to have a discussion around. And then that discussion can in turn produce questions that could later be backed up by research and data.
I can easily imagine a real-life scenario where some quick and dirty fix works, say, 75% of the time. (And maybe that's good enough.) But the expensive process change works 99%+ of the time and, even though there are cheap ad hoc alternatives that work in a particular scenario, you're still better off actually fixing the problem properly.
I saw it more as just a lesson about not overthinking things. Another version of the "During the space age Americans spent money developed a special compressed ink pen that could write in space, the Russians used a pencil". I think looking for a simple solution first is always good advice.
It can be also quite easy to make mistakes with these incentivisation schemes, fe in finance I've understood they can quite commonly cause problems.
I knew of one company where the Sales team were compensated based on the value of orders booked by a given date at/near the end of each month. That monthly value was unaffected by any orders cancelled from the previous month. What happened, of course, was that they would persuade people to place orders to be cancelled once the date passed. The value of the orders was always decent on the date in question, so the Sales staff always did quite well but the same orders might be placed, cancelled, and placed again multiple times over the year before they properly materialised (if ever).
Some things are only important once a dollar figure is attached to them.
https://blog.erratasec.com/2020/07/how-ceos-think.html
> Outside consultants often end up saying the same thing you do, but are trusted whereas you are not. CEOs listen to the outsiders because they have no hidden political agenda.
The story of the Good Kitchen comes to my mind: https://www.coursera.org/lecture/uva-darden-design-thinking-...
Digression: another valuable aspects of DT/HCD include: working as a natural extension to Agile/XP, deriving solutions to problems in a data-driven way, ability to find low-hanging fruit more easily due to the application of divergent and convergent modes of thinking, being cheaper in the long term, and finally—giving designers and engineers tools to shut down any pet/vanity projects coming from senior management, by cheaply proving them to be wasteful.
As I understand it, the value is based on the customer’s perception of value. And I believe this is contrasted with hourly-based pricing.
If I try to come up with an example, I might say the postal service has a value price. Mail a letter anywhere in the (continental) US, 0.55 You don’t pay 1.55 if it gets there sooner. Even if you overnight the letter, there is a flat fee. The extra cost for more difficult deliveries versus easier deliveries is a wash; the post office doesn’t charge you more or less.
Hourly consulting, like for a winning advertising campaign—what is that worth?
I don’t understand the remark suggesting value pricing is the more lucrative of pricing structures.
Value pricing is when different customers pay different prices for substantially the same service, like first class vs economy airline tickets, and app store fees.
Of course, with huge corporations, teeny improvements can be worth millions in value. So consultants working with these large corporations will usually prefer a "value-based pricing" model because if they can convince a customer that they can reap $100 million in additional savings or revenue (not unreasonable for a large company), they could easily charge, say, $40 million for it, but they would never be able to charge, say, $5000 an hour if that's what the timing worked out to be.
See also: The Russians Used a Pencil
Although that one is highly incorrect. Nasa did use pencils, Nasa didn't pay for the space pen's development, and the space pen is superior to the pencil (no flammable particles), and Russians also use the space pen and not pencils as a result.
It trivializes actual improvements and glorifies dangerous shortcuts over actual engineering. It contributes to the "haha scientists are dumb" mentality that's plaguing modern politics.
I'm not sure the message is decent and no harm is done, since it seems to be designed to weaken trust in complicated engineering processes with its underlying "look at these idiots".
(I swear it makes sense in context)
I wasn't in that department, but I got a general sense of the budgets, and $8 million sounds orders of magnitude too high for a project like this.
If you approach a third party as "a big company" looking for a "solution", you'll just get "a big solution at a bigger price"
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?
If you can read Chinese, you can check the thorough debunking of this myth right here, from someone that actually works in a soap factory: https://www.zhihu.com/question/27132006
And that was from 2014.
Pneumatic https://www.youtube.com/watch?v=7H9QyHUojFE
Somehow they've installed sensor but don't know about these. Add "$8 million", "0" cases yet guy "was tired of walking", "three weeks of production use" and only CEO bothered to check.
But reality is that engineers are the ones who know most about the subject, they know the details how everything interacts with each other.
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.
Same with the NASA pen story vs pencil.
Most projects fail because of stupid managers that don't trust their experts. Not because engineers can't see the forest through the trees.
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.
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.
Empty boxes are still making their way to the end of the process where a hack is being used to fix the outcome.
The problem of the empty boxes still exists. In fact, it could be many problems down the line.
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.
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.
I draw comparisons to the endeavours that Tesla is making to more efficient manufacturing lines.
The internal cost of wasting a packaging box (a few cents a day) is probably hugely surpassed by the value of increasing quality.
You have to consider the opportunity cost of the Root Cause Analysis and the potential fix, along with shutting down the line to implement it. Compare that to the cost of the fan fix.
Just because you could do Root Cause Analysis doesn’t mean you should go through with it. YAGNI
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.
Why do people think the engineer wouldn't suggest a fan?
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.
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.
Especially in 2020, I wonder if this is a kind of thinking that shouldn't be particularly encouraged... :S
I think the fable to teach engineers to consider ROI and simple solutions rather than to belittle the process, though I recognise it has that danger.
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.
When I read the story, my initial thought was that there would be a link pointing to Toyota or Kaizen: https://en.wikipedia.org/wiki/Kaizen 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
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.
I get that it is a thought exercise but wanted to add my 2 cents.
On two levels.
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?
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?
https://web.archive.org/web/20160531101830/http://ogun.stanf...
In the beginning was the plan.
And then came the assumptions.
And the assumptions were without form.
And the plan was without substance.
[...]In my experience, robust is simple. The best code is the code I don't write. The eraser is my best friend.
If I want to write code that has the fewest bugs, I need to write the code with the fewest lines possible.
Every line of code is what I call a "trouble node." That's a place where a bug can happen.
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.
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.
Take off and nuke the site from orbit. It's the only way to be sure.
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.
It's great.
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.
And every once in a while outside consultants aren't the bloodsuckers they are made out to be.
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.
A Tiny Mistake https://pastebin.com/gZa36S0K
But they do need battery backup.