What $100B+ in Lending Transformations Taught Me About Sequencing

Add up every lending transformation I've been part of over 26 years, and the total crosses $100 billion in loan operations — including a single $85 billion institution at the upper end, and community banks and credit unions with a fraction of that footprint at the other.

When people hear that number, they usually ask about scale: what's different about running a transformation that large? It's a reasonable question, and it's the wrong one. The lesson that stuck with me across two decades of this work was never about size. It was about sequencing.

The institutions that got the most out of their lending transformation — at any size — didn't move faster than everyone else. They moved in the right order. The ones that struggled almost always did the same work, just out of sequence, and paid for it later at a much higher cost.

Why Sequencing Beats Speed

At any meaningful scale, a lending transformation isn't one project. It's dozens of interdependent workstreams touching credit, operations, compliance, IT, and frontline staff at the same time. Every one of those workstreams reacts to a workflow change — and if the change lands on a foundation that isn't ready for it, the reaction is rework, not progress.

Institutions under pressure to show momentum often default to moving on every front at once: configure the platform, train the staff, and clean up the data all in parallel, because parallel feels faster. It rarely is. Configuration built on unresolved data assumptions gets rebuilt. Staff trained on a workflow that changes again two weeks later stop trusting the training. The appearance of speed early in the project becomes the source of the delay later in it.

The Three-Phase Framework

Across engagements of every size, the sequence that consistently works breaks into three phases — and each one has to be substantially resolved before the next one begins.

Phase 1: Governance and Data Standards

Before a single screen gets configured, the institution needs agreement on how data is defined, owned, and governed — chart of accounts logic, exception handling rules, who has authority to approve a workflow exception, and what "clean" actually means for the records moving into the new system. This phase is the least visible and the most skipped, because it produces no demo-able progress. It's also the phase that determines whether everything built afterward holds up.

Phase 2: Core and LOS Configuration

Only once governance and data standards are settled does configuration start. This is where the platform gets built to match how the institution actually operates — not how it operated five workarounds ago. Configuration done on a stable data foundation goes fast, because the team isn't re-litigating definitions mid-build. Configuration done ahead of that foundation goes fast at first and slow later, when the rework starts.

Phase 3: Staff Enablement

Training comes last, and it comes once, on a system that isn't going to meaningfully change under the trainee's feet. Enablement done early, against a configuration still in flux, produces staff who quietly build their own workarounds to cope with what they were taught not matching what they see. Those workarounds are exactly what the transformation was supposed to eliminate — and they're far harder to unwind once people have grown to rely on them.

What Happens When You Skip a Step

Skipping a phase doesn't save the time it looks like it saves. It moves the same work to a later, more expensive point in the project — usually day 91, the stretch right after go-live once the deployment energy wears off and the real operational questions start surfacing.

By day 91, a data problem isn't a data problem anymore. It's a trust problem: a report that won't reconcile, a workflow that behaves differently than staff expected, an exception nobody can explain. Fixing it now means unwinding decisions that are already live, already trained on, and already load-bearing for daily operations. The same fix that would have taken a week in Phase 1 can take a quarter once it's been built on top of.

This Isn't a Scale Problem

Community banks and credit unions don't run $85 billion transformations. But the sequencing principle doesn't change with size — it just compounds faster when it's ignored, because smaller institutions have less staff redundancy to absorb the rework and less time before the next audit or exam cycle arrives.

The order of operations matters just as much at $500 million as it does at $85 billion. The only thing that changes with scale is how loudly the consequences announce themselves when the order gets skipped.

Building the Sequence Into Your Own Transformation

A few principles carry across every engagement, regardless of institution size:

• Resolve governance before you configure. If your team can't yet agree on what "clean data" means for a given field, that's a Phase 1 conversation, not a Phase 2 workaround.
• Don't demo progress you'll have to rebuild. Configuration that looks finished but sits on an unstable data foundation isn't ahead of schedule — it's debt with a delayed due date.
• Train once, on something stable. If your configuration is still changing, your training calendar is premature.
• Plan for day 91 from day one. Build a review checkpoint roughly three months post-go-live specifically to catch what only shows up under real operating conditions.
• Give each phase an owner, not just a deadline. Sequencing breaks down fastest when everyone is accountable for the timeline and no one is accountable for the order.

None of this is a case against moving quickly. It's a case for moving in order. The $100 billion figure is just an accumulation of engagements — the discipline underneath it is the same whether the institution is managing $500 million in loan operations or $85 billion.

Get the sequence right, and scale becomes a matter of degree, not difficulty.

Marvin Tellez — Founder, Advanedge Consulting

Marvin is a fintech strategy leader with 26 years inside financial institutions and deep operator-level experience across the Abrigo/Sageworks ecosystem — including LOS implementation, Jack Henry integration, and AI-enabled lending operations. Based in Dallas-Fort Worth, he helps community banks and credit unions get the most out of their lending technology nationwide.