In brief
- Institutional knowledge retention is a challenge in the financial industry, as critical knowledge often resides in the minds of a few key employees, risking loss upon turnover.
- Common approaches to addressing this issue include maintaining documentation, proper code commenting, training programs, and succession planning. However, these approaches require constant effort and can diminish over time due to lack of focus.
- An effective solution involves leveraging external IT service providers who specialize in knowledge retention and transfer. These providers focus on learning and documenting client processes, updating knowledge bases, training new staff, and providing proper documentation as part of their core competencies. This helps financial firms mitigate knowledge retention risks and focus on their core strengths.
The problem: Knowledge retention
If you are an IT manager at a financial firm, you may have seen this situation. You’ve got a 20-year-old app, it’s business-critical, and the documentation is somewhere between hopelessly outdated and non-existent. You have 1 or 2 employees who have been around for a long time and who know everything about the app, but if they left, you and the business you support would be completely stuck. Sound familiar?
This is an example of the problem of institutional knowledge retention. An enormous store of intellectual capital resides only in the heads of key employees, and when there is staff turnover, this knowledge can be lost with potentially serious consequences for your business. In the current environment, with the Great Resignation accelerating attrition combined with ever-increasing regulatory scrutiny of operational risk, how can you hedge your exposure to knowledge retention risk?
The usual answer: Fix it yourself
There are several common approaches:
Maintain documentation, perhaps in an internal knowledge base or wiki
Ensure that code is properly commented and has a full complement of test cases
Establish training programs for new joiners, including mentoring by the most experienced employees to spread the knowledge
Define succession plans, not just for key workers, but for the key elements of their knowledge
These are all worthwhile practices. Documentation and training should certainly be encouraged. The problem is that they take constant effort to maintain and big companies tend to have short attention spans. There may be a burst of enthusiasm among management to implement knowledge retention plans, but after a while (and perhaps after a change in management) they wind down and wither away. The institutional knowledge of what it takes to maintain institutional knowledge is itself vulnerable to deterioration and loss.
A further factor is that at a financial firm, there are typically no employees whose job function is to be a custodian of institutional knowledge, or a guardian of good knowledge transmission. Documentation isn’t part of anyone’s KPIs — it's just overhead. There may be experts, but they see any key-man dependency as job security. We are probably all familiar with cases of key people who were let go, only to be brought back as expensive consultants once it became clear that their knowledge was never properly transferred to others. And managers always have more pressing concerns until they panic when a key person leaves the firm. There is no one with a real incentive to invest the required (and substantial) effort in the day-to-day maintenance of institutional knowledge.
A better approach: Get some help
What to do? If there is no one in the firm with the right incentive, it stands to reason that one may have to look outside the firm. I have seen this in my own experience. When I worked at big banks, nobody wanted to document the business-critical legacy apps, least of all the few real expert developers. There was always more interesting work to be done. What really changed things at one major global bank where I worked, was when we brought in an IT service provider (Luxoft) to take over the backlog of maintenance and small enhancements for a suite of front-office trading and risk-analytics applications. At first glance, you might think that turning over an app from an internal team to a service provider involves a total loss of institutional knowledge. But in fact, the opposite turned out to be the case. Let me explain why.
At a good IT service provider like Luxoft, knowledge retention and knowledge transfer are core competencies. These firms know that they don’t know the internal processes of their clients, so they make it their business to learn and document these processes up front. Service providers are also used to staff moving flexibly between projects at a client, so they don’t allow themselves to develop key-man dependencies, which are the greatest source of knowledge-retention risk. They commit themselves to constantly updating their knowledge bases, and constantly training new joiners to do the work of more experienced mentors. And they do this because it’s their job; it’s what they get paid for. If the contract is drawn up correctly, it’s part of their KPIs and SLAs. In particular, creating and updating proper documentation, including the results of extensive interviews with the incumbent experts, is a major deliverable of the initiation phase of any proper managed-service engagement.
I saw the same thing at another tier-one bank, in this case, from the other side of the table as a Luxoft consultant. We were brought in to look at industrializing a business-critical desk dev app, components of which were no longer vendor-supported. There were key experts who ran the system but no documentation to speak of. So the first thing we did, before anyone proposed to write a line of code, was to bring in a small team of senior consultants to spend a couple of months interviewing the experts and then writing up a proper BRD, both for the current state and for the desired future state. And that BRD ended up being a valuable deliverable itself, in terms of hedging against the loss of institutional knowledge, even when the business decision was made not to replace the legacy app after all.
If we look at this like economists, the question of who should manage knowledge risk is really about comparative advantage. Financial services firms are good at financial services. Most of them would like to be good at financial technology as well, since they see technology as a key differentiator. But knowledge management is not a core competency of financial services firms (neither is technology recruitment but that’s a separate topic). By hiring a professional IT service provider like Luxoft, the financial firm can effectively swap its institutional knowledge risk to a third party, for whom it is a core competency, and who therefore has a comparative advantage in managing such risk. That can be profitable all around. It can also make your employees happier as they get to concentrate on strategic projects, doing what really drives profitability at your firm.
Next steps
So if you are the hypothetical manager of that undocumented 20-year-old business-critical app, and if you are getting a bit worried about your risks, please feel free to contact me. I’d love to partner with you and to talk with you about how Luxoft and I can transform your knowledge retention risk into an opportunity for improved IT service, while letting you focus on your core competencies and the business you really care about.
If you’d like to find out more visit luxoft.com/capital-markets or consult one of our experts at financialservices@luxoft.com.
Jonathan Kastin
Jonathan Kastin has been working in financial technology for 16 years, with a focus on managing change programs in market risk and credit risk, delivering value through transparent access to high-quality data and analytics. In his role as Director, Technical Sales and Advisory at Luxoft, Jonathan partners with senior decision makers at leading financial institutions, bringing the best of Luxoft’s technology offerings to meet business needs. He holds a master’s degree in philosophy, and he enjoys using his background teaching college philosophy to take a big-picture approach to solving business problems.
