Somebody Has to Go First

Strip away the surface explanations and the same four obstacles show up in agency after agency. They are worth naming plainly, because each one points to its own answer.

The first is ownership fear. When a vendor builds a system and it fails, you can hold the vendor responsible. When you build something yourself and it fails, the mistake has your name on it. So the safe move is to wait for someone else to prove it first, which means nobody volunteers to go early, which means the win never gets claimed either. Fear of owning the loss quietly becomes fear of owning the result at all.

The second is a confidence gap, and it is easy to mistake for resistance. Most people are not refusing to change. They simply have not been shown how to write a usable prompt, how to check whether an answer is right, or where the safe edges of the tool are. Someone who tries once, gets a confident-sounding answer that turns out to be wrong, and has no way to catch it, learns the wrong lesson. They decide the technology is unreliable, when what was missing was the training to use it well.

The third is vagueness at both ends. Leadership says the team needs to be more efficient and should use AI, without defining what efficiency would even look like or which task it applies to. Meanwhile the tools themselves are a blank page, and a blank page is the hardest possible place to start. There is no baseline, no target, and no obvious first step, so the instruction floats above the work without ever landing on it.

The fourth is governance as a stall. The concerns here are real. Security, public records, and data retention all deserve care in a public institution. But a year-long policy effort can become a reason to do nothing in the meantime, and "we need to write the policy first" turns a legitimate guardrail into a locked door. Money sits underneath all of this. It is the reason given when the deeper reason is fear, and it is the easiest objection to raise because no one can argue with a tight budget.

Here is the part most people miss. Not one of those four barriers is a problem with the technology, and that is the good news, because technology problems are expensive and slow to solve. These problems are different. They are waiting for a person.

A person can supply clarity where leadership was vague. A person can demonstrate a working example where everyone else is still trading opinions. A person can volunteer to own the first attempt so that no one else has to carry the risk of going early. A person can turn an open-ended governance worry into a single page that lets the team start safely. The barriers are not walls. They are the exact outline of a role the organization needs and has not filled.

Becoming that person is less about being the most technical individual in the building and more about being the one who moves first with a little structure. The work that follows breaks into four moves, one for each barrier. You can begin any of them this month, with no authority beyond your own desk.

Move one: pick one ugly task and make it the proof

Ownership fear shrinks when the stakes shrink. Do not propose an AI strategy, and do not ask for permission to transform anything. Quietly take one painful, low-glamour task that already belongs to you, where a mistake costs almost nothing and the time saved is obvious. The first draft of a grant report. The summary that goes on top of a long council packet. The initial triage of a records request. Run it through the tool, check the output yourself, and keep the result. You now own a small, real win instead of a large, theoretical policy, and a win you can point to is worth more than any pitch.

Move two: become the person with the working example

The confidence gap closes through demonstration, not argument. Build two or three workflows that reliably do something useful, write them down in plain language, and show a colleague how to check the result for themselves so they are not trusting it blind. The moment you can hand someone a prompt that works and a way to verify what it returns, you have become the source of the practical examples the whole organization was missing. This is the same instinct behind the training models that actually move adoption: people learn from a concrete thing that works, not from a webinar about possibility.

Move three: define the metric leadership could not

When the instruction is "be more efficient," the most valuable thing you can do is translate it into one number you can actually move. Hours saved on a recurring report. Days cut from a permit or inquiry turnaround. The time it takes to respond to an investor lead. Name the baseline before you start, so the improvement is real rather than asserted. You convert a vague pressure into a scoreboard, and you become the person holding it. If you want a structured way to find that number, a readiness assessment can surface where the time is actually going.

Move four: turn the policy stall into a one-page guardrail

You do not need to wait for the year-long policy, and you are not the person who will write it. What you can write is a single page. What data never goes into an outside tool. What always gets a human review before it leaves the building. How outputs get recorded so they hold up under public-records and retention rules. Hand that page to whoever owns risk. You have reframed governance from a reason to wait into the thing that lets everyone begin safely, and your name is on the document that did it.

The person who runs those four moves becomes something an organization rarely has and badly needs: a translator. You end up sitting between leadership's pressure to modernize, the staff's quiet anxiety about getting it wrong, and the vendors circling the building with promises nobody can evaluate. You are the one who can tell each of them what is actually true. That position does not fade when the novelty wears off.

It also compounds. The budget and the formal mandate usually arrive eventually, and when they do, the organization already knows who has been running this in practice. The early, unglamorous work of going first is what makes you the obvious choice to lead the larger effort. This is the same dynamic we wrote about in the case for not waiting on a slow employer: the people who move while others hesitate are the ones who define how the institution works next.

And the skill underneath all of it is judgment, which is the part of this work that does not get automated. Knowing which task to start with, whether an output can be trusted, and what the number you are moving actually means is exactly the capability that grows more valuable as the tools get better. Going first is how you build that judgment before anyone else in the building has it.

These barriers do not dissolve on their own. In every organization, someone decides whether they are permanent, and most of the time that decision gets made by default because no one steps up to make it any other way. You can be the exception without permission and without a budget. Pick the one task you would start with, the small ugly job where a mistake costs nothing and the time saved is plain, and run it this week. That is the entire beginning.

The field is entering a stretch where the agencies that adopt well will pull ahead of the ones that keep waiting for certainty. The difference between those two groups will not be their budgets or their tools. It will be whether someone inside each one was willing to go first.