8 ms·

“Blue Light” creating capacity for nothing (2007)

151 points by Symmetry 4y ago

hiAndrewQuinn 4y ago
This brought a smile to my face. Solid industrial engineering fundamentals brought to the table.
ChrisMarshallNY 4y ago
This reminds me of the fight I had to hire an Infrastructure Engineer (they call them DevOps, these days). It was like pulling teeth, but, in fairly short order, the chap I hired became the most popular member of the team.
- hinkley 4y ago
  I had to beg for a simple server to separate staging and customers demos once, that were jamming up half a day a week. The official request I made said the server would pay for itself in eight weeks. I think the boss finally understood why I was being so grumpy about it at that point. Or maybe you could just trust the people you claim to trust.
  - DigiDigiorno 4y ago
    Persuasively communicating cost-savings in a budget increase request? I'm so sorry to inform you, but you have management written on you. (But in all seriousness, communication is an important management skill, it's good you explained it so directly, but ideally a manager would communicate back-and-forth without needing to be spoonfed all at once.)
- slowhand09 4y ago
  My current environment... we develop on a production environment. And our toolchain... put it this way. We went from no documented procedures, to several. And the several... have no date, no version, no author, no revision control... Friday is my last day. I am so happy.
  - ketzo 4y ago
    Congrats. Hopefully a better situation for you in the new year.
jancsika 4y ago
Where's the part where the welders start doing needless welding to satisfy the helper's target? Or is the point that a good consultant knows to leave before that happens?
- danuker 4y ago
  Many humans avoid malicious compliance, because they want to keep their job.
  - pxx 4y ago
    This isn't malicious compliance. This is just what organically happens -- see Goodhart's law.
- count 4y ago
  More likely the consultant helped them learn that now that they're so efficient, they can downsize the welding team.
  - mft_ 4y ago
    That was my first thought: rather than three or more welders welding ~10% of the time, they needed a team of helpers setting things up, and a single welder moving quickly from job to job...
    - LorenPechtel 4y ago
      Yup. A welder's helper is a lot cheaper than a welder, not to mention all the gear time that produces no value for anyone. You want to set things up to the high skill workers are as much as possible able to spend their time on the high skill task.
      - deleted 4y ago
        [deleted]
  - D-Coder 4y ago
twobitshifter 4y ago
It's incredible that one person was able to handle all the work that took up 90% of the welders time. Lots of time must have been spent getting in and out of gear. I’d expect that one guy to end up the bottleneck and the welders to be waiting for him to bring them parts, but it says he even as time to peel the plastic! I imagine the blue light applied to programming would be a crude tool. I want to hear keys clacking? See issues closed, pull requests? But we can ask what are the things developers are doing which interrupt them from coding and could there be a benefit to someone employed to handle those distractions?
- nikanj 4y ago
  Not all of it, just enough of it to move the bottleneck somewhere else. A factory is always bottlenecked by something, sales if nothing else
  - Dylan16807 4y ago
    > A factory is always bottlenecked by something, sales if nothing else I don't feel like that's a very good conclusion. If a good chunk of your processes have roughly the same capacity, and they're all running at that capacity, you don't have anything I would call a bottleneck.
