City of Stephenville, Texas

Technical debt, risk and public trust, from the first two months on the job

After three decades in higher-education technology, I moved into municipal government expecting the technical challenges to feel familiar. They do. Inherited environments carry configurations that made sense to someone years ago. Patching covers most systems, but not all. Some equipment is old enough to fail at inconvenient times.

What changed was the reach. A university serves a defined population that arrives, enrolls and leaves. A city serves everyone permanently and residents do not sort you by department. My wife and I recently brought a meal to an elderly widow who lives alone. Before we sat down, she asked me to explain her water bill, because I work for the city and there was finally someone from the city in her living room.

I had to tell her the billing is handled by an outside service. She wanted to know, reasonably, why the city needs an IT department at all. The answer begins with a principle that reaches past water billing: outsourcing a system does not outsource the city's responsibility for its data, security, continuity or the resident's experience. That took two hours and it was the most useful conversation I have had here. She was not being difficult. She was asking what her money buys and she was owed an answer she could follow.

At the university, speed and resiliency drove most of the conversation. Here in the Cowboy Capital of the World, the first questions are about security, visibility and cost and they come from people who answer to voters.

“The public should feel the reliability. Leadership should see the debt.”

I have held this job for about two months. What follows is not a retrospective. It is the working approach I have arrived at so far.

Begin with visibility

My first step was not a purchase order. It was a reliable picture of systems, ownership, support, licensing, dependencies, age and recovery expectations, built by talking to the people who use them every day. A diagram cannot tell you which manual workaround has quietly become essential or which recurring problem eats hours of staff time.

Unseen technical debt is dangerous. Once it is written down, it can be evaluated instead of feared. The changes that matter are moving from surprise to intention.

Spreadsheets failed me early. They could list a server. They could not tell me why a system that looked current was one expired contract away from becoming an emergency. I replaced them with an internal wiki that now holds more than 650 pages. Each page is meant to answer four questions: who owns it, how it is configured, why it exists and what we do if it fails.

Prioritize by mission and risk

We cannot address every weakness at once. I use a simple order: public safety first, then financial integrity and utility operations, records and regulatory obligations, then everything else.

The question that belongs in front of leaders is operational, not technical. What happens to the public if this system is unavailable, compromised or inaccurate? That separates an inconvenience from an unacceptable risk.

Replace projects with a program

Modernization fails when it is treated as isolated purchases. Replacing an obsolete server solves today's problem, but without a lifecycle plan the same crisis returns in a few years. The work needs a cadence tied to the budget cycle rather than to whatever breaks next. I have vendors quoting a five-year PC replacement cycle, twenty percent of the fleet each year, with room to pull life-safety equipment forward when it cannot wait. That is a budget line instead of a surprise.

The plan provides a defensible baseline. City officials do not need model numbers. They need service impact, risk, cost and timing. When those four things are on the table, budgeting becomes a policy discussion rather than an emergency request.

When our city manager told me, "You're the expert, do what needs to be done," I understood I was in a different world. Several layers of bureaucracy I had grown accustomed to simply do not exist here. That is freedom and exposure. The buck stops at my desk. If the justification lives only in my head, the city has accepted a risk it cannot see.

Protect institutional memory

Small teams carry a particular risk: too much knowledge lives in too few heads. Documentation and cross-training are continuity controls, not administrative chores. A city should keep operating through turnover, illness or incident without depending on one person recalling every configuration and workaround.

Security belongs in the same category. It is identity management, timely patching, tested backups, least-privilege access and monitoring, maintained rather than completed. I will not promise nothing will go wrong. I will work to make the city harder to disrupt and faster to recover.

Keep the public at the center

IT is invisible at its best. I have been preaching that for decades. Nobody thinks about us when everything simply works. A request is filed, a crew is dispatched, a payment posts and nobody has to know which backup or which late-night patch made it possible.

That invisibility is not the same as hiding. Council and the city manager must see the risk clearly enough to fund the work before the outage. The public should feel the reliability. Leadership should see the debt. Those are not contradictory goals.

Modernization is not a ribbon-cutting. It is measured by whether the organization becomes more reliable, secure and sustainable over time. That is the mission: building systems the public can depend on and doing the work so well that most people never have to notice.