A properly optimised, trimmed, practiced manual process can be executed much more cheaply than most people think.
What's the point? Flexibility. Humans are amazing at adapting to circumstances that invalidate portions of the process. In a fast-changing world, this is critical.
Really solid automation is notoriously expensive to set up, and about as expensive to change when the circumstances fundamentally change. When, not if. (You can usually still scrape by on an old automated process that's no longer relevant, but you're leaving oodles of value on the floor.)
Why do people underestimate manual processes? They usually don't know how to optimise them (hint: it involves restructuring things you think of as outside the process in question) so they associate manual with inefficient and expensive.
When you have a time-tested optimised manual process, it might not even make economic sense to automate it. But if it does, you don't have to do it all at once. You can start by automating the dumbest, simplest, most tedious, and most stable step of the process first.
Then you can continue to introduce automated steps only for as long as it makes economic sense to do so.
----
Another common complaint about manual processes is that they invite mistakes. I have three things to say on that:
- There are ways to mistake-proof manual processes. "Poka-yoke" is a good starting word for googling.
- Automated processes make mistakes too. The difference is that an automated process makes mistakes more consistently. (Which may or may not be a good thing, depending on context.)
- Manual processes can avoid mistakes that are about to happen. In fact, I'd argue this happens at about the same rate as mistakes are made.
I’ve made arguments both ways in the past but after decades I’ve started leaning towards “80% automated”.
The idea is to get to the point that you can tear down everything and rebuild it in an hour or so. This doesn’t need 100% automation, which can be cost-prohibitive as you’ve mentioned.
The cost benefit of partial automation is that it enables rapid iteration of things like naming conventions, container hierarchies, build order, and demarcations of when things are done.
I’m working right now on an Azure template for two(!) VMs. I could deploy these by hand in an hour. Instead I’m reusing snippets from a previous project that in turn reused snippets from another.
This lets me get “for free” all of the lessons-learned from those projects: The fiddly monitoring setup. The safety locks. Purge protection. Log archival.
The customer isn’t even sure what they want! I’ll probably have to iterate and redeploy this several times before the solution congeals. With a template this takes mere minutes per iteration.
So the lesson here is that it’s not about then final scale, but about the scale of the workflow required to finalise the entire solution end-to-end.
Funny that you advocate for manual things while I have the feeling we do too much manual and advocate for the opposite.
Especially the error scenarios are bad. They cost you time no one measures.
Manual processes are also difficult to sync across multiple team members and you need tooling around it to make sure manual things happen.
My mantra / priority looks more like this:
1. Try not to do it at all
2. Make it automated
3. Do it manually with a heartbeat system
I don't want to do things manually I prefer to be able to go to a beer garden in the summer and being flexible.
And as an endpoint: automation for me is the necessary base of adding additional value with high return. Only with an automation base you can extend it by fixing more and more issues automatically. While you fix the full disk issue a 100 times, I fix it once.
I think you alluded to it wonderfully: a small team with < 10 ppl will be fine with sharing knowledge and doing parts of the pipeline manually. The overhead of creating and maintaining a stable automation for edge cases quickly exceeds the time saved.
It's a different story altogether if there are multiple teams etc that are supposed to utilize the same pipeline
My practical experience is with small teams below 10 people.
As soon as you have a well understood base system for automation (running code with Cron, monitoring and alerting) all further automationsteps are easy to add to that system.
The initial effort was always worth it.
And the big issue is, quality is very flexible.
If you need to do something every few days and you forget about it once and you get informed, did you heart someone?
Probably not but your quality suffered.
We even had a process which was broke for 3 weeks and a customer realized the issue, not us.
Automation was missing, monitoring and alerting as well.
One solution for a manual process was a Jira plugin which would create a ticket every Monday. It would describe what to do. Half automated. Purely manually would lead again to quality issues.
I have gotten good at automating simply because I cannot do any manual process 3 times in a row identically, even with a checklist. A buddy-system checklist (someone else has the checklist and reads them off to me as I complete each step) will allow me to do it error free most of the time (to the point where repeating 3 times in a row is probable), but that doesn't make sense for most things I do on a regular basis; it's not like I'm flying a passenger airliner or operating in a surgical theater.
Here's an actual example of me trying to fill up the water glass on my office desk from the water filter in the kitchen; I have not developed a check-list for this; checklists reduce my mistakes, but do not come even close to eliminating them. This happened on Monday, but similar things happen all the time.
Attempt 1: Left the water glass on my desk
Attempt 2: Filled up the water glass, took a sip, placed it down on the counter, returned to my desk
Attempt 3: Picked up the water glass, took another sip, placed it back on the counter, returned to my desk
Attempt 4: Notice that the water glass is now 1/3 empty (2/3 full?) so I top it off and now finally remember to take it back to my desk.
A properly optimised, trimmed, practiced manual process can be executed much more cheaply than most people think.
What's the point? Flexibility. Humans are amazing at adapting to circumstances that invalidate portions of the process. In a fast-changing world, this is critical.
Really solid automation is notoriously expensive to set up, and about as expensive to change when the circumstances fundamentally change. When, not if. (You can usually still scrape by on an old automated process that's no longer relevant, but you're leaving oodles of value on the floor.)
Why do people underestimate manual processes? They usually don't know how to optimise them (hint: it involves restructuring things you think of as outside the process in question) so they associate manual with inefficient and expensive.
When you have a time-tested optimised manual process, it might not even make economic sense to automate it. But if it does, you don't have to do it all at once. You can start by automating the dumbest, simplest, most tedious, and most stable step of the process first.
Then you can continue to introduce automated steps only for as long as it makes economic sense to do so.
----
Another common complaint about manual processes is that they invite mistakes. I have three things to say on that:
- There are ways to mistake-proof manual processes. "Poka-yoke" is a good starting word for googling.
- Automated processes make mistakes too. The difference is that an automated process makes mistakes more consistently. (Which may or may not be a good thing, depending on context.)
- Manual processes can avoid mistakes that are about to happen. In fact, I'd argue this happens at about the same rate as mistakes are made.