- crdrost 4y ago
  So the derivation of Eli Goldratt’s ideas for programming is necessarily different because we are doing artisanal work rather than manufacturing. But yes taken naively it is a measure of Git commits merged into the main branch after running precommit checks and tests and code review and whatever else, and ideally shipping to prod directly. And this is where you want to enable the ability to ship broken code without breaking prod (feature toggles are super handy for this)... This speeds the code review time for example, “oh all that stuff is behind a feature toggle, we won't ship it until it's ready.” A better derivation of Eli's ideas ultimately causes your entire team to work on one feature before deploying another before deploying another. Sprint planning is “what do we want to take on next, how are we separating it across the team, and how will we pass the baton?” The relay-race baton-pass becomes the crucial concept, whoever has the baton is expected to be working 100% on this thing and only this thing, anyone who does not have the baton is either meant to be preparing to receive the baton, or else they are free to work on whatever refactoring or bug-fixing or side-feature or user support or whatever needs to be done. They are the equivalent of this non-welder helping out. And this is also why it's important for the baton to pass from person to person, because it can be exhausting to hold the baton for too long: what do you call someone who sprints for an hour—a jogger. This also unlocks the true value of daily standup, which is the person with the baton telling everybody else what they need in order to be successful, and the person who is about to receive the baton to be aware about the timescale at which they have to drop everything else they are doing and work 100% on the next part of the sprint, and the rest of the team checking in on the personal health of the person who has the baton, making sure that they are not overworking themselves to death. Are you okay? What's at stake is covered in Goldratt’s book Critical Chain, that in a “project context” there is a complex network of dependencies, including hidden ones that come from the raw logical fact that one person can't be working on two different parts at the same time, and the constraint, the thing that actually needs to be tracked and preserved is temporal safety buffer. The default state for a project is that if a step is completed late, that delay has passed on to the next step, but if a step is completed early, that advantage is not communicated to the next step because the person working on the next step isn't ready to drop everything and start working on the project yet. I actually use these principles to manage the cooking of Thanksgiving meals for our family. My wife was very upset the first time I did it because there was a lot of drawing graphs and stuff, a bunch of diagrams, I had never done it before. But now she wants me to do it every year because it is absolutely intoxicating for her to ask me “what should I be doing right now?” and for me to reply “ nothing, you should rest, but in about 30 minutes you are going to have to drop whatever you are doing and put together everything for the corn casserole.” That this is how it works should not shock us, not those of us working in web development. Everybody here who works in web development should understand that you overprovision your servers and 90% of the time. They don't do anything. That's not for no reason, it's not because we're wasteful, it because it gives us a much better latency on our incoming requests. Making it clear what the Sprint goal is, and whose shoulders that goal is currently falling upon, is part of making a very low latency system which can respond to whatever fires occur on a day-to-day basis while still getting these longer term projects done ahead of schedule. 80% of the team should be resting or dealing with the latest crisis while one person is legit sprinting on the Sprint goal, and progress on a feature should never have to stall just because the sprinter's significant other is suddenly in the hospital: the feature was owned by the team and the whole team needs to be able to work on it, with everybody checking their work in daily and everybody willing to help out to make the group's deadlines. I've kind of given the sales pitch for it so let me give one major limitation, a lot of our current methodology is structured in order to identify underperforming people by concrete metrics like how many features they complete, how many story points are those features, and the above methodology kind of creates a space where people can hide: they never take the baton so they never are really in the hot seat, but the whole group takes credit for the success of their individuals. Random assignment and pair programming are one mechanism to rectify the concern and then rectify an obvious concern with that solution (“what if we give a frontend task to a backend programmer?”—answer is, they should do the frontend task, but as the person holding the baton they are running the show and thus entitled to say “I want help, can someone who knows more about frontend code pair with me so that I can just ask “how do I do that in the browser?”).
nerdponx 4y ago
This is a great story because it's not just about welding. I have seen many data science teams working under similar conditions: spending 90% of their time doing miscellaneous bullshit and 10% doing data science at best. Recall that data science itself is 80-90% data cleaning and basic exploratory analysis, so that means no more than 1-4% of their overall time is spent doing the work that they're actually trained to do, and that you are actually paying them to do. They look productive because they are always busy. But really they need helpers (data engineers and dev/data ops people) to do all the random software work, so the data scientists can actually build models, meet with senior leadership, and all the other actually value-generating work that justifies their high price tag, and moreover keeps them happy with the work so they are more likely to actually stay at your company.
- FredPret 4y ago
  That can still be ridiculously profitable if the output is good enough and general enough. The human mind has insane leverage, especially in the modern world. For example, Newton / Leibnitz's invention of calculus created much more than enough value to pay for every single mathematician ever since, and that wasn't even all they did.
larrydag 4y ago
The article's story anecdote of "blue light" is about finding the true value in a process. Blue light means the welder is actually creating value in the product. Anything else in the process does not help build value to the product. It is all non-value added activities. The non-value added activities might be necessary such as setup, delivery, reposition or what not but it doesn't drive value. By maximizing the blue light welding operation it maximizes value being created. Maximizing value will minimize extraneous activities that don't help make a finished product and should decrease cycle time for the value-added activity. This all can be learned from The Goal by Goldgratt which is a story about theory of constraints. https://www.tocinstitute.org/the-goal-summary.html https://www.tocinstitute.org/the-goal-summary.html
- sitkack 4y ago
  Those are things are also necessary, they just don't require a welder to do them. All the talk of "value" will pollute your thinking and encourage you to be a productivity and value bigot.
  - xyzelement 4y ago
    Can you explain what you mean by "productivity and value bigot?" In my mind productivity and value generation are major virtues that benefit the doer and society, big "bigot" has a negative connotation and I don't understand how it goes together.
    - thinkmcfly 4y ago
      Like a VC for instance. They are blood sucking leeches upon our society
      - xyzelement 4y ago
        Like I try not to get hung up on language but "value/productivity" and "leeches" are essentially antonyms.
