When I was a junior BA, I had to analyze an Excel file with a few thousand rows. Five minutes of filtering and pivoting would have done it. I wrote a script instead.
Fifty minutes later, after Googling functions and debugging stupid errors, I was back in Excel anyway. The script didn’t buy insight. It bought activity.
Later I made the same mistake in product. Building a food-and-drinks ordering platform, we shipped auto-confirmation from day one. “We need it for scale.” Reality: restaurants weren’t even comfortable using the app yet. We were building an autopilot for a plane that hadn’t proven it could take off.
Both times, automation felt like progress. I built something. It ran on its own. But neither time did it solve the actual problem. It just made me feel productive while the real work waited.
Automation at the wrong time can be worse than no automation. It locks you into assumptions, and early assumptions are usually wrong. Build cost is the cheap part. Bugs, edge cases, monitoring, incidents, that’s the real bill. If someone still has to babysit the “automated” system, you didn’t remove manual work. You relocated it.
I also learned that users don’t always want things to be automatic. They want control. They want confirmation before something happens, not after. At that ordering platform, restaurant owners wanted to see each order and say yes. We took that away in the name of “efficiency.” Conversion dropped. We put it back.
Automate when it saves hours, not when it looks impressive.
That Excel file? I still have it. I still filter it by hand. Still takes five minutes.
Reach me if you have other perspectives, or just want to say hello.
Say something.