[/>] ESSAY · Jul 2026 · 5 min read

From 60+ days to ~2: rebuilding compliance review at an enterprise bank.

The review cycle was slow because the system gave reviewers too much ambiguity. I rebuilt the paths, the library, and the operating rhythm until compliance work became easier to trust.

$ A 60+ day compliance review does not feel broken at first. It feels normal. Everyone has a reason for the delay. Legal has risk to manage. Compliance has standards to protect. Marketing has deadlines. Advisors have local business to win. Each person is doing the sensible thing from their seat.

That was the trap inside the social selling program I took over at First Horizon Bank. The problem looked like speed. The deeper problem was trust. A post could sit because the reviewer did not know where it came from. A stakeholder could hesitate because the approval path was unclear. An advisor could give up because the next step felt invisible.

I was managing a program that had to serve Mortgage, Wealth, and Commercial Banking. That meant 350+ advisors, a 500+ post library, 11,000+ advisor posts, and a channel that had to be useful without becoming a risk surface. The easy answer would have been to push harder for faster reviews. That would have made the queue louder. It would not have made the system better.

Therefore I started with the shape of the work. Which content should be reused? Which posts needed a new review? Which assets already had approved language? Which stakeholders needed to see what, and when? The program needed fewer judgment calls in the middle of the process.

The old pattern made each request feel more original than it needed to be. A recruiting post, an educational post, a product post, and a brand post all came with different stakes, but the workflow treated too much of the work as fresh from zero. That meant reviewers had to spend their attention figuring out context before they could judge risk.

So I centralized the content library. Educational, product, recruiting, and brand assets moved into a shared base that people could use again. I documented SOPs so the path was visible. I created clearer review routes with Legal and Compliance. I added a reporting rhythm so the program had a pulse outside of emergencies.

I also had to make the system useful for the people who were not living inside it every day. Advisors needed content they could use without studying the back office. Business stakeholders needed enough reporting to understand whether the channel was working. Compliance partners needed fewer surprises. A good operating system has to respect all of those views at the same time.

The biggest change was not a tool change. It was removing mystery. Reviewers could see why something existed. Advisors could see what was already approved. Business partners could see the program as a governed channel, not a loose collection of posts. Once the work had a shape, speed followed.

The review cycle went from 60+ days to roughly 2. Adoption tripled during my tenure. The program supported 350+ active advisors and 11K+ posts. It also became easier to explain to people outside the daily work, which mattered almost as much as the speed. A system people cannot explain will always feel risky.

The 500+ post library mattered because reuse changed the economics of attention. If every post needs a full new debate, the program will always feel expensive to run. If the library holds approved patterns, reviewers can spend more time on exceptions and less time re-litigating safe ground.

The reporting cadence mattered for the same reason. Without a cadence, every update becomes a special request. With a cadence, stakeholders know when they will see performance, what the numbers mean, and where the program needs a decision. That rhythm lowers the emotional load around the work.

I learned that compliance friction is often a design signal. If people keep slowing down, they may be telling you the workflow is asking them to trust too much. The fix is not pressure. It is structure: named owners, known paths, reusable assets, and fewer places where someone has to guess.

That lesson carried into my AI work. A model can write a draft quickly, but a team still has to trust the path around it. Who reviewed the output? Which source did it use? What rule did it follow? Where does the human step in? The questions change, but the operating problem is familiar.

This is why I care less about isolated output and more about the path around the output. In a regulated environment, a clever draft is only useful if the next person knows what to do with it. The same is true in AI systems. If a team cannot inspect the source, rules, owner, and handoff, adoption will stall even when the demo looks strong.

The work was never only about cutting days out of a queue. It was about building a system where speed had something to stand on.