The Bench Your Agency Cannot Build

Every public safety leader has tried to solve this problem the same way. They try to hire.

They ask for a CAD administrator. Or a Technology Director. Or a Public Safety Applications Administrator. Or a systems analyst who can “help with CAD, RMS, mobile, reporting, and vendor tickets.” The request sounds reasonable. The agency needs the work done, so the instinct is to create a position.

The problem is structural.

Most agencies do not need one more person. They need a bench. They need CAD administration, RMS administration, JMS administration, evidence support, mobile data support, radio awareness, interface troubleshooting, reporting, governance, vendor escalation, ticketing, documentation, and continuity. That is not one role. That is an operating model.

Most agencies, especially small and mid-sized agencies, cannot build that operating model internally. Not because they are unwilling. Because the structure will not let them. Public sector hiring cycles are slow. Compensation bands are constrained. Benefits and pension costs change the real math. The private sector outbids agencies for the same technical talent. Civil service rules and background investigations add time. Specialized staff leave. Documentation disappears. The agency starts over.

Meanwhile, the CAD still has to work. The RMS still has to report. The jail system still has to book. The evidence platform still has to preserve chain of custody. The mobile clients still have to communicate. The radio system still has to support field operations. And the dispatcher on night shift still needs someone to fix the problem before the workaround becomes permanent.

This Insight is about the bench public safety agencies cannot build, the bench public safety agencies actually need, and the structural alternative that exists when both founders of Sentinel sit down to design it the way the work demands. It is also about why hiring and vendor admin hours, the two paths agencies usually try, will never fully solve the problem because neither one changes the structure.

The Hiring Story Every Agency Has Lived

We have watched this play out over and over again.

An agency finally admits it has a technology administration problem. The CAD administrator retired. The person who knew RMS reporting left for the vendor. The radio technician is overwhelmed. The IT department is doing its best, but it is also supporting finance, HR, public works, body cameras, email, cybersecurity, the website, and whatever broke that morning.

So the agency does what agencies do. It asks for a position.

Then the obstacle course begins.

First comes the internal justification. Then the budget conversation. Then the classification study. Then HR has to determine whether this is an IT position, a police department position, a communications position, or some new hybrid class that does not exist in the pay plan. Then the compensation band comes back too low because the classification system compares the position to a general analyst role, not to a mission-critical public safety technologist.

Then the posting opens. It runs for 30 days. Maybe 60. Maybe 90. Three people apply. One has help desk experience but no public safety background. One has used CAD but never administered it. One looks promising, but they are already interviewing with a vendor. The agency finally selects a candidate, starts the background, and waits. By the time the offer is ready, the candidate has accepted something else. The position sits open again.

That is not an exaggeration. NEOGOV reported that public sector time-to-hire averaged 119 days in 2019, with local government averaging 130 days, more than three times the private sector average cited in the same report. A Santa Cruz County civil grand jury report was even more blunt: due to existing practices, the county's hiring process often took six months to a year, and candidates frequently accepted other opportunities before an offer could be made.

That is the hiring story before the person ever logs into CAD. Now add public safety background checks, CJIS access, agency-specific onboarding, vendor training, and the reality that the person still has to learn the local configuration. By the time the agency has a productive administrator, it may be 12 to 18 months from the day the problem was first acknowledged.

Then the person gets good. Then the private sector calls. And the agency starts over.

The agency does not lose the technology administrator the day they resign. The agency loses them the day it realizes all the knowledge walked out with them.

The Hidden Math Agencies Do Not See Until Too Late

The phrase “one new FTE” makes the decision sound smaller than it is. It is not one new FTE. It is a long-term financial obligation.

The salary is the number everyone sees. The real number is salary, benefits, retirement contributions, workers' compensation, leave, equipment, software access, training, recruiting cost, onboarding cost, supervision, backfill, overtime impact, and the cost of losing the person when they leave.

