This was interesting to read, especially the point about the marginal cost of automating additional tasks falling as the underlying infrastructure gets better. One thing I was wondering about is how the maintenance side is developing as you add more automations.
At 11% you can probably still understand each automation fairly well, but if the aim is to automate a much larger share of program operations, some of the work presumably shifts from doing the task itself to keeping a growing set of automations working as forms, Drive structures, naming conventions, staff roles etc. change. I don’t know if you are already measuring this, but something like human minutes per run or per program round, including review, exceptions and repairs, might be useful alongside the percentage of tasks automated. It could help distinguish automations that really reduce operational load from ones that mostly move that load somewhere less visible.
This was interesting to read, especially the point about the marginal cost of automating additional tasks falling as the underlying infrastructure gets better. One thing I was wondering about is how the maintenance side is developing as you add more automations.
At 11% you can probably still understand each automation fairly well, but if the aim is to automate a much larger share of program operations, some of the work presumably shifts from doing the task itself to keeping a growing set of automations working as forms, Drive structures, naming conventions, staff roles etc. change. I don’t know if you are already measuring this, but something like human minutes per run or per program round, including review, exceptions and repairs, might be useful alongside the percentage of tasks automated. It could help distinguish automations that really reduce operational load from ones that mostly move that load somewhere less visible.