phyzome 4y ago
There appears to be a typo in the original post title -- perhaps s/for/from/?
- zootboy 4y ago
  I think it's meant to be interpreted as "hiring additional welders would be creating capacity for nothing" because the number of welders was not the bottleneck.
  - uhb 4y ago
    I think "for nothing" means "for free", "at no cost", creating capacity just by moving someone to be the helper.
bawolff 4y ago
It seems like a story that works well in a factory setting - where its not particularly creative work and you do the same thing over and over again. The basic gist of the story is an assembly line improves efficiency in a factory. Well no duh. The translation of that lesson to a programming environment seems like it would be really fraught, encouraging people to do stupid things like write more unnessary lines of code.
bmacho 4y ago
I like the concept of blue light, seems so simple yet powerful. I am looking forward to use it!
anenefan 4y ago
I know most people are gushing with positives ... but to me this reads like the epitome of a clueless consultant who got lucky because the 30 plus years manager missed the basics ... unless the era of the tale was early 60s or something or some middle of nowhere fabrication that sprang up with little idea of how other similar places work ... um great story but what really was this based on. In the industry it's fairly well known (ok that's a weasel phrase even though I'm sure I'd be right if I used 99.999999%) in regard to the overall benefits of TAs (Trade Assistants.) Typically a TA around welders, they're grinding and readying the surfaces to be welded and helping position the work. Though there's value in setting up, not just making blue light, welders generally receive a much higher pay packet, since ultimately it's their good welding skills that ensures quality welds leave the floor and a long life of the component. What's obvious is what would have happened if the blue light was 50 or 60% of the time and the welding machines were at capacity. (Higher capacity welding machines are generally a lot more expensive.) To the clueless a lot more can be squeezed out ... and that's what the hero would have aimed to do, in fact no doubt another 25%. The experienced plant manager would have then kindly thanked them at that point perhaps realising the consultant was out of their depth.
- nerdponx 4y ago
  To be fair, the situation in the story truly does happen in a variety of jobs and businesses. What you are highlighting is the countervailing lesson, kind of a specialization of Chesterton's fence: if highly experienced people are doing a process in what seems to be an inefficient manner, consider that it might actually be the most efficient manner, given constraints that you do not fully understand or are not aware of.
  - anenefan 4y ago
    I'd agree this sort of thing does happen in regular life where the agent of change is someone who's had wide ranging experience and maybe a lateral thinker and adopting other work processes that are proven in existing industries. (However the story above is just that, the chance that happened as stated are slim ... and only for reasons along the lines I've mentioned being a bit isolated or operating in a vacuum.) Sometimes, not that I can think of much software or hardware related situations, the fence is just an idea, years of experience have lead to a situation where they've established a comfort zone of sorts, and hesitant to change the way things are done ... often because they don't totally understand complicated processes they might be using ... or because things done differently might be more open (but rare) to a specific problem or being prone to a failure which from their previous experience, might have chewed up half a day to a day if not more to sort it out ... when the fix by someone who is competent (having been shown the correct way from the start) is able to resolve the issue quickly, barely 20 minutes of time and patience and it's in half an hour it's like nothing happened. As for "do not fully understand" - yes that is an excellent way to describe total inadequacy.
yqsk 4y ago
Is ChatGPT the helper or the welder?
- Scalene2 4y ago
  Yes. (it depends on the situation)
giorgosts 4y ago
Bullshit story the consultant made up to bolster his point (93% efficiency claim from a foreman wtf). Of course finding some help moving parts around for the welders would be the first thing the foreman would think of, because thats what foremans do all the time in factories. Maybe the welders chose to work this way (i.e. inefficiently) because continuous welding produces fatigue which risks H&S and lowers the quality of the product. So if the story was real, the solution would be extra personnel so the welding is done continuously, by rotating people between welding, moving parts and other jobs.
- nerdponx 4y ago
  That literally is the solution they landed on: they hired helpers, i.e. extra personnel. The critical difference is that they did not need to hire more welders, buy more welding equipment, set up more welding stations. I don't care if the story came right out of Aesop's fables, because it's a good story and it makes a good point.
  - anenefan 4y ago
    The problem is it's not really a good story to tell, because this leads people, who might not know any better, to later in life recount to some welder friend(s) they happen to know, about how the article's creator was the guy who worked out welders needed TAs ... or one fabrication welding business needed TAs. It's better not to make things up, or use really really incredulous examples, that may lead people to unwittingly embarrass themselves. It's almost like a story where the genius works out the boss needs a secretary. When it comes to inventing stuff, important points are often overlooked. Imagine if the same sort of story recounted a company with a 9 to 5 office where 100 people worked solely at their desktop computer station back in the days of W98 or XP doing whatever it was they did. The guy observes when people arrive for work they're not productive because the first five minutes their system was booting and virus checking. There's over 8 hours of lost production so it's worthwhile to hire an additional low paid casual worker for minimum award, with the minimum required hours for casual (here it's iirc it's been around four hours a day,) to arrive a couple hours beforehand to ensure all systems are running so workers can start working immediately when they walk through the door. Clearly that sounds right, but most here would know, in practice, for many workers, output would not increase substantially. The nuance is in the finer details.
MisterMower 4y ago
> I then watched the first welder begin to peel the protective plastic coating off the bumper in the places he had to weld. It took a good bit of time picking with his fingernails to get it done. Seems like this whole step could be eliminated if they only protected the areas that weren’t going to be welded. You don’t care about cosmetic damage to surfaces you’re going to weld on. Just be smarter about where you put the plastic. There might be good reasons why they did that though. My experience in factory settings is that there is always a reason. It’s just sometimes a really dumb one.
Exuma 4y ago
Too bad all businesses aren't this easy to fix ;x
omeysalvi 4y ago
Even if the story is true, taking this attitude to the extremes is what leads companies like Amazon to time warehouse workers down to the last second and set increasingly aggressive targets every year. It is easy to deal with people when they are just a bunch of numbers in a excel sheet. No wonder they are going to run out of workers to hire in the US by 2024, as their own memo said.
- Nifty3929 4y ago
  No need to ask people to work more or harder - just show/allow them to work more efficiently and they can generate more value with less/same overall effort. Better to have a more relaxed and achievable target of 100 units with a more efficient way of working than to have a more difficult target of 50 with a less efficient one. Right?
Nifty3929 4y ago
Regarding so many other comments from people who know a lot about welding and/or factories who think the story is made up. Probably you're right, but THE STORY IS NOT ABOUT WELDING! It is about having misconceptions about efficiency and productivity, and that people being busy does not mean they can't be more productive.
deleted 4y ago
[deleted]
vivegi 4y ago
Great article. It is almost always the case that we live under "assumed constraints". Most of the time when we question the underlying assumptions we are able to break the constraint or relax it to obtain a better solution. The Goal, by Eliyahu M. Goldratt is highly recommended for understanding Theory of Constraints told from the view of a fictional plant manager.
- hn_go_brrrrr 4y ago
  I read that, having received a similar recommendation, but after I finished it I had no idea how to translate that into my own job (I do not manage a factory).
  - sokoloff 4y ago
    What’s the thing that adds value to your customer? What is the part they’re actually paying for? How much of your time is spent on that thing/those things? How much is spent on other things and how can you reduce that, especially for any resources that are your constrained (rate-limiting) resources?
  - rm445 4y ago
    Yeah, that's what it's for. But the ideas generalise to general project-management and processing of 'stuff'. A lot of it makes sense in multi-person hardware development projects.
  - drivers99 4y ago
    The Phoenix Project is based on The Goal but applied to the software industry.
  - nerdponx 4y ago
    If your specialist employees are spending their time doing non-specialist work, then perhaps you have not set them up to work efficiently.
  - vivegi 4y ago
    It doesn't have to be a factory producing physical goods. Anytime we have a multi-stage process with different team members responsible for various stages with interdependencies, you will find constraints abound. ToC tells you that while there will be multiple constraints, your biggest bang for the buck comes from identifying the limiting constraint first and finding workarounds to break / relax that. Focusing on the non-limiting constraint would not give you the best benefit. This is such a general concept that we can apply it to so many processes whether it is sales, customer service, bug triaging/resolution, logistics etc., Any place we observe a queue (whether visible or hidden), I can guarantee that there is a lurking constraint somewhere.

151 points by Symmetry 4y ago

This brought a smile to my face. Solid industrial engineering fundamentals brought to the table.

This reminds me of the fight I had to hire an Infrastructure Engineer (they call them DevOps, these days). It was like pulling teeth, but, in fairly short order, the chap I hired became the most popular member of the team.

hinkley 4y ago
I had to beg for a simple server to separate staging and customers demos once, that were jamming up half a day a week. The official request I made said the server would pay for itself in eight weeks. I think the boss finally understood why I was being so grumpy about it at that point. Or maybe you could just trust the people you claim to trust.
- DigiDigiorno 4y ago
  Persuasively communicating cost-savings in a budget increase request? I'm so sorry to inform you, but you have management written on you. (But in all seriousness, communication is an important management skill, it's good you explained it so directly, but ideally a manager would communicate back-and-forth without needing to be spoonfed all at once.)
