Welcome back to The CP Journal, where we break down what it takes to get left of bang.
Somewhere in your organization, someone is repeating a process that was supposed to be a temporary workaround several years ago.
They’re emailing department heads for updated emergency contact lists and chasing the people who never responded.
They are checking training certificates against a spreadsheet they don’t entirely trust and a Microsoft Teams folder of poorly labeled PDFs.
They’re making three phone calls to find out whether the equipment listed in the resource inventory is working and available.
Everyone involved can describe what makes processes like these cumbersome, but fixing them has never quite made it to the top of the priority list, so the workaround just becomes part of the job. And even though that works when the organization is fully staffed and the operating budget is relatively predictable, those same processes become a burden the moment a budget gets cut or a position is left unfilled. They endure within an organization, even though there are fewer people left to carry them out.
This is where the familiar expectation to “do more with less” runs into the reality of how the work gets done. The needs of your community or organization haven’t decreased with your budget, and the time spent keeping these workaround processes running leaves even less time to address those mission-oriented needs.
But some of the problems we’ve learned to tolerate may now have solutions within reach of the people who understand them best. The time, cost, and technical expertise required to build a useful tool are changing and are creating opportunities to improve processes that have gone untouched for years.
In this week’s briefing, I want to explore that opportunity: how people with operational experience can begin building tools for the problems they face, and how developing a few new skills can help us recognize possibilities we might otherwise miss.
The Opportunity
When I think about what has changed, it is not a generic recognition that “AI” is now available. The central change is that someone who understands an operational problem can now participate much more directly in building the solution to it.
Previously, the person who understood a problem had to translate their experience into requirements, find someone with technical expertise, secure funding, and compete for development time. A relatively modest problem could remain unresolved because getting a solution built required more coordination, more time, and a greater expense than anyone could justify.
But AI-assisted development can shorten that path in a few specific ways:
Describing the problem can lead to a working prototype. Someone can explain the inputs, the steps they repeat, and the output they need, then use AI to help write the code.
Trying an idea requires a smaller initial commitment. They can test whether a tool helps with one task before making a case for a larger investment.
The person doing the work can guide revisions directly. Using an early version reveals missing steps, exceptions, and assumptions that would have been difficult to capture in a requirements document.
Technical learning can happen during the project. A person can ask for explanations, troubleshoot errors, and develop enough understanding to make progressively better decisions about what they are building.
This is what enables the opportunity to develop narrow, highly specific tools to solve problems. These are the problems that are too particular to attract a software vendor, may be too small to reach the top of an internal development queue, and yet still consume hours of someone’s time every month.
But because AI is able to shorten this path, it shifts the limiting factor from “solution development” to “problem identification, definition, and evaluation.”
The Required Input: Operational Experience
Recognizing that a process is frustrating (or just dumb) gives you a place to start, but building something better requires understanding what that process is supposed to accomplish, where it breaks down, and what an improvement would make possible. This is where operational experience becomes so valuable.
Consider the emergency manager developing next year’s exercise schedule. A list of plans and their last exercise date provides some useful information, but it doesn’t fully explain what needs to be tested. An exercise might be needed because a recent incident exposed a gap, or staff turnover may have left people unfamiliar with their responsibilities, or a revised plan may include an approach that nobody has practiced. Someone who understands the work and the organization’s goals can explain how those conditions should influence exercise priorities.
Or consider a police commander reviewing staffing for the coming month. A roster may show enough officers assigned to each shift, but court appearances, training, and leave can change who is actually available. The commander has to consider the mix of supervisors, experienced officers, specialized qualifications, and the personalities of each of those officers working together. Their experience helps them recognize which combinations leave a gap and what options exist to address it.
In both cases, a tool could produce something that looks complete while missing what matters operationally. Experience is what helps you recognize those shortcomings and define what the tool needs to account for before you can rely on its results.
This is something we’ve encountered while helping organizations integrate Hazzard into their workflows. Defining what a tool should produce requires understanding the decisions people make, the information they use, and how they evaluate it. Those conversations also create an opportunity to question familiar practices and decide which steps are necessary, which can be improved, and which can be eliminated.
This is why I reject the blanket argument I see online that using AI means giving up critical thinking. Selecting a worthwhile problem, explaining how the work connects to a decision, defining the requirements, and determining whether a solution actually improves the organization all require intensive critical thinking and extreme levels of clarity. While accepting an output without questioning it is a failure of judgment, using AI to build something you can explain, test, and improve requires you to exercise that judgment.
I want experienced people, those closest to the problem, spending less of their day searching through folders, reconciling spreadsheets, and chasing updates. Their attention is valuable, and freeing more of it for the decisions that serve their communities is a goal worth pursuing.
Where to Begin
Start with one recurring task you understand well enough to explain: what information goes into it, what you do with that information, and what you need at the end. Choose something small enough to finish and familiar enough that you can judge whether the result is useful.
Your starting point will depend on your experience, but you might begin by describing the process to an AI tool and asking for help exploring ways to improve it. If you’re already comfortable building a prototype, great. Either way, give yourself a specific problem to work through.
For me, one of those problems was making better use of the work I had already done. Past articles, project documents, and existing internal guidance were spread across files, folders, and platforms, and made any meaningful reference to them sporadic at best. When starting something new, I wanted relevant past work brought to my attention, including material I might not remember to search for. That gave me a concrete purpose for experimenting with AI: making existing knowledge easier to use in the next project.
Your first project could address one step in a spreadsheet you update regularly or help you find missing information before preparing a report. Define what would make that task easier, then try building something that delivers that improvement.
Test it against work you’ve already completed so you can compare the results, identify what it misses, explain the exceptions, and then revise it. I like to ask questions about how it works as you go, so your understanding develops alongside the tool.
But recognize that you don’t need a complete picture of what you could eventually build to get started. Completing a modest project gives you experience that reading about the technology alone won’t provide. As you learn what it takes to make one tool useful, you’ll become better at recognizing other problems worth tackling.
Reversal | Accumulating Complexity
The direction I see is more of the ability to develop solutions moving into the hands of people closest to the problems. As more people begin building tools for their own work, I expect organizations to gain useful capabilities—and encounter new challenges.
The unbundling of cable offers a familiar comparison. Being able to choose what I wanted to watch initially felt like an improvement; over time, those choices have become a collection of subscriptions, separate apps, and costs that now exceed what I had to pay for the bundle. The pursuit of customization has accumulated into something increasingly cumbersome.
I expect a similar tension with custom tools, as several people may build solutions to the same problem. As a result, information may need to be maintained in multiple places, or a tool that saves one person time may create additional work for someone else. Leaders will need to recognize when to combine tools, improve a shared process, or retire something that no longer earns its place.
There will also be challenges when the person who develops a custom tool leaves the organization or transitions to a new role. Who understands how the platform works? Who maintains it? What happens when its creator is no longer involved? A useful personal experiment can become an organizational dependency before anyone has explicitly made that decision.
While I don’t see these challenges as strong enough to stop the trend, I do expect leaders to have to manage them as the ability to develop new tools grows. The same judgment that helps us decide what to build will also be needed to help us decide what to keep.
Conclusion
The next time you find yourself working around a familiar problem, consider whether the reasons you’ve left it alone still apply. The time and technical support needed to improve it may have changed, and your unique understanding of the work gives you a place to begin.
Choose one problem and give yourself room to learn by trying to solve it yourself. You’ll have to explain things you normally do without thinking about, test assumptions, and decide whether what you’ve built actually helps. That experience will also make other possibilities easier to recognize.
Being asked to do more with less is a frustrating experience, but removing even one recurring burden can give you and your team some time back. What you do with that time—preparing, making decisions, and serving the people who depend on you—is the reason to pursue it.
Absolutely nailed it. Ai development is enabling practitioners and operators to be part of the solution development to their hardest problems like never before. Exciting times.