Labor is not as simple as supply and demand; a huge portion of a worker's value is in their knowledge and ability to train other workers. When they strike, they

Labor is not as simple as supply and demand; a huge portion of a worker's value is in their knowledge and ability to train other workers. When they strike, they are unavailable to train replacements. Most of the people reading this are likely to be tech workers, so imagine what it would be like to try to join a company that was on strike[1]. How do you log in to your computer? Where's the bug tracker? What are the current goals? Where is the code stored? What part of this code base is actually relevant to what you're doing? What five year old architectural decision means that you can't just do this the obvious way? How do you deploy code? How do you roll back deployments? How do you find the metrics for what went wrong? Imagine trying to figure out the answers to any of these questions without senior engineers around, and in fact nobody around except other strikebreakers with the same questions. When I was at Google it was generally accepted that a new hire would take 3-6 months before the were productive, and that was with considerable help from the rest of the engineers. Tech is a particularly severe instance of this, but all labor is more complex than it appears on the surface. As any roboticist will tell you, the real world is overwhelmingly detailed. [1] Don't do this by the way, it's called being a scab, and it's against your own long-term interests. If a strike in your industry succeeds, it raises the average conditions of people in your industry.