slowhand09 4y ago
My current environment... we develop on a production environment. And our toolchain... put it this way. We went from no documented procedures, to several. And the several... have no date, no version, no author, no revision control... Friday is my last day. I am so happy.
- ketzo 4y ago
  Congrats. Hopefully a better situation for you in the new year.

jancsika 4y ago

Where's the part where the welders start doing needless welding to satisfy the helper's target? Or is the point that a good consultant knows to leave before that happens?

danuker 4y ago
Many humans avoid malicious compliance, because they want to keep their job.
- pxx 4y ago
  This isn't malicious compliance. This is just what organically happens -- see Goodhart's law.
count 4y ago
More likely the consultant helped them learn that now that they're so efficient, they can downsize the welding team.
- mft_ 4y ago
  That was my first thought: rather than three or more welders welding ~10% of the time, they needed a team of helpers setting things up, and a single welder moving quickly from job to job...
  - LorenPechtel 4y ago
    Yup. A welder's helper is a lot cheaper than a welder, not to mention all the gear time that produces no value for anyone. You want to set things up to the high skill workers are as much as possible able to spend their time on the high skill task.
    - deleted 4y ago
      [deleted]
- D-Coder 4y ago

twobitshifter 4y ago

It's incredible that one person was able to handle all the work that took up 90% of the welders time. Lots of time must have been spent getting in and out of gear. I’d expect that one guy to end up the bottleneck and the welders to be waiting for him to bring them parts, but it says he even as time to peel the plastic! I imagine the blue light applied to programming would be a crude tool. I want to hear keys clacking? See issues closed, pull requests? But we can ask what are the things developers are doing which interrupt them from coding and could there be a benefit to someone employed to handle those distractions?

