The Graying of IT

A recent story in Baseline Magazine discusses what CIOs at various companies are doing to retain institutional knowledge in the face of retiring IT workers.  One example, FirstEnergy Corp:

As its first baby boomers turn 60 next year, FirstEnergy Corp., a $12.5 billion utility in Akron, Ohio, will transfer the insight and knowledge of its long-timers to younger recruits.

The company plans to hire up to 75 new technology workers over three years. The gray-hairs will mentor incoming technologists for stints of a few months to two years.

The transfer of brainpower comes as FirstEnergy brings on 3,000 new employees companywide. They will ultimately replace the 23% of its workforce that is expected to retire by the end of 2007.

"We can't afford not to do this," says chief information officer Brad Tobin.

The good news is that solving this problem has benefits beyond just making sure you don't lose knowledge to retiring workers.  You may also gain deeper insight into your products and services in the process. 

A few weeks ago, I heard a former Novell employee describe the meetings that occurred after Novell bought USL (Unix Systems Labs) from AT&T.   He recalled sitting through several days of meetings where everyone was talking about "clients" and "servers."  What he realized later was that the Novell people though of servers as big computers and clients as smaller computers that used them while the USL people were thinking of clients and servers as peer processes.  They thought they were communicating, but in fact were talking past each other. That kind of misunderstanding about the common words and phrases in your business is one of the core reasons you lose institutional knowledge when whole cohorts of workers are replaced. 

In an essay I wrote called Your Company's Leaking Knowledge, I talk about how a process for managing nomenclature can be used to retain important corporate knowledge and build a foundation for creating products.  While I wrote about the problem primarily from the standpoint of products, the methodology for creating nomenclature is largely the same:

1. Get everyone with a stake to start talking.
2. Build strawman models for reference and to give people something concrete to argue for or against.
3. Get everyone using common words and phrases and discussing them to ensure they mean the same thing to everyone
   
4. Write whitepapers to cement the models and nomenclature in place
   
5. Repeat as necessary
   

I've been going through this process with a company I consult with and I can testify that it's not only messy, but can engender considerable passion.  Don't ignore the passion or try to sweep disagreements under the rug.  The whole point of this process is to work through those and come to a common understanding.