6 ms·

Interesting experiment. I don't think this applies to knowledge work in the same way it does to manufacturing.

kqr 5y ago
You're right. It doesn't. But it's a matter of degree, not kind. Knowledge work has many times the variability of manufacturing (by design: if you remove variability from knowledge work, you're no longer producing anything new each time.) In other words, this applies even more severely to knowledge work. More concretely: in manufacturing you can have a process that yields 9–14 % defective or whatever. The variation is relatively small; say a CV of 10 %. In knowledge work, you'll be looking at processes that generate somewhere between 0.1 and 100 defective ideas for every really good idea. This variation is enormous: 1000 % or so.
com2kid 5y ago
Software engineer is put on a team that has more legacy code. If management judges by # of incidents, they are under performing. Heck I can tell you from experience that if you want to get promoted fast, new product teams are the way to go. You get to file lots of patents, architect huge new systems, and look like a rock star. Another example: Partner teams upstream keep pushing breaking API changes, downstream teams look bad because their services are the ones having the outage. You do your due diligence, your code is defect free, well tested. Doesn't matter, you are spending half your day putting out fires caused by someone else. Meanwhile another co-worker starts on a team where their upstream services are written to be robust against bad incoming data and have APIs that maintain back compat. Your co-worker puts out buggy poorly tested code, but the upstream services are robust enough that everything keeps chugging along. Management doesn't see any of this. They just see your team has poor performance, and this other team has great performance. Heck maybe that other team has a higher "velocity" because they can turn out features faster.
riskable 5y ago
In knowledge work the skill of the worker matters vastly more because "the process" mostly takes place in their head. You can optimize a workspace and tools for productivity and the reduction of errors but ultimately that has a minimal impact on "the process" that's taking place in the knowledge worker's mind. If the process was the problem (or perfect), adding a new (or replacing) a worker would have minimal impact but we know this is not true. You could have the best documentation, training, and absolutely stellar code yet one person can turn everything to shit quite quickly! The opposite is true as well: Bringing on a fantastic new worker can make your existing team look like a bunch of inefficient laggards. Neither of these situations can be fixed by improving processes (maybe hiring processes? Though I doubt it). It'd be like having one magic blue bean in the box that--if found--can either drastically improve or degrade the final productivity by 90%. Would the optimum process improvement then be to try to eliminate magic beans entirely? Sure seems like it (i.e. hire the lowest common denominator and don't try to optimize for the 1%). That way you reduce the likelihood of taking on the "bad 1%"--even though it reduces your chances of obtaining the perfect magic bean.

kqr 5y ago

You're right. It doesn't. But it's a matter of degree, not kind. Knowledge work has many times the variability of manufacturing (by design: if you remove variability from knowledge work, you're no longer producing anything new each time.) In other words, this applies even more severely to knowledge work. More concretely: in manufacturing you can have a process that yields 9–14 % defective or whatever. The variation is relatively small; say a CV of 10 %. In knowledge work, you'll be looking at processes that generate somewhere between 0.1 and 100 defective ideas for every really good idea. This variation is enormous: 1000 % or so.

com2kid 5y ago

Software engineer is put on a team that has more legacy code. If management judges by # of incidents, they are under performing. Heck I can tell you from experience that if you want to get promoted fast, new product teams are the way to go. You get to file lots of patents, architect huge new systems, and look like a rock star. Another example: Partner teams upstream keep pushing breaking API changes, downstream teams look bad because their services are the ones having the outage. You do your due diligence, your code is defect free, well tested. Doesn't matter, you are spending half your day putting out fires caused by someone else. Meanwhile another co-worker starts on a team where their upstream services are written to be robust against bad incoming data and have APIs that maintain back compat. Your co-worker puts out buggy poorly tested code, but the upstream services are robust enough that everything keeps chugging along. Management doesn't see any of this. They just see your team has poor performance, and this other team has great performance. Heck maybe that other team has a higher "velocity" because they can turn out features faster.

riskable 5y ago

In knowledge work the skill of the worker matters vastly more because "the process" mostly takes place in their head. You can optimize a workspace and tools for productivity and the reduction of errors but ultimately that has a minimal impact on "the process" that's taking place in the knowledge worker's mind. If the process was the problem (or perfect), adding a new (or replacing) a worker would have minimal impact but we know this is not true. You could have the best documentation, training, and absolutely stellar code yet one person can turn everything to shit quite quickly! The opposite is true as well: Bringing on a fantastic new worker can make your existing team look like a bunch of inefficient laggards. Neither of these situations can be fixed by improving processes (maybe hiring processes? Though I doubt it). It'd be like having one magic blue bean in the box that--if found--can either drastically improve or degrade the final productivity by 90%. Would the optimum process improvement then be to try to eliminate magic beans entirely? Sure seems like it (i.e. hire the lowest common denominator and don't try to optimize for the 1%). That way you reduce the likelihood of taking on the "bad 1%"--even though it reduces your chances of obtaining the perfect magic bean.