nikanj 4y ago
Not all of it, just enough of it to move the bottleneck somewhere else. A factory is always bottlenecked by something, sales if nothing else
- Dylan16807 4y ago
  > A factory is always bottlenecked by something, sales if nothing else I don't feel like that's a very good conclusion. If a good chunk of your processes have roughly the same capacity, and they're all running at that capacity, you don't have anything I would call a bottleneck.
crdrost 4y ago
So the derivation of Eli Goldratt’s ideas for programming is necessarily different because we are doing artisanal work rather than manufacturing. But yes taken naively it is a measure of Git commits merged into the main branch after running precommit checks and tests and code review and whatever else, and ideally shipping to prod directly. And this is where you want to enable the ability to ship broken code without breaking prod (feature toggles are super handy for this)... This speeds the code review time for example, “oh all that stuff is behind a feature toggle, we won't ship it until it's ready.” A better derivation of Eli's ideas ultimately causes your entire team to work on one feature before deploying another before deploying another. Sprint planning is “what do we want to take on next, how are we separating it across the team, and how will we pass the baton?” The relay-race baton-pass becomes the crucial concept, whoever has the baton is expected to be working 100% on this thing and only this thing, anyone who does not have the baton is either meant to be preparing to receive the baton, or else they are free to work on whatever refactoring or bug-fixing or side-feature or user support or whatever needs to be done. They are the equivalent of this non-welder helping out. And this is also why it's important for the baton to pass from person to person, because it can be exhausting to hold the baton for too long: what do you call someone who sprints for an hour—a jogger. This also unlocks the true value of daily standup, which is the person with the baton telling everybody else what they need in order to be successful, and the person who is about to receive the baton to be aware about the timescale at which they have to drop everything else they are doing and work 100% on the next part of the sprint, and the rest of the team checking in on the personal health of the person who has the baton, making sure that they are not overworking themselves to death. Are you okay? What's at stake is covered in Goldratt’s book Critical Chain, that in a “project context” there is a complex network of dependencies, including hidden ones that come from the raw logical fact that one person can't be working on two different parts at the same time, and the constraint, the thing that actually needs to be tracked and preserved is temporal safety buffer. The default state for a project is that if a step is completed late, that delay has passed on to the next step, but if a step is completed early, that advantage is not communicated to the next step because the person working on the next step isn't ready to drop everything and start working on the project yet. I actually use these principles to manage the cooking of Thanksgiving meals for our family. My wife was very upset the first time I did it because there was a lot of drawing graphs and stuff, a bunch of diagrams, I had never done it before. But now she wants me to do it every year because it is absolutely intoxicating for her to ask me “what should I be doing right now?” and for me to reply “ nothing, you should rest, but in about 30 minutes you are going to have to drop whatever you are doing and put together everything for the corn casserole.” That this is how it works should not shock us, not those of us working in web development. Everybody here who works in web development should understand that you overprovision your servers and 90% of the time. They don't do anything. That's not for no reason, it's not because we're wasteful, it because it gives us a much better latency on our incoming requests. Making it clear what the Sprint goal is, and whose shoulders that goal is currently falling upon, is part of making a very low latency system which can respond to whatever fires occur on a day-to-day basis while still getting these longer term projects done ahead of schedule. 80% of the team should be resting or dealing with the latest crisis while one person is legit sprinting on the Sprint goal, and progress on a feature should never have to stall just because the sprinter's significant other is suddenly in the hospital: the feature was owned by the team and the whole team needs to be able to work on it, with everybody checking their work in daily and everybody willing to help out to make the group's deadlines. I've kind of given the sales pitch for it so let me give one major limitation, a lot of our current methodology is structured in order to identify underperforming people by concrete metrics like how many features they complete, how many story points are those features, and the above methodology kind of creates a space where people can hide: they never take the baton so they never are really in the hot seat, but the whole group takes credit for the success of their individuals. Random assignment and pair programming are one mechanism to rectify the concern and then rectify an obvious concern with that solution (“what if we give a frontend task to a backend programmer?”—answer is, they should do the frontend task, but as the person holding the baton they are running the show and thus entitled to say “I want help, can someone who knows more about frontend code pair with me so that I can just ask “how do I do that in the browser?”).

