Apparently, I built an AI team that needed fewer meetings.
I’ve been building an AI operating environment for JPJ Impact, with defined roles, clear responsibilities and approval boundaries. Then accepting a completed monthly close turned into dozens of record updates and repeated verification.
The numbers balanced. The process still had plenty to do.
I noticed my usage allowance decline during the session. I haven’t isolated what drove that decline or measured savings from the changes we made. But it raised a familiar leadership question: how much of this activity still helps the business?
Consider this fictional situation.
A service manager needs a replacement part to get a customer’s equipment running. The supplier is approved. Purchasing has confirmed the part is right. The expense is within her budget and authority.
The order still needs her director’s signature.
That requirement was added after an expensive rush order went wrong. It made sense at the time. Now every rush order waits for the director, including decisions managers are already authorized to make.
At the weekly meeting, the director asks why the customer is still waiting.
“We’re waiting for your approval.”
“Is there something here she can’t decide?”
Nobody identifies one.
The team keeps the compatibility check and spending limits. For the next few orders, the director will review exceptions rather than sign every request.
The next order moves while the director is in a customer meeting. The manager makes the decision she already had authority to make. They will watch for errors and unnecessary freight costs before making the change permanent.
The team hadn’t needed another reminder to move faster. It needed to stop asking permission twice.
The story’s leadership problem is the one I encountered in my own system: each requirement had a purpose, but nobody was examining the combined burden.
In Article 01, I argued that AI’s value depends on how an organization brings people, technology, information and decisions together. Leaders shape those conditions. They cannot mandate adaptive capability into existence.
That responsibility includes revisiting the architecture they have already built.
A practical decision test is retain, simplify or remove:
Retain the requirement when it protects a necessary obligation, material risk or decision. In the story, compatibility and spending limits still matter.
Simplify the requirement when its purpose remains valid but the same protection can be achieved with less repetition. The director still needs visibility into unusual orders; reviewing exceptions focuses attention where it can change a decision.
Remove the requirement when its purpose has expired or another mechanism already provides the necessary protection. The director’s signature duplicates authority the manager already holds.
The leader accountable for the whole outcome must own that conversation. Control owners understand what can go wrong. People doing the work understand where the burden falls. Neither perspective is sufficient alone.
In our AI environment, we simplified routine acceptance while retaining deeper review for consequential decisions. The next real tasks will tell us how well that change works.
Removing process is one way to create room for people to learn and respond. Some situations require stronger coordination or new safeguards. The test is whether the operating design supports sound decisions as conditions change.
Take one decision your team struggled to make this week. Follow it through every check, approval and report.
What did each step protect? Where was the same decision made twice? Who has the authority to change the whole path?
