No Central IT Policy, 31 Counties, 300 Staff: What NGO Infrastructure Taught Me

My first week as ICT Officer at Hand in Hand Eastern Africa, I printed a map of every field office — 31 locations across Kenya and Tanzania — and pinned it to the wall next to my desk. Then I wrote four words under it in marker: this is the problem.

The inherited state was what you'd expect from a fast-growing NGO that had scaled faster than its IT function could. Field staff were using personal laptops with whatever software they'd installed themselves. There was no Active Directory. Passwords were scribbled in notebooks or reused across six platforms. The "network" at any given branch was whichever 4G dongle the branch manager had picked up that month. Security posture was, functionally, hope.

Three years later I'd rebuilt enough of the infrastructure to run stable, secure, and measurable — across 300+ staff, two countries, 31 counties, and every flavour of connectivity a field office can throw at you. These are the lessons that hold up, the ones I still apply on every infrastructure project I touch.

Lesson 1: Policy Before Tools

The temptation when you walk into a mess is to buy the shiny thing. MDM platforms. Zero Trust overlays. A new SIEM. Something that feels like progress.

Don't. No technical control in the world enforces what hasn't been agreed to in writing.

The first artefact I produced was not a network diagram or a procurement list. It was a four-page Acceptable Use Policy. What devices were allowed on organisational systems. Who owned the data on them. What staff could and couldn't install. What the consequences of policy breaches were. It was signed off by the Executive Director, rolled out at the next all-hands, and attached to every new-hire onboarding pack.

Only after the policy existed did we start layering in the technical controls to back it up. Active Directory. Group Policy Objects. Endpoint protection. Device enrolment.

Policy is cheap. Tools are expensive. Always start with the cheap thing.

A policy without tools is aspirational but enforceable through management. Tools without policy are a pile of software nobody understands and nobody signed up for. The order matters.

Lesson 2: Treat Active Directory Like a Database Schema

The easiest mistake in AD is to create Organisational Units reactively, as people join — "we'll clean it up later." You will not clean it up later. You'll inherit the mess forever.

Plan your OU tree like you'd plan a database schema: geography first, function second, exceptions last. Ours ended up looking like this:

• HiHEA
  • KE — one sub-OU per branch
  • TZ — one sub-OU per branch
  • Shared Services — finance, HR, M&E, comms, ICT

Group Policy was layered: country-level GPOs handled things like update windows, time zones, and regional compliance (Tanzanian staff had different data-residency requirements than Kenyan ones). Function-level GPOs added the finer controls — finance had stricter clipboard, USB, and RDP rules than comms did.

That structure survived four reorgs over three years. That's the test of a good schema — not how clean it looks today, but how gracefully it absorbs change you didn't plan for.

Lesson 3: Offline-First Is the Default, Not the Exception

Infrastructure patterns built for stable broadband will fail you in the field. I learned this the first time internet died for a full day at our Turkana branch and no one could log in to their own laptops because cached credentials weren't configured.

From then on, the assumption flipped. Connectivity is intermittent by default. Every system had to work when the internet didn't.

Practically, that meant:

• Cached AD credentials — staff could log in and work on their local machine even when the domain controller was unreachable
• Endpoint backups via scheduled sync, not real-time — when connectivity returned, deltas flowed up, never a full re-sync
• Reporting tools with local caches — field officers could capture programme data offline and sync when back at a connected hub
• Software distribution via seeded USBs — yes, really. Sometimes the fastest way to push a 2GB update to a remote branch was to hand a USB to a driver

None of this is glamorous. None of it shows up in a vendor pitch deck. All of it kept the organisation running on weeks when the telco didn't.

Lesson 4: Field Champions Over Centralised Control

You cannot hop on a plane every time a printer jams in Dar es Salaam. And even if you could, you shouldn't.

Every branch got a designated tech point person — not an IT hire, just a staff member who was willing, curious, and good with people. I ran a two-day immersion training for them the first year, quarterly refreshers after that, and kept a permanent WhatsApp group where they could ask questions and share fixes with each other.

Within a year, roughly 80% of tickets were being resolved at branch level without me touching them. The champions learned to reset local printers, walk colleagues through password resets, triage connectivity issues, and escalate the genuinely broken cases with enough detail that I could fix them remotely.

The direct cost of the programme was near zero. The indirect saving was roughly 30,000 kilometres of travel a year and a drop in mean-time-to-resolution from days to hours.

Distributed infrastructure needs distributed people. A centralised IT function cannot serve 31 counties alone — and shouldn't try.

The Unglamorous Truths

A few things I carry with me from those years that aren't on any exam:

• Write it down. If it's not in a doc, it won't scale past you. I wrote runbooks for every recurring task. When I left, my successor was productive in weeks, not months.
• Design for your worst-connected user, not your best. The field officer in Wajir with 2G on a good day is the architecture test, not the finance manager in Nairobi with fibre.
• Budgets are fiction; tech literacy is reality. You can always argue for another licence. You cannot argue a user into skills they don't have. Invest in the humans first.
• NGO and public-sector IT is the best training ground in the industry. Fewer vendors to hide behind. More ownership. Every problem becomes yours because there's no one else to pass it to.

Why This Matters If You Work in Enterprise Tech

Most IT conversations happen in the context of well-funded enterprise environments. Fast internet, dedicated teams, mature vendor ecosystems. That's not most of the world.

Some of the most complex infrastructure environments I've encountered — and the ones where good IT makes the most difference to actual human outcomes — are NGOs, public institutions, and community organisations with a fraction of the budget. If you want to grow as an infrastructure engineer, spend a rotation in one. You'll learn more in twelve months than three years at a bank.

Every assumption you didn't know you had will get tested. And what you build under that kind of constraint is what you'll rely on when things get hard everywhere else.

Building Something Similar?

If you're rebuilding IT for a distributed, resource-constrained organisation — NGO, public institution, field-based team, or a multi-branch business — I'd be glad to compare notes or help you scope it. Get in touch and tell me what you're working with.