nerdponx 4y ago

This is a great story because it's not just about welding. I have seen many data science teams working under similar conditions: spending 90% of their time doing miscellaneous bullshit and 10% doing data science at best. Recall that data science itself is 80-90% data cleaning and basic exploratory analysis, so that means no more than 1-4% of their overall time is spent doing the work that they're actually trained to do, and that you are actually paying them to do. They look productive because they are always busy. But really they need helpers (data engineers and dev/data ops people) to do all the random software work, so the data scientists can actually build models, meet with senior leadership, and all the other actually value-generating work that justifies their high price tag, and moreover keeps them happy with the work so they are more likely to actually stay at your company.

FredPret 4y ago
That can still be ridiculously profitable if the output is good enough and general enough. The human mind has insane leverage, especially in the modern world. For example, Newton / Leibnitz's invention of calculus created much more than enough value to pay for every single mathematician ever since, and that wasn't even all they did.

larrydag 4y ago

The article's story anecdote of "blue light" is about finding the true value in a process. Blue light means the welder is actually creating value in the product. Anything else in the process does not help build value to the product. It is all non-value added activities. The non-value added activities might be necessary such as setup, delivery, reposition or what not but it doesn't drive value. By maximizing the blue light welding operation it maximizes value being created. Maximizing value will minimize extraneous activities that don't help make a finished product and should decrease cycle time for the value-added activity. This all can be learned from The Goal by Goldgratt which is a story about theory of constraints. https://www.tocinstitute.org/the-goal-summary.html https://www.tocinstitute.org/the-goal-summary.html

