The Sign-Off Is Not the Agreement

The purchase order was signed. The sensors were on enroute. And the largest school district in the program told me they wouldn’t put a single one on their network.

And they weren’t wrong. Our sensors needed 2.4GHz WiFi; the district ran 5GHz. Adding a separate SSID meant touching firewall policy they didn’t want to touch. Pulling Ethernet to six locations in every building meant cutting walls, patching them, and paying for labor nobody had budgeted. Their IT lead put it plainly:

you need to figure this out, or the program doesn’t move forward.

Some context. I led the deployment for a Kansas statewide initiative to monitor indoor air quality in schools after COVID — real-time CO2 and particulate data in classrooms, offices, and outdoors, tied to state funding. A school district got paid when its sensors were installed, activated, and producing data the staff trusted. We went from a 10-building pilot to 500 buildings — 2,400+ sensors across roughly 100 school districts — a $5.4M+ state contract, with a five-year commitment. I was the SME and deployment engineer on the ground.

Here’s the part that hit hard. I’d been the technical lead on the pre-install calls — dozens of them — and in every one I’d walked the district and their IT staff through the exact network and firewall requirements. The 2.4GHz limitation. The ports we needed open. The MAC whitelisting. Everyone agreed. Everyone signed off.

But I learned the hard way: the sign-off is not the agreement.

At the start, we had a proper plan: an installer and an IT lead unbox six sensors — five indoor, one outdoor — and they’re live in under two hours. The pilot studies taught us it was feasible.

The plan didn’t survive the first real network. Or the second. Or any of them.

So I stopped designing for the deployment we’d agreed to, and started designing for the one I’d actually walk into.

For districts that could broadcast a hidden 2.4GHz SSID, we did that and whitelisted each sensor’s MAC address. For districts that couldn’t, I’d pre-configure sensors off-site with a “phantom” SSID matching theirs, so they’d handshake the moment they powered on in range. And for the district that started all of this — whose network came off a nearby federal facility and was simply off-limits — I built our own network: 2.4GHz routers and cellular data SIMs, pre-configured so the install required nothing but power. Plug it in, it joins our network, it reports.

The outdoor sensors were a different problem. The hardware we shipped was built for a classroom, not a Kansas winter. The obvious answer was a second, ruggedized SKU — but a separate part number meant separate manufacturing, sourcing, inventory, and logistics for a fleet we’d support for five years. So instead I worked with the manufacturer’s design engineer to design a weatherproof enclosure that let the indoor sensor live outdoors: easy to mount, easy to swap, and one fewer thing for a non-technical installer — or my own logistics chain — to get wrong. One SKU for both cases.

The cellular fix, though, became a bigger headache.

Those SIMs ran on a carrier’s 3G network — which the carrier was in the middle of retiring. I found that out after we’d deployed a lot of them, and ended up working with their engineer to keep our SIMs registered against a legacy 3G server so the fleet wouldn’t go dark. It worked. But it was an unknown-unknown I should never have been exposed to, and I’d only chosen that router because hardware was on a tight budget — fixed-price government contract, no asking for more money.

The real thing I’d redo, though, is upstream of all of it. I’d have pushed harder before the team picked a 2.4GHz-only sensor in the first place. That part was chosen on price, to protect margin on a low bid — and the person who had to make it work in the field wasn’t in the room when it was chosen. Half the problems I spent a year and a half solving were designed into the hardware before I ever touched it.

Once I accepted I couldn’t be on every site, the job changed. I wasn’t installing sensors — I was building a system that let other people install them without me.

The decision that actually unlocked scale: train at the district level, not the school level. The largest district had dozens of facilities. Training one IT POC and one installer POC there — with full collateral, a network playbook for every topology, pre-configured gear, and a tiered support queue — let that district repeat the install across its buildings on its own. I fielded the hard tickets; they did the reps. Multiply that by 100 districts, and a six-person team covers 500+ schools.

If I had to hand a field engineer one rule from this program, it’s this:

The customer’s sign-off tells you what they intend. Their site conditions tell you what’s true. Build for the second one.

A few things I no longer deploy without:

• Verify the constraint, don’t confirm it. “Can you support 2.4GHz?” gets a yes. “Can we watch a sensor join your network today?” gets the truth.
• Carry a fallback you fully own — a network, a SKU — before you need it.
• Collapse complexity before you scale it. Every extra SKU, network type, or manual step gets multiplied by hundreds of sites. Kill it at the source — one enclosure, one part number, one playbook.
• Put the deployment engineer in the hardware-selection room. The person who has to make it work on site should have a vote on what ships. Scale through the customer’s own people, at the level where one trained POC covers the most sites.

The sensors were never the hard part. The seam between what we sold, what we shipped, and what the building would actually allow — that was the whole job.