The U.S. Bureau of Labor Statistics reported that, as of December 2025, state and local government compensation costs averaged $65.68 per hour worked, with wages and salaries accounting for 61.7% of employer costs and benefits accounting for 38.3%. Put plainly: if an agency thinks it approved a $90,000 role, the fully loaded annual cost may be closer to $145,000 before recruiting, training, equipment, and knowledge-loss costs are even counted.

Now stretch that out. A $90,000 salary translated into a roughly $145,000 loaded annual cost becomes approximately $1.45 million over ten years and roughly $4.3 million over 30 years before inflation, step increases, overtime, future benefit cost changes, retiree healthcare exposure, or pension-plan-specific obligations.

That does not mean every $90,000 public safety technology position creates the same actuarial liability. It does not. Pension structures vary by state, plan, tier, employee contribution, employer contribution, vesting, and retiree healthcare policy. The broader point is true. The public agency is not buying a position for one budget year. It is creating a long-term obligation in a labor market where retention is uncertain.

That changes the math.

If one person could cover CAD, RMS, JMS, mobile, evidence, radio, interfaces, reporting, security, and vendor escalation, the FTE argument would be stronger. That person almost never exists. So the agency approves one FTE and then discovers the work actually requires a bench.

The agency thought it approved one technology position. What it actually approved was the first seat in a bench it still cannot afford to build.

The Specialization Fragmentation Trap

From the engineering side, this is where the plan starts to break.

Agencies talk about “a technology administrator” like that is one skill set. It is not.

Modern public safety technology stacks are fragmented by design, by vendor history, by acquisition, by regulation, and by operational discipline. CAD is not RMS. RMS is not JMS. JMS is not evidence. Evidence is not mobile. Mobile is not radio. Radio is not NG911. Interfaces are their own problem. Reporting is its own problem. Security and CJIS are layered across all of it.

A public safety applications administrator posting from Broomfield, Colorado captures the reality well. The role includes day-to-day configuration, training, support, maintenance, improvements, patch testing, feature configuration, user access management, and user training for public safety applications. That sounds like one job description. In practice, it can represent five different specialties.

CAD administration includes call types, unit status codes, dispatch recommendations, fire run cards, response plans, move-up logic, geofile behavior, premise alerts, agency hierarchies, interface monitoring, CAD-to-CAD behavior, mapping, AVL, paging, station alerting, and failure procedures.

RMS administration is different. The BJA and LEITSC RMS functional specifications describe RMS as an agency-wide system supporting storage, retrieval, retention, manipulation, archiving, and viewing of law enforcement records across incident reports, arrests, citations, warrants, case management, field contacts, internal affairs, crime analysis, interfaces, RMS administration, and reporting. That is not just records. That is the legal data backbone of the agency.

JMS administration is different again. Booking workflows, inmate classification, housing movement, medical screening interfaces, court interfaces, commissary, visitation, release workflows, audit logs, and facility safety do not behave like CAD or RMS.

Digital evidence administration brings storage policy, retention, redaction, prosecutor sharing, audit trails, chain of custody, media ingestion, disclosure workflows, and body-worn camera lifecycle.

Mobile data administration brings MDC behavior, device profiles, field reporting, message switching, NCIC and CCIC queries, premise alerts, offline behavior, wireless connectivity, and field officer workflow.

Radio administration brings fleet maps, talkgroups, subscriber programming, encryption keys, key management, ISSI and CSSI, console permissions, RF coverage issues, logging recorder integration, and mutual aid behavior.

Each one of those is a specialist role in a vendor company or a large metropolitan agency. The mid-sized agency posts one job and hopes one person can cover all of it. That is not a staffing plan. That is a bet.

The public safety technology stack has fragmented into specialist disciplines. Agencies are still trying to hire generalists to carry specialist risk.

The Vendor Admin Alternative And Why It Fails Differently

When agencies cannot hire the person, they often turn to the vendor. That is understandable.

The CAD vendor offers admin hours. The RMS vendor offers admin hours. The evidence vendor offers professional services. The radio vendor offers managed services. The body-camera vendor offers implementation support. The JMS vendor offers configuration assistance. On paper, this looks reasonable. In practice, it fragments ownership even further.