sitkack 4y ago
Those are things are also necessary, they just don't require a welder to do them. All the talk of "value" will pollute your thinking and encourage you to be a productivity and value bigot.
- xyzelement 4y ago
  Can you explain what you mean by "productivity and value bigot?" In my mind productivity and value generation are major virtues that benefit the doer and society, big "bigot" has a negative connotation and I don't understand how it goes together.
  - thinkmcfly 4y ago
    Like a VC for instance. They are blood sucking leeches upon our society
    - xyzelement 4y ago
      Like I try not to get hung up on language but "value/productivity" and "leeches" are essentially antonyms.

phyzome 4y ago

There appears to be a typo in the original post title -- perhaps s/for/from/?

zootboy 4y ago
I think it's meant to be interpreted as "hiring additional welders would be creating capacity for nothing" because the number of welders was not the bottleneck.
- uhb 4y ago
  I think "for nothing" means "for free", "at no cost", creating capacity just by moving someone to be the helper.

bawolff 4y ago

It seems like a story that works well in a factory setting - where its not particularly creative work and you do the same thing over and over again. The basic gist of the story is an assembly line improves efficiency in a factory. Well no duh. The translation of that lesson to a programming environment seems like it would be really fraught, encouraging people to do stupid things like write more unnessary lines of code.

bmacho 4y ago

I like the concept of blue light, seems so simple yet powerful. I am looking forward to use it!

anenefan 4y ago

I know most people are gushing with positives ... but to me this reads like the epitome of a clueless consultant who got lucky because the 30 plus years manager missed the basics ... unless the era of the tale was early 60s or something or some middle of nowhere fabrication that sprang up with little idea of how other similar places work ... um great story but what really was this based on. In the industry it's fairly well known (ok that's a weasel phrase even though I'm sure I'd be right if I used 99.999999%) in regard to the overall benefits of TAs (Trade Assistants.) Typically a TA around welders, they're grinding and readying the surfaces to be welded and helping position the work. Though there's value in setting up, not just making blue light, welders generally receive a much higher pay packet, since ultimately it's their good welding skills that ensures quality welds leave the floor and a long life of the component. What's obvious is what would have happened if the blue light was 50 or 60% of the time and the welding machines were at capacity. (Higher capacity welding machines are generally a lot more expensive.) To the clueless a lot more can be squeezed out ... and that's what the hero would have aimed to do, in fact no doubt another 25%. The experienced plant manager would have then kindly thanked them at that point perhaps realising the consultant was out of their depth.

