Ignore the person behind the curtain
For most of my career, GIS has “worked” not because the systems were resilient, but because very smart, very patient people were standing just out of frame.
When something broke, a person noticed.
When data didn’t line up, a person fixed it.
When a workflow wasn’t documented, a person remembered how it worked last time.
Because that person existed, the system appeared stable.
It wasn’t.
It was buffered.
GIS grew up assuming that humans would always be there to absorb ambiguity, reconcile inconsistencies, and quietly make the output “look right.” That assumption is so deeply embedded that we rarely question it. And for a long time, it mostly worked.
Until it didn’t.
There’s a particular kind of failure mode that shows up in spatial systems. Nothing crashes. No alert fires. No exception bubbles up. Instead, someone notices that the map looks weird.
So they rerun a job. Or reproject a layer. Or fix a filename. Or resend a link. The immediate problem goes away, and everyone moves on. The system never learns. The workflow never changes. The metadata stays optional. The cost of correctness is quietly paid in human attention.
This is the most dangerous kind of success: success that hides the labor required to sustain it.
This is why GIS is often described as “flexible.” But that flexibility isn’t coming from the software. It’s coming from people.
It’s coming from someone who can hold five coordinate systems in their head. From someone who knows which dataset is actually authoritative. From someone who understands that this feed is always late, that this join only works on Tuesdays, that this export needs to be nudged just a little to behave.
That isn’t system flexibility. It’s human elasticity.
And elasticity doesn’t scale. It stretches. Then it snaps. Quietly.
At small scale, this feels like craftsmanship.
At medium scale, it feels like heroics.
At large scale, it feels like burnout.
This is why scaling spatial systems feels uniquely painful. Not because geometry is hard, and not because spatial data is special, but because complexity has been hidden in people instead of encoded into infrastructure.
When those people leave, take vacation, or simply get tired of being the last line of defense, the system doesn’t degrade gracefully. It collapses.
Every time a person manually triggers a pipeline, sanity-checks output visually, emails files between systems, or explains the same caveat again, they are acting as middleware.
They are doing orchestration.
They are performing validation.
They are carrying undocumented contracts in their head.
In any other software domain, we would call this technical debt. In GIS, we call it “just how it works.”
And then we wonder why automation stalls, why onboarding takes months, and why every attempt at “cloud-native GIS” feels like it stalls out at hosted desktops and scheduled scripts.
What actually scales isn’t removing humans from the loop. It’s removing humans from the correctness path.
Systems that scale make workflows explicit instead of tribal. They treat metadata as operational infrastructure, not documentation theater. They fail loudly instead of aesthetically. They rely on contracts between steps, not shared assumptions between people.
This is why ideas like data contracts matter
(https://martinfowler.com/articles/data-monolith-to-mesh.html),
why workflow engines matter
(https://airflow.apache.org/),
why observable pipelines matter
(https://opentelemetry.io/),
and why file-based “just drop it in the bucket” architectures eventually collapse under their own ambiguity.
The goal isn’t rigidity. The goal is trust.
If your spatial platform only works because a few key people know how to fix it, you don’t have infrastructure.
You have institutional memory.
And institutional memory does not survive growth.
This is the lesson scale teaches over and over, whether we want to hear it or not:
People are incredible. People are essential.
But humans are not a scalable integration pattern.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.