The Failure Happened Long Before Oracle's 6AM Email

Five months after we moved to Zoho Books, my accountant told me why he had delayed the migration for four months.

I was worried that if this system makes everything easier, you might not need me.

He had built those Excel templates over years. Formulas, macros, shortcuts. He knew every quirk of every file.

Zoho Books made all of that obsolete in a week. His fear was not irrational. It was accurate.

I had assumed the benefits were obvious. I had never told him his job was safe.

Reports said Oracle began notifying employees of layoffs on 31 March 2026. Employees described receiving termination emails at 6am, with no prior warning from HR or their direct managers. Oracle cut system access within hours.

The reported email language said their roles had been eliminated “as part of a broader organisational change”.

My accountant and, I suspect, many of those Oracle employees faced the same fear. He expressed it. They received it as a fact.

I announced the Zoho Books migration without first telling my accountant what it meant for his job. He stalled for four months. Every month brought a new reason: data needed cleaning, templates were not ready, month-end was coming.

I put my foot down. Fifteen days. It happened.

Five months later, I understood why it had taken so long. I had skipped the one conversation that mattered. Now I have it before I announce the change, not after.

I sat down and asked what work he found most boring. Then I asked what work he wished he had more time for. He told me.

I explained what the software had taken off his plate and what that freed him to do. Nobody was losing their job. When we scaled, we would not need to hire more people for billing runs.

He now does financial analysis and cash flow modelling. Work he never had time for when billing consumed 10+ days every month.

The same person who handled payroll for 450 employees now manages 850. He could likely handle 1,500 without help.

The system did not replace him. It revealed what he was actually capable of.

This is the part Oracle skipped.

The lesson was already visible in my own business. Oracle is only a larger version of the same failure.

Oracle built a great business on database software. Revenue grew. Profits grew. Headcount grew.

In good times, that is what companies do. Nobody questions whether each new hire is genuinely necessary. The money is there. The workload appears to justify it.

Then AI arrived and changed what Oracle thought it needed to be.

Oracle’s stock fell 25% in 2026. The core business still works, at least on the numbers. Oracle posted a 95% jump in net income last quarter.

Oracle had also told investors it expected to raise $45 billion to $50 billion in 2026 for infrastructure expansion. TD Cowen estimated cuts of that scale could add ₹6,640 crore to ₹8,300 crore ($8 billion to $10 billion) in cash flow. From the outside, the layoffs look at least partly financial.

From the outside, that reads as a financial transaction dressed up as an organisational decision.

Paul Graham drew a useful distinction between two ways companies operate. Manager Mode keeps large organisations functional: processes, layers, coordination. It absorbs growth without falling apart. Founder Mode is how companies do bold, risky things: direct control, fast decisions, tolerance for disruption.

Oracle spent years in Manager Mode. Headcount accumulated. Systems grew around people. The organisation built itself for running smoothly, not for moving fast.

Now Oracle is making Founder Mode moves but executing them through Manager Mode machinery.

Block’s CEO argued that repeated rounds of cuts damage morale, focus, and trust. That is why he framed the move as one decisive round rather than multiple phases.

I am sceptical of the Block narrative from the outside. A well-packaged press release is not the same as a well-executed decision. But the logic points in the right direction.

If you cannot describe the organisation you are cutting toward, you are not redesigning. You are hitting a number.

To me, the 6am email is what number-first restructuring looks like from the outside.

I should be honest about what I am inferring here. I do not sit in Oracle’s board meetings. It is possible they have a detailed organisational blueprint their communication simply failed to convey.

But execution tells its own story.

A genuine redesign tells the people who remain what the new organisation looks like and where they fit in it.

A financial transaction sends an email at 6am.

The distinction matters because of what happens to the people who stay.

Oracle’s roughly 130,000 remaining employees knew that thousands of colleagues had lost system access the same morning they lost their jobs. Now they are asking the same question my accountant asked for four months: what happens to me?

The difference is nobody is coming to have that conversation.

A person afraid of being cut does not take risks. They do not flag problems that fall outside what is being measured. They find ways to make themselves hard to remove. They adjust their work to look good on whatever metric is currently being watched.

A company full of people not rocking the boat will not notice small cracks appearing in customer relationships. Those cracks become someone else’s market share. No single dramatic failure. A slow bleed nobody traces back to a 6am email sent two years earlier.

I made my own version of Oracle’s mistake in late 2023. I was looking for a sales manager.

I took time over the decision. I ran the conversations carefully. I still got it wrong.

The person was excellent in an environment where leads arrive and the job is to close them. My company needed someone who could build the sales playbook from nothing. Generate leads, walk the full cycle, create the system a future team could run.

I hired an executor for a builder’s role.

I never asked the right question. Not “can this person sell?” but “can this person build the playbook a future team will run?” Those are different people.

Subject to hindsight bias, I see this clearly now. I did not see it in the hiring conversation. But I believe the framing holds.

The evidence was there: he had only ever executed playbooks someone else built. He had never constructed one from scratch.

Now I sit down and ask two questions before the system changes: 

• What’s the part of your work you’d happily give up?
• What’s the part you wish you had more time for? 

Then I can introduce the system as the thing that makes this shift possible

My operating philosophy now is simple: Systems fail, people do not (unless they lack basic aptitude; then no system helps, and I take the hard call).

I explain clearly why the change is needed. I give assurance that no cuts are coming.

Then I provide training and a transition timeline. I offer real opportunities to make the crossing. Most people, given a working system and a genuine reason to trust the move, will surprise you.

The system reveals what trainable people can do. It does not create capability from nothing.

Before every hire now, I ask one question: Can this person do this job better when we are three to four times our current size, five years from now?

Builders are expensive. After a year of trying to hire one for sales, I am building the playbook myself. Maybe I will fail. But that is better than hiring and firing another person to avoid doing the hard work.

Oracle had about 162,000 people. From the outside, it did not look like the company had a clear public answer to either question.

The failure in a restructuring is rarely the layoff itself. It happens earlier, when leadership changes the system before telling people what they become inside the new one.

Annexure: How markets read tech layoffs

The pattern we can observe is not “layoffs are good for stocks.” It is much narrower: markets often reward layoffs when they reinforce a story of discipline, efficiency, or credible AI-led margin expansion, as in SAP, Meta, and Spotify.

Markets have reacted negatively when layoffs arrived with weak guidance, visible operating stress, or a broader turnaround under pressure, as in Cisco and especially Intel. In those cases, the cuts appears less like design and more as evidence that the business is under strain.

Oracle matters because it appears closer to the second bucket than the first.

One caveat: the “30,000 cuts” number is not confirmed anywhere explicitly, so any exact figure needs to be treated as an estimate rather than a confirmed final count.