Automation eliminates value but not risk

Revision as of 14:00, 23 August 2021 by Amwelladmin (talk | contribs)
The design of organisations and products
Index: Click to expand:
Tell me more
Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

If you can automate something, you can’t monetise it. You automate, therefore, as a defensive strategy: because everyone else is automating, and if you don’t, your unit cost is higher.

This plays to a pet theory of the JC’s: the quotidian is a utility, not an asset. If you believe you have intellectual property in your boilerplate, you will waste precious resource defending a common asset. You will misprice that asset, and you may be disappointed in how many people will be prepared to pay for it.

Proprietors of contract assembly tools, take note. The value is in what you assemble, not how.

Automation keeps you in business; it isn’t a business. If every function in your organisation can be managed by an algorithm, it is game over. There is no excitement, no difficulty, no skill required, no value left. Behold the difference between noughts and crosses and chess: both are deterministic, zero-sum games — therefore unsuitable analogies for technological unemployment, but that is another story — but noughts and crosses has been solved. There are trivial, mechanical steps to force a stalemate. It is no fun. Skill in noughts and crosses has no value. It doesn’t really even count as a skill. Chess is capable of algorithmic solution, but it has not been solved.[1]

But (rigorous and competently executed) automation can remove micro-risks — risks that are intrinsic/internal to the process being automated; you can iron out the inconsistencies, foibles and errors of the meatware — but not the extrinsic risks that arise from the interaction of your new automated process with the outside world. those are emergent risks, impossible to see at the level of the process (certainly when a machine is carrying out that process), but that are a function of complexity.

See also

References

  1. Yet.