4 ms·

>On the other hand, knowledge work typically handles uncertainty and variability of work way better. I am not sure that is true, they are very different but I

>On the other hand, knowledge work typically handles uncertainty and variability of work way better. I am not sure that is true, they are very different but I wouldn't say one handles it better. One of the factories in involved in builds to order on a short lead time. We produce 2500 machines a day, from a wide range with many configuration options. There are various sub assemblies that have to be built first. On any given day there will be shortages on various components, meaning we can't build what we want. There will be quality issues with materials meaning reworks and changes in process. There will be design up-issues to address material changes, firmware problems, or customer demands. There are 400+ people to coordinate. This is all done whilst still shipping 99.9% within the lead time. We don't know anything for certain about our demand in 10 days time. It seems much more complex and adaptable to me than when I ran a software team

flail 2y ago
I failed to explain. In the ideal case, in manufacturing, we repeat the same set of tasks to manufacture identical goods. In software development, we have the same stages (development, code review, testing, etc.), but every task going through the workflow will be different. Depending on how these tasks are defined, the effort, interdependencies, etc., might vary wildly. Both types of work, of course, will have variability related to the complexity of the process. And that variability will be correlated with the size of workflow, people and/or machines involved, etc. It's just the knowledge work adds another dimension. By the way, that's why, in knowledge work, we rather talk about accepting variability instead of controlling it (which was the focus in Lean Manufacturing). I recommend Don Reinertsen's work on that, since he worked in both contexts. While his book (Principles of Product Development Flow) is not an easy read, it's absolute gold.

flail 2y ago

I failed to explain. In the ideal case, in manufacturing, we repeat the same set of tasks to manufacture identical goods. In software development, we have the same stages (development, code review, testing, etc.), but every task going through the workflow will be different. Depending on how these tasks are defined, the effort, interdependencies, etc., might vary wildly. Both types of work, of course, will have variability related to the complexity of the process. And that variability will be correlated with the size of workflow, people and/or machines involved, etc. It's just the knowledge work adds another dimension. By the way, that's why, in knowledge work, we rather talk about accepting variability instead of controlling it (which was the focus in Lean Manufacturing). I recommend Don Reinertsen's work on that, since he worked in both contexts. While his book (Principles of Product Development Flow) is not an easy read, it's absolute gold.