Ask just about any financial institution what their technology priorities are these days, and you’re bound to find “modernization” on that list.
Often this means upgrading infrastructure, such as migrating from on-prem to off-prem Software-as-a-Service (SaaS) platforms. This could also mean shifting to modern development methodologies such as agile. Each of these are worthy of their own articles. [Editor’s note: on it!]
But tech modernization requires the organization to evolve as well.
To deliver advanced technologies at a cheaper cost via modern methodologies, you need to have a modern operating model within the Technology group that can truly help the business transform.
Below are three recommendations that CIOs should keep in mind as they modernize their delivery models.
1. Use Products as Domains
We have a soft spot for Business Architects. They like to create dense maps of all the domains and capabilities and processes in an organization, and these maps tend to be logical things of beauty.
There are even companies dedicated to mapping the financial services universe for you. Which are really cool… until you actually try to apply them to your situation.
These maps do have their purpose. Their beauty shines when it comes to organizing the work your organization does (including your technology groups). But for the most part, one should not model an organization based on them.
DO organize around your business: value chains, product portfolios, individual products, or key business capabilities that support the business strategy.
DO NOT organize around a technology asset, like a website or mobile app or database. Doing the former helps keep you focused on the end customer, whereas the latter risks keeping customers another layer removed.
2. Stop Pooling all your Engineering Resources
The adoption of “platforms” across tech organizations has been quite the rage the past several years. But rage is an appropriate word when product owners realize their needs are now competing against those of every other product in the company.
See, with this adoption of platform models, companies have begun pooling all their engineering capacity by platform, or even across platforms into broader “Practices.” The intent is to ensure that precious resources are only working on the most important things to the company.
There’s a point, however, where that doesn’t pay off.
The optimization gains from pooling your engineering resources can become outweighed by an imbalance of priorities. In other words, the big fish will always get the worm.
CIOs need to find a balance in these pool sizes, leaving room for flexibility to allow for the smaller fish to thrive.
Platforms are an important concept as long as you treat them as enablers for the business. They deserve the attention …but not at the sacrifice of delivering value to your customers.
3. Fund Products, not Projects
Better balance can also be achieved by restructuring how you fund work.
Historically, organizations plan on an annual basis – aligning a set amount of funding against a set number of projects and teams to staff up (or down) to that funding level. In other words, you “fund projects.”
When the business priorities change during the year (because it’s not “if”), most organizations do not have the radar and budgetary processes in place to smoothly re-align funding to new priorities. In fact, they will often execute projects that no longer reflect the reality of business needs because either the “teams are already working” or there is no simple way to re-allocate to the next priority.
An agile methodology suggests you fund persistent teams that are typically product-oriented, with a defined backlog and priorities that are constantly reviewed, or “groomed,” thereby assuring the highest business priority features are being worked.
Said more simply, you fund products, not projects.
Each year you may fund a specific product more or less, depending on where you believe your strategic investments have the greatest ROI. By aligning your funding model with these Agile principles, you better guarantee teams are working on the highest priority efforts, not just those that looked good 6 months earlier.
(Oh, and this gets you out of your annual IT budget hell.)
Bonus Considerations
A few other items to keep an eye on:
- Leverage “Horizontal” groups as the glue. If you right-size your engineering pools, and if you organize around your product domains, it is even more crucial to have elements in the delivery model that stitch everything together. Having certain disciplines like User Experience Design as a horizontal practice can ensure delivery is consistent across products. And for practitioners of SAFe, the Architecture Runway is another “horizontal” that will keep you pointed in the right direction.
- Move away from a culture of “Firefighting.” Some companies really love this notion of “event storming,” where teams form quickly, swarming to solve problems. But too often it becomes a crutch – or worse, an unwelcome distraction that derails priorities and limits the teams’ depth of subject matter expertise. Instead, solve what is driving all that firefighting in the first place.
- Don’t Sacrifice Scale for Speed. It’s exciting to be agile, slinging code to get products out quickly, but have your development shop invest in knowledge management. Creating a knowledge repository for discoverability of all code (a catalog so everyone can see it) and reusability (so no one has to recreate code) allows for the organization to scale and ultimately increases speed of delivery by reducing potential rework.
There’s much more to the modernization journey for delivery organizations. And as any good CIO knows, the evolution never stops.
Additional contributors to this article: Michael Kleinberg, Michaux Raine, Anthony Klick, and Jeff Catalina.
Further Advisory helps large institutions by objectively evaluating their tech delivery models and identifying opportunities to gain scale and speed, all with a bias toward execution and a heavy dose of pragmatism. From organizational design to product delivery, we make strategy become a reality.
