I walked over to the billing desk to check on a new hire. He was covering for a colleague who quit, and pointed to a screen displaying 300 auto-generated Zoho invoices. He leaned back and told me he was overwhelmed by this two-day process.
I looked at the screen. In that exact moment, I realized he had absolutely no idea what he was looking at.
He saw a repetitive digital chore. He did not know that just three years ago, this exact task took three people seven days to complete.
He did not know about the twelve Excel tabs or the manual GST logs. He did not know about the 15 per cent error rate that delayed our cash flow.
I run a ₹1.5 crore monthly security operation across 45 cities. Dragging it out of operational chaos took everything. I spent ₹2.5 lakh and fought seven months of internal resistance to migrate to Zoho.
I built custom logic to handle city-specific compliance. But the employees who built that bridge are gone. The new team inherited a working system and called it an inconvenience.
I cannot blame him. I made the exact same mistake when I inherited this business. My father passed away suddenly.
There was no succession plan, and I had been working to start my own venture. Because there was no warning, there was no handover. I looked at the chaotic Excel tabs and assumed that was just how things were.
I was naive. I asked the Day-1 employees to explain everything. In doing so, they told me the stories of the original chaos.
I accidentally learned the rationality of the old system. That accident is the only reason the Zoho migration worked.
It is like watching a junior mechanic complain about tightening a single bolt on a Formula One transmission. He does not know that three years ago, the chassis failed every ten kilometre run.
He sees the friction of the maintenance. He does not see the failure-proofing that keeps the car running at 250+ kilometres per hour.
This is the danger of scaling. Memory held by one person is not a system. It is a single point of failure.
The standard advice is to write standard operating procedures to fix this. That is the wrong assignment. I know this because I made the same error building our new O9X software.
I relied on our SOPs. They described how the system worked. I had forgotten why we built it that way.
Almost immediately, the old billing chaos started returning.
Robert Pirsig writes this. Tear down a factory, but leave its original rationality standing. That rationality will simply produce another factory.
The inverse is true for operators. Tear down a system without understanding its rationality. Forgotten chaos will rebuild itself.
I stopped writing SOPs. I cannot rely on the accident of oral history. So I now write a Survival Log such as this very build log for O9X
I ask my team to document three things before any system upgrade:
- The Current Status
- The Specific Pain Point
- The Historical Rationality (the exact chaos this system was built to prevent)
For our billing upgrade, the Historical Rationality entry is blunt: twelve Excel tabs. Manual GST logs. A 15 per cent error rate that delayed cash flow.
Incremental updates seem boring. But every major innovation survives only because someone managed past failures quietly. If you do not record how the old system broke, the new one breaks faster.
An old system’s rationality always demands respect, whether you document it or not.