Image Credit: Pixel cells problem technology by Manfred Steger from Pixabay.
There is a category of GIS problem that does not show up in job descriptions, does not appear in project timelines, and rarely makes it into executive conversations. I’d like to name it today as a GIS single point of failure.
It shows up as a backlog — a slow, persistent accumulation of unresolved issues that everyone knows about and no one has the bandwidth to address systematically. The work keeps moving. The deliverables keep going out. But underneath the surface, the system is held together by the judgment of one or two people who carry everything in their heads.
The Engagement
Last year, I encountered this directly during a short-term engagement with a US-based telecommunications infrastructure company. They had recently migrated from ArcGIS Online to ArcGIS Enterprise — a transition that is never one-to-one, and in this case had introduced structural issues the team had been managing reactively ever since. The field operation ran on Esri Field Maps. Construction crews submitted daily production data. Billing codes were generated automatically through spatial logic tied to the geodatabase. At any given moment, over two hundred users depended on the accuracy of that system.
The GIS operation was run by two people.
When the Technical Director described the situation in our first conversation, he named it as a backlog management problem. There were over 280 open issues assigned to one technician. The validation layer had gaps. Engineering and construction GIS worked in separate silos. There was no written documentation of any workflow — not because no one had thought to create it, but because until recently there had been no one else to write it for.
The Actual Problem
I understood what he was describing. But what I heard underneath it was something different.
This was not a backlog problem. This was a structural problem wearing the costume of a backlog problem.
The distinction matters because solving a backlog without addressing its structural cause is not a solution — it is a postponement. You resolve the 280 issues. Three months later, there are 280 more. The technician is still the single point of failure. The workflows are still undocumented. The billing risk is still present every time a crew submits inconsistent field data or engineering sends a shapefile with corrupted values.
What the Organization Actually Had
What this organization had was a transversal GIS function — one that touched engineering, construction, billing, and client-facing reporting — managed as if it were a single-point technical service. The spatial data lifecycle ran from design intake through field collection, issue resolution, and billing validation. It crossed at least four functional groups. It had direct revenue implications. And it depended on the tacit knowledge of people who had never had the time or the mandate to formalize what they knew.
This is not unusual. It is the most common configuration I have seen in organizations that have grown their GIS capacity organically — where the technology expanded faster than the governance structure around it. The tools became sophisticated. The workflows became complex. The organizational understanding of what GIS actually does did not keep pace.
The result is always some version of the same pattern: a highly capable system, chronically understaffed, producing real business value that the organization cannot fully see or protect.
What the Engagement Required
During the month I spent inside this operation, I did what the situation required: I learned the workflows from the inside, mapped the data lifecycle, began documenting processes that had never been written down, and identified where the structural gaps were creating the most downstream risk. My goal was not to fix the backlog. It was to give the organization a clear picture of what it actually had — and what it would take to make it sustainable.
The Technical Director’s assessment at the end of the first conversation stayed with me. After I described my approach, he said something I have heard in different forms across multiple organizations: that I was not quite the resource they had asked for, but possibly exactly the resource they needed.
The Gap That Stays Unnamed
That gap — between what an organization asks for and what it actually needs — is where most GIS professionals spend their entire careers. They are hired to resolve the backlog. They are not asked to name the structural problem that produces it. And so the backlog remains, reassigned from one ticket to the next, while the real issue goes unnamed.
Naming it is the first act of organizational GIS strategy.
What the Technical Director had was not a staffing problem with a spatial data problem attached. He had a decision infrastructure problem — a GIS function that had grown to the point where it was making consequential decisions about billing accuracy, field crew coordination, and client-facing reporting, without the organizational positioning, documentation, or staffing to match that level of consequence.
That is a different conversation than backlog management. And it requires a different kind of professional to have it.
From My Lens
The professionals who carry institutional GIS knowledge alone rarely have the organizational language to name what they are actually doing. They can see the structural problem clearly — they live inside it every day. What they often lack is the framework to surface it as a decision infrastructure risk rather than a workload issue.
That shift in framing changes what gets resourced, what gets documented, and what gets protected. It is the difference between managing a backlog indefinitely and building a system that does not depend on any single person’s presence to function.
If your GIS operation is running on the tacit knowledge of one or two people, the risk is not in the backlog. It is in what happens the day those people are unavailable.
In a GIS Clarity Session, we name what you are actually carrying — and build the language to make it visible to the people who need to understand it.
🧭 Continue Reading
Leave a Reply