The vendor administrator knows the vendor's product. That is useful. The agency's real problems rarely stop at one product boundary.

A CAD-to-RMS issue is not only a CAD issue. It is not only an RMS issue. A mobile query issue may involve the mobile client, message switch, network, permissions, RMS data, and CJIS policy. An evidence problem may involve RMS case numbers, prosecutor export, user role security, storage policy, and chain-of-custody audit. A dispatch alerting problem may involve CAD, paging, station alerting, radio, network, and agency policy.

The vendor admin sees their system. The agency needs someone to see the whole environment.

Public contracts show how quickly vendor services become their own cost category. In one public CentralSquare agreement, services were broken into CAD cloud migration, public safety consulting, development, GIS and analytics, project management, technical services, and training, with subscription fees scheduled to increase 3 percent in years 2 through 4 and 5 percent in year 5 onward. A Tyler agreement with the City of Orange states that professional services fees are estimates, that actual fees depend on factors such as city involvement and speed of knowledge transfer, and that discrepancies can be resolved by multiplying hourly rates by quoted hours.

That is not a criticism of those vendors. That is how professional services contracts work. Agencies need to understand the incentive structure.

Vendor admin hours are revenue to the vendor. Root-cause fixes that reduce future hours are not always naturally aligned with that model. Vendor admins do not usually recommend leaving the platform. They cannot work deeply across the competitor's product. They may rotate. The agency-specific configuration knowledge may not carry forward. When the problem lives between systems, each vendor can be technically correct while the agency remains operationally stuck.

That is the failure mode.

Vendor administrators are not bad because they work for vendors. They are limited because they work for vendors.

The Accountability Gap Between Vendors

This is the moment every agency recognizes.

A dispatcher reports that a call update is not flowing correctly to mobile. Patrol says the incident notes are delayed. Records says the RMS report is missing key fields. The mobile vendor says the message was received. The CAD vendor says the data was sent. The RMS vendor says the field was not populated correctly. IT says the network was clean. The supervisor opens three tickets. Three vendors investigate. All three return the same answer.

“Not us.”

The ticket sits open. The shift builds a workaround. The workaround becomes tribal knowledge. New hires learn the workaround instead of the process. Six months later, leadership asks why the same issue is still happening, and no one can explain the original defect because the email thread is buried, the vendor portal ticket is closed, and the one person who knew the issue left.

That is the accountability gap.

Operationally, this destroys confidence. The supervisor is the one standing in front of the chief explaining why staff keep complaining about the same problem. The dispatcher does not care which vendor owns it. The officer in the field does not care whether the message bus, RMS API, or CAD interface caused it. They care that the information is wrong or late. Once the floor stops believing the system will be fixed, they stop reporting issues properly. They build shadow processes. They make cheat sheets. They avoid certain workflows. They say, “That system never works right,” and eventually leadership stops getting clean data about the actual problem.

Technically, the fault often lives at the seam. The data mapping is wrong. The field length is mismatched. The code table values do not align. One system sends null. Another system expects a value. One system uses an agency-specific event type. Another expects a standardized value. One vendor updated a schema. Another did not update its connector. The interface did exactly what it was configured to do, but what it was configured to do is no longer what the agency needs. The vendor looking only at its own logs can honestly say, “Our system is working.” The agency still has a broken workflow. That is why someone has to own the seam.

The National 911 Program has documented that CAD systems are an integrated component of the 911 emergency response ecosystem and that stakeholders cite challenges such as lack of funding, lack of standards enforcement, common terminology problems, and disparate policies and procedures as obstacles to seamless CAD data sharing. Those are not abstract problems. Those are the seams where real agencies get stuck.

The most expensive technology problems in public safety rarely live inside one system. They live between systems, where every vendor can deny ownership and still be technically correct.

What Practitioner-Led Embedded Administration Actually Looks Like

This is the pivot.

