In brief: Start with one operating outcome. Identify where work stalls, clarify ownership and reliable inputs, make room for a bounded test, and review whether AI improves the whole workflow.
A leadership team agrees that AI should help the organization work better.
The promise is appealing: less time assembling information, faster first drafts, and more room for work that requires judgment. Someone identifies a tool. A few people begin experimenting.
Then come the questions.
Which information should the tool use? Who checks its output? Who decides whether a recommendation becomes action? Where does the team record what worked?
Those questions deserve as much attention as the technology.
For leaders of small, mission-driven organizations, a useful place to begin is the work surrounding the tool: how priorities are set, decisions are made, responsibilities are assigned, and experience becomes shared learning.
Consider an illustrative example. A nonprofit wants to shorten the time it takes to prepare funding proposals. Its team decides to test AI-assisted drafting.
But preparing the draft is only one part of the work. Program staff need to confirm what the organization can deliver. Finance needs to validate the budget. Someone needs to decide whether the opportunity fits current priorities. A leader needs to approve the commitments.
A faster draft could still spend days waiting for those decisions. It could also create extra work if it contains commitments the team has not agreed to make.
The useful question is where the delay actually occurs. If drafting is the constraint, an AI tool may be worth testing. If the delay comes from conflicting priorities or unclear approval authority, the test needs to address those conditions too.
That distinction changes what an AI initiative is designed to accomplish.
Start with one outcome the organization wants to improve. In the proposal example, that might be submitting a sound, strategically relevant application on time without making commitments the team cannot meet.
Then examine the whole path to that outcome. Where does work wait? Where does information become unreliable? Which decisions are repeatedly reopened? Who has to compensate when the process breaks down?
This gives the team a basis for choosing an intervention and judging whether it helped.
It also creates a more useful conversation about ownership. A person can be responsible for operating an AI tool while someone else remains accountable for the decision it informs. Both roles need to be explicit.
For the proposal team, that might mean one person prepares the draft, program and finance owners validate their sections, and a named leader decides whether to proceed. The team also needs a way to raise concerns when the proposed work exceeds its capacity.
Those arrangements can be lightweight. Their value comes from making the next action clear.
Shared information deserves the same attention. Before introducing AI into a workflow, identify which sources the team should rely on and who is responsible for keeping them current.
In the illustrative proposal process, that could mean agreed descriptions of services, current budget assumptions, and a record of commitments already made. Conflicting source material creates a question for the organization to resolve. A polished draft should not conceal it.
The next consideration is capacity. Learning a new workflow, checking outputs, correcting errors, and discussing results all take time.
For a small team, a responsible test therefore includes a decision about what will receive less attention while the test runs. Adding an improvement initiative to an already full workload can leave people without the time needed to assess it properly.
Keep the experiment bounded: one recurring task, one owner, a small set of approved inputs, and a review date. Agree in advance on what would justify continuing, changing, or stopping.
The review should look beyond whether people used the tool.
Did the work reach its destination sooner? Was it accurate enough for its purpose? Did checking and correction create additional work elsewhere? Did the people accountable for the outcome have better information when they needed it?
Record the answers and the decision that follows. If the test exposes an unclear approval step, change that step. If it shows that the tool performs poorly on the task, reconsider its use. If it helps under specific conditions, make those conditions visible to the next person doing the work.
This is how an individual experiment can become something the organization learns from.
At Chase Pack, this way of examining work informs the development of Cadence: an organizational operating system designed around understanding what limits performance, choosing a responsible next step, and learning from what happens.
The starting point is the leader’s operating problem. Technology belongs in the response when it fits that problem and the organization has the capacity to use it responsibly.
An organization does not need to perfect every process before experimenting with AI. It does need enough structure around an experiment to know who owns it, what evidence matters, and how the results will affect the next decision.
Before your next AI initiative, choose one recurring workflow. Ask the people involved to identify where it stalls, who can resolve that delay, and what evidence would show improvement.
Then decide what role AI should play.
The ambition is a team that can make progress, recognize what it is learning, and carry that learning into the next round of work.