The email arrived on a Thursday afternoon. Subject line: All Staff Notice: Business Continuity Plan, Effective Immediately. By end of business Friday, every member of the NGO's 300-plus staff was expected to work from home until further notice. This was March 2020.
I was the ICT Officer. I read the email once, put my head down on my desk for about ten seconds, then opened a spreadsheet.
What the organization had in place for remote work at that moment: a VPN configured for roughly fifteen concurrent users (our Nairobi HQ IT team), a shared SharePoint environment that worked fine on the office network and was largely untested over home internet connections, a patchwork of personal laptops with no MDM enrollment, and absolutely no documentation for any of it. Field staff in county offices had 4G dongles and the strong impression that IT would figure something out.
I had roughly 60 hours before Monday's 8 a.m. standby.
The inventory that changed everything
The first thing I did on Friday evening was stop thinking about the technology and start thinking about the people. Not all 300 staff had the same urgency. Program officers at HQ who needed SharePoint and email were different from field monitors in counties who mostly needed SMS-based data collection and a functioning phone line. Finance staff who ran the payroll system were a different category again.
I built three tiers by Saturday morning. Tier 1: people who would break things for the whole organization if they couldn't work Monday. About forty of them. Tier 2: staff who needed access to produce their own work, maybe a hundred and twenty people. Tier 3: everyone else, whose productivity mattered but whose outage wouldn't cascade into a system-level failure.
That triage probably saved the weekend. It turned an impossible problem ("get 300 people online") into a tractable one ("get 40 critical users stable by Monday, then expand"). I've used that same three-tier framing on every major rollout and incident since. The crisis taught it to me faster than any training would have.
What actually broke on Saturday
The VPN was the first casualty. Our on-premise VPN gateway had been fine for fifteen users. When fifty Tier 1 people tried to connect Saturday morning for a test, it dropped roughly half of them. The remaining connections were slow enough to be unusable for the SharePoint calls the finance team needed.
I had two options: try to expand the VPN capacity (which would have required hardware procurement we couldn't do over a weekend) or change the architecture so that most traffic didn't need the VPN at all. I chose the second.
For most of what staff needed, the bottleneck wasn't access, it was habit. People had been trained to connect to the VPN as their first step because some internal resources genuinely required it. But SharePoint Online, Teams, and email were all cloud services. They didn't need the VPN. They just needed authentication. The VPN had become a security blanket more than a technical requirement for most users.
Saturday afternoon I ran a short documentation exercise: for each system our Tier 1 users needed, does it actually require VPN? The list of things that genuinely needed it was much shorter than anyone thought. I updated the quick-start guide I was writing in real time. VPN for the three internal systems that required it, direct internet for everything else.
That reduced the VPN load by roughly two-thirds. The gateway held for the users who genuinely needed it.
The call I was dreading
There was a senior program director whose county team was essential to a field operation that couldn't pause. Her team were not tech-savvy. They had mixed personal devices, some old laptops, one desktop computer at a county office that couldn't go home. Her message to me on Saturday afternoon was calm, but the subtext wasn't: "We need to be operational on Monday. What exactly should my team do?"
I had been putting off that call because I didn't have a complete answer. That was a mistake. The incomplete answer, delivered clearly and honestly, was much better than the silence I'd offered by avoiding it.
What I told her: the three things her team could definitely do Monday morning (email, the mobile data-collection tool, the reporting form they submitted weekly), the one thing that wasn't ready yet (access to the grants management system), and what I needed from her to fix that second thing (a list of which team members had which devices so I could prioritize enrollment). She gave me the list within an hour. We had four of her seven team members enrolled in the MDM by Sunday evening. The grants system access came Tuesday.
The lesson from that call sits with me still: when you're in the middle of a crisis and someone is depending on you, the kindest thing you can offer is an honest incomplete answer, not a comfortable silence while you wait for a complete one.
Monday morning
The 8 a.m. standby was not smooth. About twenty Tier 2 staff couldn't connect at all, mostly because their personal laptops didn't meet the minimum OS requirements we'd set for MDM enrollment (some were running operating systems that were years out of support). A field coordinator in one county had a router that blocked the authentication ports. Finance's payroll system required a specific browser extension that had been installed on office machines but not personal ones.
None of these were catastrophic. They were tickets, real ones, that we worked through one by one across Monday and Tuesday. The Tier 1 priority system meant that the people who needed to work first were working. The rest came online as we cleared the queue.
What surprised me on Monday was how much of the problem was communication, not technology. Staff who couldn't connect assumed it was their fault. They didn't report it. Two people sat with broken setups for most of Monday morning before they messaged me, because they thought they were doing something wrong. Setting up a simple status channel and making it unmistakably clear that "if it doesn't work, message here immediately, this is not your fault" moved twice as fast as the ticket queue alone.
What held, and what I still think about
By the end of the first week, roughly 85 percent of staff had a functional working setup. By the end of month one, we were at something close to full operational capacity, with better visibility into device health than we'd ever had when everyone was in the office. The enforced crisis turned into a genuine infrastructure improvement, because we finally had to document everything and enroll everything properly.
But I think about the gaps we got lucky on. The VPN issue could have been worse. If field staff had genuinely needed the internal systems that required VPN access, the Saturday workaround would not have held. We got lucky that most of what people needed was cloud-hosted. If we'd been one year earlier in our SharePoint migration, we would have been in real trouble.
I also think about the fifteen users we never got fully stable. Staff in areas with genuinely bad connectivity, not just inconvenient connectivity, but bandwidth so constrained that even a lightweight Teams call dropped constantly. We worked around it with async communication, but those staff members were effectively working at a disadvantage for the duration of the remote period, and I'm not sure I ever solved that properly, just managed around it.
A crisis reveals the assumptions your infrastructure was built on. Ours was built on the assumption that everyone would always be in the building. The pandemic made that visible in 60 hours.
The thing I'd do differently
The playbook I wrote that weekend, rough as it was, became the foundation of every remote-access and business-continuity document the organization produced for the next two years. That's good. What's less good is that it took a global emergency to produce it.
If I could go back, I'd have run a fire drill six months earlier. Not a full remote-work exercise, just a tabletop: what happens if fifty people need to work from home tomorrow? Who are the critical users? What does each of them need? Where are the bottlenecks? Two hours of honest conversation would have surfaced most of what the crisis forced us to discover under pressure.
Infrastructure stress-tests are a gift you give your future self. They feel wasteful when nothing is on fire. They feel obvious when something is.
If you're running IT for an organization that hasn't asked that question recently, ask it this week. You don't need a global crisis to find the answer. You just need an afternoon and the willingness to be honest about what you find.
And if you're currently in the middle of a rollout that feels like controlled chaos, drop me a line. I've been in the chaos. Sometimes it helps to talk to someone who came out the other side.
Comments