The answer is not to replace one missing FTE with one consultant. That is not enough. The answer is to change the structure.

A practitioner-led embedded administration model gives the agency access to a bench it cannot build alone. Not a generic IT bench. A public safety technology bench. People who understand CAD, RMS, mobile, JMS, evidence, radio, dispatch operations, records operations, CJIS, vendor behavior, implementation history, and the way public agencies actually make decisions.

Sentinel Admin™ is built around that premise. One Sentinel practitioner working across CAD, RMS, Mobile, and JMS, delivered remotely, embedded full-time, or shared regionally, with Sentinel Response™ included in every engagement. The model is deliberately not one-size-fits-all. It can be remote monthly hours, a dedicated on-site administrator, or a shared on-site administrator across multiple agencies in a region.

From the agency-leadership side, the value is continuity and control. The chief, sheriff, dispatch director, IT director, or city manager does not want five different vendor portals, seven unresolved email threads, and a technology problem that nobody owns. They want one place to go. They want to know what is open, what is in progress, what is waiting on vendor input, what has been resolved, and what keeps recurring. They need operational governance, not just technical support. A practitioner-led admin model gives them that. It gives the agency a partner whose loyalty runs to the agency, not to a product. It gives leadership visibility without forcing them to become system administrators themselves.

From the engineering side, the work is disciplined. Provisioning is documented. Roles and permissions are controlled. Configuration decisions are tracked. Workflow changes are tied to operational need. Interfaces are monitored. Vendor escalations are specific. Repeat issues are recognized as patterns. Changes survive staff turnover because the knowledge lives in the ticket, the configuration log, the diagram, the runbook, and the quarterly review, not in one person's head.

That is what most agencies are missing.

Sentinel Admin™ does not replace a person. It replaces the fragile idea that one person was ever enough.

Why Sentinel Is Built To Carry This Work

Sentinel exists because the agencies doing the hardest work in public safety, government, and mission-critical technology deserved someone on their side of the table. Not a vendor. Not a generic MSP. Not a law firm. A practitioner firm with no resale margin, no referral fees, and no commissions, whose loyalty runs only to the agency it serves.

That is not language we adopted because it sounded good in a brochure. It is the design principle behind how the firm was built and how it operates every day.

The two of us, Justin and Jason, founded Sentinel after decades of doing this work on both sides of the table. We have operated CAD, RMS, JMS, mobile, evidence, and radio systems from inside agencies. We have managed program deployments for vendors. We have sat in dispatch supervisor seats and project manager seats and command staff briefings. We have watched what works and watched what does not. Sentinel's delivery principles were not borrowed from a corporate consulting playbook. They were designed around public safety and mission-critical technology because that is the only kind of work this firm has ever done.

We recruit and train our people the same way. The practitioners we bring into the firm have lived the work. They have run a dispatch floor. They have written records policy. They have administered evidence systems. They have configured CAD environments under live operational pressure. They understand the difference between a 0200 dispatch-floor defect and an 0800 administrative office printer issue, because they have stood in both rooms at the right time. Every Sentinel practitioner is mentored and guided by one of the founders. That is structural, not aspirational. When an agency engages Sentinel, the work is delivered by a practitioner whose judgment is shaped by people who have personally led the same kind of program for the agencies the firm serves.

We operate as a small firm by design. That is the source of our agility and the source of our depth. A large MSP can cover a thousand customers and lose any one of them without noticing. Sentinel cannot. Every Sentinel customer has the backing of the whole firm, including both founders, because the firm is small enough that nothing happens at scale without the founders knowing about it. That is the partnership model. The agency does not get a junior account manager and an offshore queue. The agency gets a practitioner working their environment, with a senior bench standing behind that practitioner, and with the founders accessible when the situation requires founder-level engagement.

Independent. Practitioner-led. Vendor-neutral. While the phases move, Sentinel stays. That language is not marketing. It is the operating reality of how every Sentinel Admin engagement is structured. The administrator changes. The vendor changes. The chief changes. The technology refreshes. Sentinel stays. The institutional memory the agency cannot afford to build internally lives in the firm that is built to carry it.

