Managing risks to institutional knowledge

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.