Skip to content

← Writing

engineering

Taal, Ashfall, and the Question Nobody Asked: Can Your Team Work From Home?

· Jerwin Arnado

Archive note: this is a backdated post, written years later while rebuilding this site. It’s dated to the moment it covers, but the hindsight is real.

On January 12, Taal Volcano erupted. Within hours, ash was falling on Calabarzon and Metro Manila, classes and flights were suspended, and a lot of companies sent out the same panicked memo: work from home if you can.

“If you can” was doing a lot of heavy lifting in that sentence.

The infrastructure question

It turned out a surprising number of teams couldn’t. Not because the work itself required an office, but because nothing about how they operated had ever been tested outside one:

  • Code that only deployed from one machine sitting under someone’s desk.
  • Databases reachable only from the office IP.
  • Approvals that lived on paper, in drawers.
  • “The VPN” that nobody had logged into since it was set up.

For developers, the eruption was a low-stakes fire drill. A few days of disruption, then mostly back to normal. But it raised a question worth answering honestly: if the office disappeared tomorrow, how long before your team ships code again?

What actually mattered

The teams that handled that week well had boring things in place, none of which were bought during the emergency:

  1. Everything in version control — not just code, but deployment scripts and infrastructure notes.
  2. Cloud-reachable environments — staging and production you can deploy to from anywhere with credentials, not from a blessed machine.
  3. Written communication by default — if decisions already lived in chat threads and tickets instead of hallway conversations, distance changed nothing.
  4. A laptop policy — people who worked on desktops were simply offline.

None of this is exotic. It’s the gap between “we use Git” and “our process survives nobody being in the same room.”

The PH-specific layer

There’s an extra layer here that remote-work articles from abroad skip: home internet in the Philippines is the real single point of failure. A team can have perfect cloud infrastructure and still lose half its developers to a brownout or a dropped DSL line. Mobile data as backup, generous async expectations, and not scheduling life around video calls — that’s the local adaptation.

I’m writing this down mostly as a note to self. Taal was a regional disruption that lasted days. It felt like a one-off. But the readiness gap it exposed — teams that could relocate in an afternoon versus teams that were paralyzed — seemed like the kind of thing that would matter again eventually.

It would matter much sooner than anyone guessed.