The real cost isn't just time
Repetitive tasks cost more than the time they take. The person doing the copying and pasting isn't doing any real thinking, so by the time they're done they feel drained. It usually takes a couple of hours before they're productive again.
→ An hour of menial work can quietly burn half a day.
It's not dramatic. It just adds up.
What this looks like in practice
I've seen this play out clearly with client reporting. The manual version looked something like this: pull data out of a system, choose the right dates, paste it into a spreadsheet, update the dates in the sheet, check everything looks right, PDF it, send it through an approval process. Then do it again next week.
We automated that in stages. Not all at once. Over time, we built a workflow that handled the data pull, generated the report, and produced the PDF.
The person who used to run through all those steps didn't lose their job. They got to focus on the actual work. Reviewing the numbers. Checking if they matched what the client was expecting. Comparing against previous weeks. Spotting issues before they became problems.
The quality of their output went up because they were doing the thinking, not the data entry.
People start looking for more
One of the best things that came out of that was unexpected. The person who went through the process of learning the new system, working through the bugs, and seeing the result, they started looking for other things that could be automated.
They saw how powerful it made their role. How much more time they had to help the team. So they started feeding suggestions back in.
In most organisations, it's hard to see automation opportunities from the top. Getting suggestions from the people doing the work is genuinely valuable. And that only happens when someone has experienced the benefit firsthand.
You don't need to automate everything at once
I think one of the biggest misconceptions about automation is that it needs to be all-encompassing. That it has to handle every step, end to end, right from the start.
I think the best way is to start small. You can tackle small pieces. Automate the middle of a process and keep manual steps on either side. That's fine. You're still saving time and learning.
Part of the value of automating is that you have to document the process first. And when you do that, people often realise there are redundant steps. Things that made sense once but don't anymore. The process itself improves just by looking at it closely.
Starting small also helps with adoption. People aren't overwhelmed by a massive change. They see a small win, they trust it, and they're open to the next one.
Run it alongside until the deltas disappear
When a new automation runs for the first couple of cycles, I keep the manual process running alongside it. Two outputs, same inputs.
Then you compare. Almost always, there are deltas. Small differences between the automated output and the manual one. You fix the automation, run it again, compare again. Keep going until they match.
Once there are no deltas, you can trust it. Turn off the manual process and move on.
→ Start small, check it works, then build on top.
This approach removes the fear. If something doesn't work, you roll it back. No damage done. But more often than not, it works, and you've just freed up a chunk of someone's week.
In small teams, this is how you do more
In early-stage companies, people do a lot. Things move fast, and often the best approach is just to make things happen, even if that means someone is doing tasks well outside their job description. That's just part of it.
But you hit a point where you need to figure out how to do more without adding headcount. One way is to sweep around, find the low-hanging fruit, and automate it. Free up people to work on the things that actually move the needle.
It doesn't need to be complicated. It doesn't need to be perfect. It just needs to start.