Somebody Has to Go First

The same four obstacles show up in agency after agency, and 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 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.

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.

One person can supply the clarity leadership did not. Where everyone else is still trading opinions, a working example settles the argument, and whoever builds it has also volunteered to own the first attempt, which is the risk nobody else wants. An open-ended governance worry becomes a single page that lets the team start safely. The barriers are the outline of a role the organization needs and has not filled.

Becoming that person takes moving 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. That might be the first draft of a grant report or 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.

Move two: become the person with the working example

The confidence gap closes through demonstration. 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 move adoption. People learn from a concrete thing that works.

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 move. That might be hours saved on a recurring report, or days cut from a permit turnaround. 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 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 gets a human review before it leaves the building, and 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 a translator, which is something an organization rarely has and badly needs. 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 true. That position does not fade when the novelty wears off.

It also compounds. If the budget and the formal mandate arrive in a later cycle, 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.

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 means is 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.

The strongest objection is that this asks one person to carry a risk the organization has already decided not to take, and that objection is largely right. Where a records request or a briefing note carries legal exposure, owning the first mistake is not a small thing to volunteer for, and a procurement rule or a records officer can overrule any amount of individual initiative. The four moves are built to keep that exposure small, and they hold only while it stays small. The claim would be wrong if the agencies that adopted well turn out to have done it through budget and mandate, with no early volunteer anywhere in the story. That is a checkable question.

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.

If nobody in your agency picks up that task this quarter, the four barriers stay where they are, and the next person who asks about AI gets the same answer about the policy being drafted.