Managing Change as a Paradox
Large scale business change is a cultural paradox, not an exercise of breaking resistance to change through political means; Plus how The Software Shift is playing out in Fintech
There is a change management paradox at the heart of large business transformations due to an inherent tension between "new future" expectations and "status quo" instincts.
I have been part of many transformations. From my observation, everyone involved is aware of the expectations of the new future. But how entrenched the instincts of the status quo can be is always surprising.
The needed equilibrium for progress is unique to every organization’s culture and values. It can’t be achieved through rules or processes copied from elsewhere. It requires adjusting the cultural norms so that the right balance is drawn across both sides of the paradox.
For example, what mistakes can be allowed when you are asking teams to experiment to innovate? Are you just communicating guardrails to keep, e.g., regulatory compliance risks or some business-critical risks? Or are you asking them to follow detailed and rigid policies that have no degree of freedom?
A few other examples of accounting for the whole paradox include investing in processes and infrastructure that maximize development flow:
Are the teams equipped to work in small batches to produce short-term results?
Are they empowered to constrain the work in process (WIP) to manage the long-term focus?
Is there a good infrastructure to deliver high-quality production software at a low cost?
A successful transformation has to be more than just breaking the resistance of those who don't want to move from the "status quo".
It should be about managing the whole paradox, i.e., addressing contradictions between the "new future" and the "status quo".
The Software Shift: Consumer Tech and Banks
The concept of “Becoming a Software Company (BASC)” is anchored on a business where non-software companies have to build and launch consumer-facing software solutions.
FinTech is one of the domains where this convergence is playing out very actively.
Case in point: a consortium of banks, including JPMorgan Chase, Bank of America, Wells Fargo, and others, recently launched Zelle to compete with peer-to-peer payment apps like Venmo.
While Zelle can be counted as a reasonable success, the consortium’s play (dubbed Paze) to compete against mobile wallets like Apple Pay has run into delay and regulator scrutiny. (Link1, Link2)
The consortium’s playbook is a violation of The Value Principle from BASC. By just assuming that consumers need another app, these banks are missing an opportunity to understand how they can really help their customers to make progress.
If customers are happy using Apple Pay, banks don’t need to build another competing app. That is a painful lesson Chase learned when there were no takers for Chase Pay after launch.
Instead, they could consider enabling easy connectivity to their banking infrastructure so that developers can create better and different customer experiences. That a company like Stripe has created a developer platform for internet payments is a telltale sign of the value that can be created by enabling developers
Secondly, it is interesting that the consortium decided to involve merchants and card issuers only a few months before the planned launch. That is a violation of The Complexity Principle from BASC. The phasing they are considering now should have been part of the approach from the beginning, i.e., building in small batches and mitigating some complexity with every batch.
Compare and contrast with Apple’s approach. They have focused their efforts on their secret sauce, building the best possible user experience with Apple Pay. They are happy to partner with Goldman Sachs on providing the banking infrastructure.
From these examples, it is obvious that a software company is doing a stellar job at becoming a bank, but the banks are struggling to become software companies.