So here's the problem with many of the examples in Matt's piece: they're all about manufacturing. Taylor wasn't concerned with the software engineer; he was concerned with paper and steel manufacturing. Lean principles came from car factories. All these things are concerned with building something consistently and doing that as efficiently as possible. Innovation isn't intended to make something different or to make the product better; it's intended to make the product more consistent and to use less effort to make that product more consistent.
So now we apply this to software!
After all, software is about building the same thing over and over and simply doing it more efficiently and.... wait. That doesn't sound right at all.
This is the fundamental breakdown: as software professionals we seek innovation in the product itself, not innovation in the process used to create the product.
There is a process of manufacturing software. There is a compiler that manufactures bytecode. There is a library that calculates a hash. Those are manufacturing processes in the sense that the way we improve quality is to produce the same end result (the same bytecode, the same hash) more efficiently and more consistently. Taylor's "labor" - the workers actually doing the manufacturing - is all software for us now. We, the developers and the testers, we are Taylor's management.
We as management have responsibilities, too. It is our responsibility to seek better products for our workers (compilers) to build. It is our responsibility to seek out inefficiencies in the manufacturing process (are we using SHA-2 hashes when MD5 will do?) and to correct them. We are the ones who must conduct time and motion studies (only we generally call this optimizing the software or performance analysis).
So yes, go ahead and use a manufacturing analogy - just recognize that the humans are all on the "management" side of that analogy. (Yes, even those of us that don't have "manager" in our title.) Taylor wanted to make laborers into highly efficient drones with focused areas of expertise. In software, he has succeeded - a computer program makes a highly efficient drone with a focused area of expertise. It's time to move on; it's time to think about what we're building instead of how we're building it.