A working process can be frustrating and still contain things worth protecting. I approach that tension carefully: a leadership team may want less manual work without losing the checks, relationships, and operating knowledge that keep the business dependable. The decision isn't simply whether to add AI. It's how much of the surrounding operation actually needs to change.
My background includes rebuilding day-to-day processes and aligning departments as a chief operating officer. That experience informs a distinction I make in AI work: improving a process doesn't automatically require replacing the system around it.
I favor a narrower approach when the business supports it. Preserve what earns its place, change a defined part of the work, and judge the result before expanding.
Preserve the function, not every familiar step
I don't take “no rip-and-replace” to mean leaving everything untouched. Familiarity isn't evidence that a process works. But inconvenience alone isn't evidence that it should disappear.
Before changing a workflow, I separate its useful functions from the effort required to carry them out. I want to understand what protects accuracy, who has authority to make a decision, where responsibility changes hands, and which records people depend on.
Those functions may deserve to stay even when the mechanics change. My aim isn't to preserve every click or handoff. It's to avoid removing an operating safeguard just because it looks like administrative friction.
That distinction gives the leadership team a more useful scope: the work to simplify, the controls to retain, and the decisions that remain with people.
Give the change a clear boundary
I prefer to define a limited change rather than announce a broad AI rollout. A useful boundary makes clear where the work begins, what information is permitted, what output is expected, and who reviews it before it moves forward.
I also want a clear answer about which existing system remains the official record. If people have to reconcile competing versions of the same work, a seemingly helpful addition may create another layer of administration.
Within that boundary, I keep accountability explicit. I analyze the business, with AI assisting the analysis. The same principle applies to implementation: the people responsible for the work remain responsible for judging whether an output is suitable for use.
I wouldn't force this approach where it doesn't fit. If a limited addition requires extensive changes elsewhere, I'd reconsider its scope rather than describe it as a small improvement.
Count the work that remains
I don't judge an AI-assisted workflow only by how quickly someone can produce an output. I include preparation, review, correction, recordkeeping, and the effort required to keep the process running.
That broader view matters because economics can change, but the change has to survive the full cost of use. A shorter production step may not be worthwhile if it creates more checking or shifts unresolved work to another department.
Before implementation, I define what would make the change worth keeping. Depending on the business need, that may involve capacity, quality, cost, or a capability the current process doesn't provide. I also define what would justify stopping. Continuing shouldn't be the default merely because work has begun.
Make adoption part of the operating design
I treat adoption as more than instruction on a new tool. People need to understand what changes in their responsibilities, what stays the same, and when they should set the AI-assisted step aside.
I want the people doing the work involved in reviewing that design. Their knowledge of exceptions and dependencies matters when deciding whether a proposed change is practical.
Where feasible, I retain a usable fallback while the change is evaluated. That isn't an argument for maintaining duplicate processes indefinitely. It's a way to avoid making the operation dependent on an approach before there is enough evidence to support that decision.
Expand only when the evidence supports it
I see a limited implementation as a decision point, not an automatic first installment of a larger rollout. I compare the result with the original purpose and examine what happened to the surrounding work.
If the change holds up, I can consider a broader scope. If it adds complexity without enough value, I would narrow it, revise it, or recommend stopping.
No rip-and-replace is a discipline about scope, not resistance to change. I want each expansion to earn its place — without treating what already works as expendable.