You are your Institutional Knowledge

In the midst of recession, many companies are closing locations and laying off staff to cut costs.  The thinking from many of these companies is that the remaining staff can pick up any projects the laid-off staff previously did, resulting in all the important work being accomplished.  Secondary tasks may end up being done a bit less frequently, and any extra can get picked up by contractors, who don't entail the same hire/fire burden. 

There are some flaws in this thinking for anything with real complexity, and these flaws all relate to institutional knowledge. 

First, it assumes that the remaining staff knows what is important.  In reality, today's workers are often so siloed they don't have any idea what the person two cubes over is doing.  Lay off a few people, and entire critical infrastructure applications may be forgotten-until they stop working, to the confusion of the remaining staff.  Also likely- remaining staff will know of the existence of such applications, but most likely won't know where such apps sit, or how they work.  It's hard to prioritize importance when you don't have the basic facts.

Second, it assumes unfamiliar applications are not overly burdensome to learn, even when the previous maintainers are no longer present.  The truth is that many existing applications were built over many years using fragile programming techniques, and then went through a maintenance period that resulted in counterintuitive, self-contradicting, hard-to-follow, even misleading code.  These issues may not have been  issues for the previous maintainers because they were so familiar with it that they knew all the common problems, and how to handle them. I think of the old Dodge Caravan I drove around in college-not fuel injected, so I knew to press the gas when I started. The hydraulics in the rear door were broken too, so I knew to keep my head down, and I kept a hockey stick in the back to prop it up. I also knew to use premium fuel or it would start knocking like crazy. but I knew about these issues, had workarounds, and was largely unaffected.

(This one was not mine, but mine was very similar save for being white with fake wood) However,  had I lent the car out to a friend without this info, my friend may not have even been able to start it, and later probably would have ended up getting smacked in the head with the rear door, and then wondered if they broke the thing after filling up with regular gas and hearing extra knocking.  These problems take only a few minutes to understand; unfortunately, learning all the subtleties of a large, complex codebase can take months or even longer, even with the guidance of someone with experience.

Sure, with time, the important applications will be discovered and eventually learned, but what happens in the meantime?  What if the important app is customer-facing?  What if it runs your business's billing?  Can you live without this app for days while your staff  takes baby steps learning the most basic elements of an app, trying to figure out why it's non-functional?  Can you live with new and different critical errors happening repeatedly, as staff learns the idiosyncracies of the app the hard way?  Or, can you live without any work of substance being done on a critical app for an extended period of time for fear of encountering the issues mentioned above?  This is what happens with the loss of institutional knowledge.  If you can't afford these kinds of problems, you might reconsider the nature of your business... regardless the stated goal of the company or any products it might sell, reliance on knowledge means your business, IS, to some level, the institutional knowledge of the people that make it up, and losing that knowledge could be tantamount to losing the business. Tread carefully.

EDIT: A related concept I really wanted to mention is the idea of the Truck Factor, i.e. "The number of people on your team who have to be hit with a truck before the project is in serious trouble"  Anytime you lay off people who have specialized knowledge, you're lowering your truck factor... if you lower it down to 1, particularly on a stressful project, you're potentially in real trouble.. even if that person isn't hit by a truck, there's a good chance he/she will leave when the economy recovers.

Posted 08-27-2009 10:38 PM by Anne Epstein
Filed under: ,



Brett Powell wrote re: You are your Institutional Knowledge
on 08-29-2009 12:59 PM

Let me start by stating that we are not laying anyone off but regardless of this I only partly agree with this post.

Firstly regardless of LIFO policies we all know that companies lay off their weakest. This is a critical part of the process of ensuring that companies emerge from the recession stronger. Call it pruning. What happens during the boom times is that we employ staff under pressure, standards slip a bit and weaker staff are retained. During a recession these people are pruned. Painfull yes, wastefull no. essential I believe so.

Anne Epstein wrote re: You are your Institutional Knowledge
on 08-29-2009 2:47 PM


Certainly, companies tend to lay off their weakest when pressed, and this drive to discover and not tolerate those who are zero, or even negatively-producing is, if anything, perhaps a positive of a recession.  I may not have been clear, but my goal was to stress that institutional knowledge is sometimes a *completely  orthogonal* concern.  Making cross-training a high priority, verifying that critical knowledge is spread throughout many staff members and kept up-to-date can protect against the consequences of losing any one team member, or even any one team, but that's not the story at many, many companies.  Perhaps skill *should* be the key factor in the tough decision on retaining staff, but it may be that absorbing the work of the incompetent who nevertheless is the only guy who has any idea how your homegrown billing system works may be a LOT tougher... If that's the case, perhaps mitigating that risk should be a priority so institutional knowledge is less of a risk factor.

BlogCoward wrote Institutional Knowledge
on 08-29-2009 8:26 PM

Institutional Knowledge

Erica Janine wrote re: You are your Institutional Knowledge
on 10-08-2009 1:41 PM

I do not agree with the comment above. Companies generally lay off their weakest employees, true, when it can be determined. In more technical environments, the ability to even determine who is technically stronger or weaker is really not there in favor of appearance of importance. The very fact so many silo situations exist in big companies today goes to illustrate it is impossible to determine who knows what they should because the projects/items being worked *are* so specialized. In healthy technical or software-oriented groups, cross-training and common development is the norm, not the exception.

In big companies whose primary industry is not technology (i.e. most corporations), silos exist because software is NOT the focus. In this scenario, it is likely that only the most invisible (not necessarily the weakest) or most disliked employees are let go.

Sarita wrote re: You are your Institutional Knowledge
on 10-21-2009 3:47 PM

Like many companies, mine has gone through layoffs; however I see the lay-off trend continue within the same organizations.  For sure a benefit of the recession is to lose sub-par performers, but belts continue to tighten so the differentiating line between who stays and goes and why has gotten a lot blurrier.  Sometimes it's financial, sometimes it's arbitrary and sometimes it's combining 2 positions into 1.  

Institutional knowledge therefore becomes even more critical in the current environment, particularly when it comes to the daily operations.  Day 1 through Day 30 - what do you do and where do you get the information if your "go-to" person is gone?  Technology certainly plays a key role here.  My firm has invested heavily in electronic repositories and required documentation so we aren't left in a lurch if the go-to person didn't leave a good audit trail.  Technology helps BUT IT"S NOT ENOUGH!  If you operate in a high touch environment, service delivery WILL suffer despite efficiencies gained through technology.  If you're client facing, internal or external, It takes time to transfer knowledge from your predecessor and do it effectively.  Care has to be put if one is to make a seamless transition but if there's a lack of investment in this effort, how is one setup for success?  Not spending enough time to answer this question is what I'm seeing in today's market.

link building wrote re: You are your Institutional Knowledge
on 07-18-2014 8:54 AM

DWdAsk Thanks again for the article. Cool.

matzcrorkz wrote re: You are your Institutional Knowledge
on 08-06-2014 6:59 AM

m0wJpg Really appreciate you sharing this article.Thanks Again. Great.

michal benz wrote re: You are your Institutional Knowledge
on 03-03-2015 1:02 AM

WmDhpI Hello my loved one! I want to say that this article is awesome, nice written and come with almost all significant infos. I would like to peer more posts like this .

crork matt wrote re: You are your Institutional Knowledge
on 03-09-2015 11:57 AM

CL4kzi Thanks for the good writeup. It in truth was once a leisure account it. Glance complex to far delivered agreeable from you! By the way, how can we keep up a correspondence?

find a free pron wrote re: You are your Institutional Knowledge
on 10-14-2016 6:34 AM

bQzKqg like to read it afterward my links will too.

Add a Comment

Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)