Introduction
Last week I interviewed “Boris” (not his real name) about his and his company’s handling of the pending retirement of senior IT staff who are important to the maintenance and operation of a number of his company’s business-critical mainframe legacy systems.
Initially I was interested in learning whether Boris thought that modern social networking and collaboration tools might be useful in documenting and transferring the specialised expertise staff needed for maintaining critical systems. Instead, the discussion took a different direction and revealed some underlying issues that go beyond technology enabled knowledge sharing.
Discussion
One of the first things Boris told me was the need to be sensitive to potential “age discrimination” issues.
As is true with many other large insurance and financial companies, Boris’ current employer has been created through a mix of mergers and acquisitions. Along with this many IT staff have been “let go” as companies and departments have been consolidated. Those who remain, especially senior managers who have settled into maintenance and support roles (that infrequently require significant technology or knowledge upgrades given the stability and maturity of the systems) are potentially sensitive to any action taken by management that would appear to make it easier to “let them go” before they reach retirement age.
There is therefore some sensitivity, especially among corporate HR staff, that encouragement by management of special programs for documenting technology and practices might be viewed by some as an attempt to hasten the day when their services might no longer be needed. (The legal issue here is called “constructive discharge.”)
In such a situation, whether the company uses new “social software” techniques or older document-oriented “knowledge management” tools is irrelevant. If the employee out of fear is afraid for his or her job, the end result might be unwillingness to collaborate with knowledge extraction techniques.
Boris emphasizes that this issue not his main concern. “My problem is not that my 55 year old staff members are reluctant to document their systems using blogs or wikis, my problem is that I don’t even have enough 55 year old people around to document the systems!”
This is when we started talking about two kinds of outsourcing. The first is the outsourcing to India of the automatic documentation of older systems. The resulting documentation and modeling, automatically created and reviewed by disciplined, trained programmers, can be generated and brought back to the company to be managed and updated by the senior staff who are maintaining the system. In fact, Boris described a project where that is being done right now. “A good byproduct of this process,” Boris explained, “is that segments of dead code that were never called upon by any software routines can be identified.”
The second type of outsourcing is the actual development, maintenance, and support of legacy code. Skills in Cobol, Assembler, and other classic languages are becoming scarcer, and going offshore is becoming an increasingly viable — and necessary — option.
The manager who isn’t already concerned about how to handle losing his best programmers or developers, explained Boris, is just not doing his or her job and shouldn’t be waiting to see what happens when Baby Boomers retire to figure out how to address the lack of needed skills.
Comments and Conclusions
My initial interest in this topic was stimulated by the question of whether social networking and collaboration tools such as blogs and wikis might be useful to help bridge the gap between retirees leaving a company with knowledge that needs to be shared before they leave.
What I’m discovering in my research is, not surprisingly, that the use of Web 2.0 tools in general, and the sharing of knowledge and expertise in particular, are not “slam dunk” additions to a company’s management and communications arsenal. Whether or not you agree with the sentiment that some senior employees might explicitly resist sharing their knowledge, the fact is that with some companies this could be a concern. And at least in one case I have documented here, one company’s solution to a lack of documentation (based at least partly on the lack of cooperation of some of its staff) is to go outside the company to India to obtain support.
Now, if you’re like me, you realize that one model of professional performance in a corporate environment, especially in an environment that ostensible relies heavily on “knowledge workers” as does IT, is that constant learning and the “network effects” created by sharing knowledge and expertise are — or should be — both personally and corporately valuable. Yet we see in Boris’ situation a perhaps all-too-common example of what happens when staff are more concerned with stability and fiefdoms than with growing, developing, and supporting the company.
Some companies may have little choice but to put up with such behavior. Yet such behavior, viewed from the outside, is inevitably counterproductive since it reduces competitiveness, increases costs, and prevents corporate agility.
This is a much bigger issue than whether or not a company adopts enterprise web 2.0 techniques. It goes to the core of how we align the self interest of employees with the needs of a competitive organization. Ironically, the collaboration and social networking tools that enable the rapid sharing of knowledge — and the rapid improvements that can support — can be viewed by some as threatening. How extensive this is I don’t know but I do intend to do more research along these lines.
- Dennis D. McDonald, Ph.D. is a technology management consultant located in Alexandria, Virginia. Contact him via email at ddmcd@yahoo.com.
I asked “Boris” to review the above interview writeup and comments. Here is his response:
Nice job and interesting comments by Luis [see “reader comments” below this note - Dennis]. The legal theory here is probably not as big an issue as the fact that if systems developers never had a tradition of sharing information IN WRITING, they aren’t going to start now. And many systems developed in the 70s and 80s did not have strong documentation traditions since disk storage was expensive and word processing tools were generally a private preserve of word processing centers that were focused on the business itself (proposals, strategies, policy and procedure manuals, etc.) and not on IT. Thus, if you were originally hired, not for your communications skills, but for your programming skills, quite predictably you aren’t likely to have developed superior communications skills in the following 25 years.
Luis notes that this is a management problem and, quite possibly, a cultural problem. He is correct. Management must select staff and develop frameworks that are designed to promote communication. In our company, this is the case for staff who have 10 years of business experience and are using Java. It is ALSO the case for the staff that are recruited to firms in India. While they may not speak an English dialect that we can understand comfortably, if you spend any time at all with them, you will see that they communicate a lot in both verbal and written form. And the methods of CMM Level 5 require that there be written work products and extensive peer reviews of code. In fact, peer review is judged to be the least expensive, highest value software quality improvement program you can implement.