Sentinel Response™: Ticketing Designed By Public Safety, For Public Safety

Sentinel Response™ matters because public safety technology work needs a system of record.

Most agencies are operating in one of two worlds. Either they have nothing: email, phone calls, hallway conversations, sticky notes, and vendor portals. Or they have a generic IT help desk that was designed for password resets, laptop tickets, printer issues, and office software problems, then stretched awkwardly over CAD, RMS, radio, evidence, and mobile workflows.

Public safety does not work that way.

A CAD issue is not the same as a desktop issue. A records validation issue is not the same as a Microsoft 365 ticket. A radio encryption issue is not the same as a printer problem. A dispatch-floor defect at 0200 has a different consequence than a broken monitor in an administrative office. Sentinel Response was designed around that difference.

It is the operational backbone of Sentinel Admin™. Tickets flow through it. Work is documented in it. Audit trails live in it. Reports and dashboards run on it. There is no Sentinel Admin engagement without Sentinel Response. Every tier of the offering includes it at no incremental cost and no per-user license. Sentinel Response was designed by Jason Floyd and produced by Sentinel, which means it was built for this industry from the first line of code. It is not a commercial off-the-shelf ticketing platform with a million configurations the agency has to learn. It is purpose-built for public safety technology administration, and it works because the people who designed it have lived inside the kind of work it has to support.

A public safety ticketing system has to know the difference between CAD, RMS, Mobile, JMS, evidence, radio, reporting, provisioning, configuration, vendor escalation, and operational support. It has to capture priority in a way that reflects mission impact. It has to preserve audit trail. It has to produce leadership reporting. It has to survive turnover. It has to let a small agency operate with the visibility of a much larger organization.

Sentinel Response gives agencies standardized intake, status tracking, audit trails, reports, dashboards, quarterly visibility, ticket volume, average resolution time, work-type breakdown, vendor escalation rate, and completion-against-commitment reporting. That is not a help desk wrapper. That is governance infrastructure.

The ticket is not paperwork. The ticket is the agency's memory.

Why The Ticketing Layer Matters For Budget Defense

The IT director who walks into a council meeting with no data is already behind.

They can say the system is under-supported. They can say the vendors are slow. They can say staff are frustrated. They can say more hours are needed. Without data, it sounds like opinion.

Now change the conversation. The IT director walks in with twelve months of Sentinel Response data. Total tickets opened. Tickets by category. CAD issues versus RMS issues versus mobile issues. Average time to resolution. Vendor escalation rate. Recurring defects. Open aging tickets. SLA performance. Work completed by month. Configuration changes made. Hours spent by system. System uptime trends. Critical incidents supported. Documentation created.

That changes the room.

The chief can show the city manager that the technology request is not a wish list. It is tied to operational demand. The sheriff can show the county commission that vendor performance is being measured. The dispatch director can explain why a CAD admin is not “nice to have.” The IT director can show that the department is not asking for more money because staff are complaining, but because the data shows the system requires sustained administrative support.

This matters for grant applications. It matters for insurance conversations. It matters for performance reviews. It matters for budget defense. It matters when council asks, “What are we getting for this monthly service?”

For small agencies, this is the kind of governance they could never justify building internally. Sentinel Response gives them the structure immediately.

The agency that cannot measure its technology support burden cannot defend its technology support budget.

The Cost Case, Laid Out Plainly

We would not overcomplicate the cost argument. The math writes itself when the structure is laid out side by side.

The agency can do its own numbers. A fully loaded $90,000 public-sector position can approach $145,000 annually using BLS state and local compensation ratios. Over ten years, that is roughly $1.45 million before inflation, equipment, training, recruiting, attrition, and pension-specific obligations.

That is still only one person. If the real need is CAD, RMS, mobile, JMS, evidence, radio, reporting, and vendor escalation, the agency is not deciding between one internal FTE and one external partner. It is deciding whether to keep pretending one FTE can cover a bench.

