Innovation at Scale, #7: Will Corona Kill FinTech?
How tech stacks create competitive advantage, and what it means in an era of change
Startups, corporates, and competitive advantage.
One of the key insights of Innovation Consulting for large companies is that startups, not corporates, are the ones with a competitive advantage.
Large organizations have two big disadvantages against smaller companies:
The first big disadvantage is that startups can chase the low end.
The second is that startups can move faster.
“Chasing the low end” is another way to describe the underpinnings of disruption theory. Startups can supply less lucrative customers, and then move upmarket - this is classic disruption. Because startups typically have a leaner cost base, they can go after opportunities that would be unprofitable for the larger organization. Because startups are trying to find their scalable business model, they can pursue markets that the large company would ignore, because those markets would be a rounding error on their existing profits. From here, the startup can expand, using the knowledge gained from the adjacent low-end segments.
Startup speed has been written about in lots of places. The major insight is that startups can build cultures of fast decisionmaking. Fast decisionmaking, when combined with fast access to empirical data, means that startups can build the right things faster. We’ll explore this more in a future post on OODA loops.
There is a third disadvantage though, which is related to the second but we can treat separately. Large companies have legacy code.
Large companies have legacy code
If the second disadvantage is about legacy cultural and organizational code — less responsive decisionmaking practices, hierarchies of approvals, internal politics, annual budget theater — I mean this third one in a very literal sense. Large companies are typically using old software to achieve their aims.
Let’s take the large multinational banks as an example. Because of the way that financial and regulatory infrastructure has been built, most banks are still relying on a tech stack of mainframe computers running COBOL. This was state of the art in 1970, but it creates some problems in the 21st century. It’s harder for banks to ship customer-facing apps iteratively and quickly, because some of these front-end changes may be hampered by the capabilities of their back-end systems.
So… Why do banks still use COBOL? Well, firstly, COBOL has lots of advantages. It is highly stable and reliable, which is important for a bank! The risks of migration to a newer system are also incredibly high: every migration contains significant uncertainty, and a bank’s data risk includes risks to things like your account balances, your credit card balances, and your credit ratings (and that’s just for individuals!). There are some sunk cost concerns as well — every year, banks spend millions on maintaining these systems. Investing in a new infrastructure requires a much larger upfront spend, and implies risks about future reliability as well as unknown ongoing maintenance costs for the new platforms. The benefits to this might be unknown, or minimal over the short term. If you’re considering your balance sheet and the risk/reward profile of a large-scale change, it’s very easy to stick with the status quo.
This COBOL tech stack is just one example; the tech stack for many transactions is primarily paper and pen. Some documents might require hardcopies, signatures or in-person authorizations. This is true in lots of heavily-regulated, often-highly-manual industries. Financial and legal, and government services tend to have these processes — and are most often pre-digitization.
Startups build new codebases
On the other hand, startups are, quite literally, starting from scratch. They can choose the best tools that are state of the art today, and build on those. These systems will usually be fit for purpose for most or all of today’s known use cases. Over time, as customer needs change, new technologies are built that cater to those needs; using old technology often means using technology that is unable to meet a subset of currently known user needs.
Since these startups are not encumbered by already-built systems, they have less worry about breaking something when they do make changes. Because they’re early on in their codebase’s life, it’s likely that someone in the organization knows how everything works. This may not be a single person, but in the aggregate, the organization typically understands the working of its own code. This is a luxury that older organizations using older codebases don’t have.
Many parts of a modern codebase will be components, for which that understanding is effectively outsourced. Surprisingly, this is a strength, for two reasons. Firstly, because the maintenance and improvement of these components can be outsourced to specialists, at lower costs and with a faster pace of improvement. Off-the-shelf components are more reliable and improve more quickly. Secondly, because the institutional knowledge required to build a functional codebase is now much smaller! This means teams can increasingly focus on the areas of their competitive advantage as the underlying components become commoditized.
But what does this have to do with a global pandemic?
The Great Global Work From Home Experiment
For the few weeks, and for the foreseeable future, most knowledge workers across the world will be telecommuting. This has already led to massive changes in our work and social lives. We Live in Zoom Now, as the New York Times put it. The use of new tools — videoconferencing, collaborative document editing, and many more — has expanded dramatically over these last few weeks. Luddites don’t have a choice; people are finding ways to digitize their professional (and social, and academic) lives where they can.
A tweet from Box CEO Aaron Levie highlights the impact of the current situation on “How IT strategies will change overnight”:
Shifting a workforce to working from home won’t lead to large banks abandoning COBOL for their backend tech stack. It might, however, increase the pace of digitization on front-end services. Maybe law firms, banks, and governments will be more willing to adopt digital signature tools to confirm transactions; they might build dashboard tools for employees where previously they had a paper inbox. Communications will have to change, and maybe document collaboration will move toward digital systems as well. A shift to “extended enterprise” and “UX above all” approaches using “best-of-breed apps” is long overdue in these industries.
A lot of my work focuses on driving the changes that Aaron outlines, but most large companies aren’t adequately set up to undertake them without a larger holistic change program that covers technology, people and culture. What if they were?
The end of the startup advantage?
Generally, the history of progress is one of displacement. Technological progress happens when one technology supplants another. Businesses are replaced by businesses that offer better products and create more value for customers. And as Max Planck (almost) said, “science advances one funeral at a time.” It’s worth asking why this is the case, and whether from an innovation point of view “this time is different.”
The “why,” in Planck’s view, is that
A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it. . . . An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning: another instance of the fact that the future lies with the youth.
I’m most interested in Plank’s “rarely.”
What would it take for a company or group of scientists to wholesale change the ideas that they are attached to?
As the Great Global Work From Home Experiment continues, we’re seeing that some practices need to change, no matter how attached people were to the status quo.
Video calls have replaced coffee meetings, workers need to juggle work and childcare, workers need to access secure data while off-site, amongst many more changes that you’re probably aware of.
So, here’s an interesting question about the long-term effects of the Great Global Work From Home Experiment: If large companies follow Aaron’s advice above, and rebuild their tech stacks to facilitate the current work environment, will they also invest in changing their underlying technologies?
To some degree, this will be required, at least on the front end. If you’re reading this, you’re probably already using Zoom (for work, or at least for socializing), and the odds are good you use Google Docs, or Slack, and/or some other collaboration and communication tools already.
So: will companies adopt these new tools, on the front and/or back end of their tech stack?
And if they do this, does this mean that one source of competitive edge for startups evaporates?
If so, then the real battleground for 21st-century companies will be over culture. How fast can your team make decisions? How fast does your software ship? How empowered are your teams to run with new insights? How distributed is knowledge in your organization? How easy is it to serve new customer segments? Can teams pursue ideas that feel too “small” to move the needle in the short term?
The companies that build the best answers to these questions will be the ones that survive.
Reading List
Each week, I'll include links to articles, books, or podcasts related to corporate innovation, that can help you accelerate the knowledge and progress of your teams.
This week, I’m going to recommend a single short book. Zero to One: Notes on Startups, or How to Build the Future by Peter Thiel and Blake Masters is dense with provocative questions about innovation. Peter’s takes are often controversial, but they are consistently generative — they identify new ideas and challenge orthodoxies in productive ways. I recommend a close reading, and writing some reflections at the end of each chapter: what challenged you to think of something new? What did you disagree with?
A personal note
I’m currently looking for new, interesting projects to explore, and people to meet. I’m especially interested in working with very large companies on building and leading innovation teams, and in helping startups to scale from a nascent Product function to a high-performing larger team. Please don’t hesitate to reach out to discuss either of the above.