Twelve months after NorthRiver Bank acquired BrightPay, a fast‑growing fintech, the celebration banners were gone. Internally, people had started calling it “the merger that never landed.”
On paper, the deal made sense. NorthRiver brought capital, licenses, and a broad customer base. BrightPay brought a modern payments platform. They also provided a product team that could ship in weeks instead of years. The investor deck promised “accelerated digital growth” and “seamless omni‑channel experiences.”
Reality was different. Two parallel hierarchies kept running in competition. BrightPay’s engineers were still pushing releases from their own pipeline. At the same time, the bank’s IT insisted every change go through legacy governance. Journeys that were supposed to be “integrated” now had even more handovers. There were relationship managers at NorthRiver, risk at headquarters, product owners at BrightPay, plus at least three steering committees. No one could say who actually owned “digital SME Onboarding.”
Customers felt it first. Time to open a digital business account crept from five days to twelve. Contact‑center complaints about “stuck applications” doubled. Two senior BrightPay product leads left within six months, taking key knowledge with them.
Everyone had an explanation. “Tech is the blocker.” “Compliance is too rigid.” “They don’t understand our culture.” What they did not have was a shared way to see the system. They lacked focus on a few critical flows. No one had clear authority to fix them.
That is when the AO team was called in. They received a brief that sounded simple. Yet, it seemed impossible. “We have to show real integration results in the next two quarters. We must do this without breaking the bank or the fintech.”
1. AO diagnosis: seeing the stuck system
The AO work started with a fast, visual diagnostic rather than another slide‑deck TOM.
- Mapped three priority value streams:
- Digital SME Onboarding
- Consumer current‑account opening
- Instant payments incidents.
- Drew real sociograms around each stream. These sociograms show who actually talks to whom when something moves or gets stuck. This is not the org chart.
- Surfaced “strangled swarms”: informal cross-org groups trying to fix issues. They have no mandate, no budget, and no clear decision rights.
Three patterns emerged:
- Fragmented ownership
- At least four groups claimed they “owned” digital SME Onboarding (retail banking, SME business, BrightPay product, central IT).
- None had authority across process, technology, and policy for the end‑to‑end journey.
- Outcomes (time‑to‑open, NPS, churn) had no single accountable group.
- Waterfall PMI overlay on top of complex work
- The integration office ran dozens of workstreams (IT, HR, Risk, Products), each with its own plan and RAG status.
- No cross‑functional group owned a specific customer journey or a synergy hypothesis.
- Steering committees saw slides about “integration progress,” but not how real customer cases moved through the merged system.
- Culture as a blind spot, not a design input
- Bank leaders talked about “synergies” and “best‑of‑both,” but BrightPay teams experienced a slow absorption into legacy ways of working.
- Bank teams felt overrun by “cowboys” pushing changes fast; fintech engineers felt trapped in endless approvals.
- Culture differences appeared as blame, instead of being used as design material for complementary strengths.
AO interpretation
AO framed this not as “bad people” but as a system that made local optimization rational and end‑to‑end value impossible.
- The system rewarded local optimization (protecting functions, minimizing risk) more than shared outcomes.
- Informal cross‑org problem‑solving groups existed but were “strangled swarms”: no mandate, no budget, no clear decision rights.
- The Target Operating Model existed mainly as a slide‑deck. It did not exist as living agreements about who owns what. It also did not define how decisions are made.
2. AO intervention: swarms and two‑speed TOM
Instead of redesigning the whole organization, AO proposed a minimal evolutionary Target Operating Model anchored on a few high‑value swarms.
2.1 Swarm the value, not the org chart
For the first wave, AO helped leaders choose two integration themes:
- Integrated “Digital SME Onboarding”
- Unified mobile current account experience.
For each theme, AO set up a cross‑functional swarm:
- Members from: BrightPay product & engineering, NorthRiver IT, SME business, risk/compliance, operations, and customer support.
- One clearly named outcome (e.g. “Median SME Onboarding time ≤ 5 days with NPS +20”).
- Explicit decision rights for this slice: they could change process steps, UI copy, and routing rules. They could also modify some policy constraints within guardrails.
- 6–8 week integration sprints, each producing a working change in production, not just a design.
AO introduced Swarm‑4 style habits. These include short hypothesis cycles, visible backlog, and Plexus‑like governance. As a result, funding decisions followed evidence from swarm experiments.
2.2 Two‑speed TOM
AO resisted pressure to “fully harmonize” everything at once.
- High‑volume, regulated core (e.g. deposit accounting, AML monitoring) stayed on the bank’s slower but stable processes for now.
- Customer‑facing digital journeys were moved into AO swarms with a mandate to experiment, even if it meant temporary dual processes.
This two‑speed TOM shifted the question from “When will we be fully integrated?” to “Which flows need integrated behavior now, and how can we evolve the rest safely?”
2.3 Culture in the room
AO designed explicit integration ceremonies:
- Monthly “customer walk” reviews occurred. Bank and fintech leaders followed real cases through the system. They heard directly from frontline staff.
- Swarm retros that included both HR and risk, making culture and policy trade‑offs discussable, not invisible constraints.
Instead of generic culture workshops, culture was handled as part of everyday decisions. These decisions included how much risk to accept for faster Onboarding. They also involved deciding what service tone to use. Additionally, there were considerations on how to handle fallback when the fintech platform failed.
3. Outcomes and AO‑style metrics
Within two swarm cycles (around 3–4 months), the bank‑fintech system started to behave differently.
Quantitative shifts:
- Median SME digital Onboarding time dropped from 12 days to 6, with a clear path to 5 days.
- “Where is my application?” contact‑center calls for SME Onboarding fell by ~30% in swarm‑covered segments.
- Decision lead‑time for key integration choices (e.g. product variants, UI changes) shrank from 6–8 weeks of committee ping‑pong to under 10 days for the swarm’s scope.
Qualitative shifts:
- BrightPay engineers reported “having a real product again” rather than “just being an integration project.”
- Bank business leaders described “finally seeing the same picture” when talking about journeys and constraints.
- Attrition stabilized in the integrated areas. A few who had considered leaving decided to stay. They changed their minds once they saw the swarms’ mandate was real.
AO encouraged the organization to track a small, stable metric set for each swarm:
- Time‑to‑value (from idea to production change affecting customers)
- Decision latency on cross‑org items
- Defect / incident rate on the integrated journey
- Engagement / retention of key roles inside swarms.
Menschgeist 
Leave a comment