The internal FTE looks cheaper until the agency admits it still does not have the bench.

Why This Matters Even More For Small Agencies

Small agencies are where this problem is most acute.

A large metropolitan agency may have some internal bench. Not enough, but some. It may have a CAD team, a records systems team, a radio shop, a cybersecurity team, and a dedicated IT director. A small agency has one person. Sometimes that person is the IT manager. Sometimes it is a sergeant who knows the software. Sometimes it is the dispatch supervisor. Sometimes it is the city IT generalist who also supports finance, parks, public works, email, body cameras, and council chambers.

Small agencies do not have economies of scale. They do not have compensation flexibility. They do not have deep applicant pools. They cannot usually justify one full-time CAD admin, one RMS admin, one evidence admin, and one radio specialist. They still carry the same operational consequences when the systems fail.

That is the unfair part.

A small agency's CAD outage is still a CAD outage. A small agency's RMS data integrity problem can still affect a prosecution. A small agency's evidence workflow failure can still create discovery risk. A small agency's radio configuration mistake can still affect field safety. A small agency's CJIS issue can still become an audit finding.

The public examples are sobering. The Los Angeles County Sheriff's Department, the nation's largest sheriff's department, had an antiquated CAD system become inoperable after a New Year's Eve crash, forcing deputies into self-dispatch and manual station-level tracking while radio and 911 lines remained operational. If a major agency can be pushed into manual fallback by a CAD issue, smaller agencies should not assume they are protected by being simpler.

San Jose's CAD implementation review is another cautionary example. The civil grand jury found morale was adversely affected by inadequate user training, implementation problems, and functionality shortcomings. Portland's RegJIN experience similarly shows the cost of systems that burden users. Reporting described agencies leaving the system and users complaining about inefficiency and report-writing burden.

Those are not all the same failure. They are not all administration failures. They all point to the same truth. Public safety technology does not manage itself, and the cost of weak ownership appears in operations long before it appears in a budget report.

Sentinel Admin's Mainstreet™ model was built for exactly this reality. Shared regional administrators. Remote tiers. No need to hire. Sentinel Response™ included. Workload visible through one system. The smallest agency can engage Sentinel at a fraction of the cost of one internal FTE and immediately receive the kind of operational governance, ticketing infrastructure, and cross-system practitioner support that larger agencies pay millions to build.

Small agencies usually think they cannot afford a practitioner bench. The harder truth is that they are the agencies least able to absorb the cost of not having one.

The Position Of This Article

The public safety technology bench problem is not a recruiting problem. Recruiting is only where the problem becomes visible.

The actual problem is structural. The systems are too specialized. The hiring cycles are too slow. The compensation gap is too wide. The vendor model is too fragmented. The knowledge loss is too severe. The operational consequences are too high.

Agencies have tried to solve this with headcount. They have tried to solve it with vendor hours. They have tried to solve it by giving the work to someone who already has a full-time job. None of those models fully solve the problem because none of them change the structure.

The structure has to change.

The agency that tries to hire its way out of this problem will still be hiring five years from now. The agency that builds the bench differently will be operating. Vendor admins answer through the product. Practitioner admins answer through the operation. That distinction decides every problem that crosses a system boundary.

Sentinel governs the technology administration. We never sell the platforms. Independent. Practitioner-led. Vendor-neutral. Built by founders who have led the work, staffed with practitioners mentored by those same founders, operated as a small firm where every agency has the backing of the whole bench. While the phases move, Sentinel stays.

If you are an agency that has spent the last twelve months trying to fill a public safety technology position and is no closer to having the bench you actually need, this is the structural alternative. If you are an agency where vendor admin tickets sit open for weeks because no one owns the seam between systems, this is the structural alternative. If you are an agency where the dispatch supervisor has stopped reporting issues because the workaround has become permanent, this is the structural alternative.

The answer to the public safety technology bench problem is not headcount. It is a bench built differently. That is the bench Sentinel exists to provide, and it is the bench the work has always required.