nerdponx 4y ago
To be fair, the situation in the story truly does happen in a variety of jobs and businesses. What you are highlighting is the countervailing lesson, kind of a specialization of Chesterton's fence: if highly experienced people are doing a process in what seems to be an inefficient manner, consider that it might actually be the most efficient manner, given constraints that you do not fully understand or are not aware of.
- anenefan 4y ago
  I'd agree this sort of thing does happen in regular life where the agent of change is someone who's had wide ranging experience and maybe a lateral thinker and adopting other work processes that are proven in existing industries. (However the story above is just that, the chance that happened as stated are slim ... and only for reasons along the lines I've mentioned being a bit isolated or operating in a vacuum.) Sometimes, not that I can think of much software or hardware related situations, the fence is just an idea, years of experience have lead to a situation where they've established a comfort zone of sorts, and hesitant to change the way things are done ... often because they don't totally understand complicated processes they might be using ... or because things done differently might be more open (but rare) to a specific problem or being prone to a failure which from their previous experience, might have chewed up half a day to a day if not more to sort it out ... when the fix by someone who is competent (having been shown the correct way from the start) is able to resolve the issue quickly, barely 20 minutes of time and patience and it's in half an hour it's like nothing happened. As for "do not fully understand" - yes that is an excellent way to describe total inadequacy.

yqsk 4y ago

Is ChatGPT the helper or the welder?

Scalene2 4y ago
Yes. (it depends on the situation)

giorgosts 4y ago

Bullshit story the consultant made up to bolster his point (93% efficiency claim from a foreman wtf). Of course finding some help moving parts around for the welders would be the first thing the foreman would think of, because thats what foremans do all the time in factories. Maybe the welders chose to work this way (i.e. inefficiently) because continuous welding produces fatigue which risks H&S and lowers the quality of the product. So if the story was real, the solution would be extra personnel so the welding is done continuously, by rotating people between welding, moving parts and other jobs.

nerdponx 4y ago
That literally is the solution they landed on: they hired helpers, i.e. extra personnel. The critical difference is that they did not need to hire more welders, buy more welding equipment, set up more welding stations. I don't care if the story came right out of Aesop's fables, because it's a good story and it makes a good point.
- anenefan 4y ago
  The problem is it's not really a good story to tell, because this leads people, who might not know any better, to later in life recount to some welder friend(s) they happen to know, about how the article's creator was the guy who worked out welders needed TAs ... or one fabrication welding business needed TAs. It's better not to make things up, or use really really incredulous examples, that may lead people to unwittingly embarrass themselves. It's almost like a story where the genius works out the boss needs a secretary. When it comes to inventing stuff, important points are often overlooked. Imagine if the same sort of story recounted a company with a 9 to 5 office where 100 people worked solely at their desktop computer station back in the days of W98 or XP doing whatever it was they did. The guy observes when people arrive for work they're not productive because the first five minutes their system was booting and virus checking. There's over 8 hours of lost production so it's worthwhile to hire an additional low paid casual worker for minimum award, with the minimum required hours for casual (here it's iirc it's been around four hours a day,) to arrive a couple hours beforehand to ensure all systems are running so workers can start working immediately when they walk through the door. Clearly that sounds right, but most here would know, in practice, for many workers, output would not increase substantially. The nuance is in the finer details.

MisterMower 4y ago

> I then watched the first welder begin to peel the protective plastic coating off the bumper in the places he had to weld. It took a good bit of time picking with his fingernails to get it done. Seems like this whole step could be eliminated if they only protected the areas that weren’t going to be welded. You don’t care about cosmetic damage to surfaces you’re going to weld on. Just be smarter about where you put the plastic. There might be good reasons why they did that though. My experience in factory settings is that there is always a reason. It’s just sometimes a really dumb one.

Exuma 4y ago

Too bad all businesses aren't this easy to fix ;x

omeysalvi 4y ago

Even if the story is true, taking this attitude to the extremes is what leads companies like Amazon to time warehouse workers down to the last second and set increasingly aggressive targets every year. It is easy to deal with people when they are just a bunch of numbers in a excel sheet. No wonder they are going to run out of workers to hire in the US by 2024, as their own memo said.

Nifty3929 4y ago
No need to ask people to work more or harder - just show/allow them to work more efficiently and they can generate more value with less/same overall effort. Better to have a more relaxed and achievable target of 100 units with a more efficient way of working than to have a more difficult target of 50 with a less efficient one. Right?

Nifty3929 4y ago

Regarding so many other comments from people who know a lot about welding and/or factories who think the story is made up. Probably you're right, but THE STORY IS NOT ABOUT WELDING! It is about having misconceptions about efficiency and productivity, and that people being busy does not mean they can't be more productive.

deleted 4y ago

[deleted]

vivegi 4y ago

Great article. It is almost always the case that we live under "assumed constraints". Most of the time when we question the underlying assumptions we are able to break the constraint or relax it to obtain a better solution. The Goal, by Eliyahu M. Goldratt is highly recommended for understanding Theory of Constraints told from the view of a fictional plant manager.

hn_go_brrrrr 4y ago
I read that, having received a similar recommendation, but after I finished it I had no idea how to translate that into my own job (I do not manage a factory).
- sokoloff 4y ago
  What’s the thing that adds value to your customer? What is the part they’re actually paying for? How much of your time is spent on that thing/those things? How much is spent on other things and how can you reduce that, especially for any resources that are your constrained (rate-limiting) resources?
- rm445 4y ago
  Yeah, that's what it's for. But the ideas generalise to general project-management and processing of 'stuff'. A lot of it makes sense in multi-person hardware development projects.
- drivers99 4y ago
  The Phoenix Project is based on The Goal but applied to the software industry.
- nerdponx 4y ago
  If your specialist employees are spending their time doing non-specialist work, then perhaps you have not set them up to work efficiently.
- vivegi 4y ago
  It doesn't have to be a factory producing physical goods. Anytime we have a multi-stage process with different team members responsible for various stages with interdependencies, you will find constraints abound. ToC tells you that while there will be multiple constraints, your biggest bang for the buck comes from identifying the limiting constraint first and finding workarounds to break / relax that. Focusing on the non-limiting constraint would not give you the best benefit. This is such a general concept that we can apply it to so many processes whether it is sales, customer service, bug triaging/resolution, logistics etc., Any place we observe a queue (whether visible or hidden), I can guarantee that there is a lurking constraint somewhere.