Key Man Theory, heard of it?

Sometime in the past decades I read about a management idea called the "Key Man Theory". Of course, I can't recall where and when, but it stuck in my brain ever since. In essence, it states that if the success of your business operation or project is heavily dependent on one person, with unique knowledge or skills, you have a huge risk to mitigate. In less sensitive times someone might ask "what happens to us if Dick (or Jane) walk out of the office and get hit by a bus? are we screwed?". The nicer way of saying it now is "what happens if Dick/Jane win the lottery?". Either way, the risk is the same; things could go bad quickly.

This in the same idea as the financial product called key person insurance, but that may not be what you want to fall back on. It is good to avoid poverty if your business fails, but what if you love your business and want to actually save it? In this case the mitigation techniques are to reduce your dependence on the key man (OK, person) by looking to hire similar people, or start some knowledge transfer from Dick and Jane to other people in the organization. Dick/Jane may not be thrilled with this --- being the key person certainly gives leverage when asking for more money or other things --- but you have to do something about this situation; being empathetic and supportive of the key person will help. In the end, when they do leave/retire, they will have felt valued and may have enjoyed passing on their knowledge to the younger folk..


 So, I was drafting some thoughts on another post to come, which refers to the theory.  I thought I would make use of web searches to find some source info or references to use and, to my surprise, my searches found nothing... nada.  So question for everyone: do you remember 'Key Man Theory'? And if so, do you know what happened to it?

What to do when you see bad methods...

... and can't convince people of it.

I have had this experience a few times, and I have thought long and hard about writing about it.I still don't want to get into details, the old "if you can't say something good..." situation. But the possibility of it happening starts with joining a project already underway and the methods have already been chosen. When I first see something troublesome, I might nicely say something like "this is a bit different, how did come to be used?" The worst answer is "that's how we have always done it", and I really have to shut my mouth before reflexively responding "and how's that been working for ya?" ala Dr Phil.

I won't jump ship because of this (new ships not always passing by), so I make the effort. The real problem comes when you see that using the bad method(s) will make you produce bad or late deliverables. The worst response in this case is "Work harder, Work overtime, etc" because that is what always has happened, so it is seen as the norm for doing projects. Even if what you do eventually produce results in buggy systems and missing functionality, so that the change log balloons, that is also seen as the norm.

My personal problem is that I know it does not have to be this way, so it is tough to continue working to the 'norm'. If you are lucky, some project goes so awry enough that 'lessons learned' are considered; that's when you might have chance to suggest improvements.If not, I start considering my options for moving to a (hopefully) better situation. This could be within the organization if it is big enough, but leaving the org might be what is needed in order to join a better environment.

Anyone want to offer their similar experiences as comments?