Training is the only enduring link between IS past and IS future. But retraining can be both a threat and a challenge. Find out the obstacles to conducting a productive training program and learn how to avoid them.

Training is not paid leave. It is an investment, and both management and employees have the right to expect a return. In today’s technological environment, in which skills must be constantly refreshed simply to keep from losing ground, training is no option. The fact that so much education falls short of its intended outcome speaks to a lack of understanding of some very powerful issues that surround it. The reality is that periods of training are often pressure-intensive for both managers and their staffs—frightening and exhausting for some, energizing and rewarding for others.

Many AS/400 installations are grappling with one or both of the following training challenges: programmers with S/36 or S/38 experience who learned the AS/400 on the job and therefore have some big holes in their education; or hot-shot programmers with mastery of one or two development tools who have no wider context for the mission of IS, understanding neither business nor systems. Whatever your specific situation, to get the optimal technical benefits from a training investment, it is essential to recognize the personnel issues that can undermine it.

What You Don’t Know Will Get You

Some years ago, I worked for a Silicon Valley telecommunications company that IBM purchased. At the time, it was one of the largest Hewlett-Packard shops west of the Mississippi. We ran 13 HP3000s, the result of exceedingly rapid frontier-style growth and an unchecked propensity for decentralization. The majority of the applications were home- grown, and the cadre of development and support programmers was correspondingly large. Relentless growth had made the operation unruly and, short of becoming an HP3000 emporium, it was clear something had to be done.

With IBM’s ascendancy, it was announced that a 4381 would be installed to replace the baker’s dozen HPs. In the heady world of IBM mainframes, HP3000s were sneered at as next of kin to appliances, and our dirty dozen were clearly an embarrassment to the new management team. They would be retired, top management was promised, and quickly. An aggressive (laughably optimistic in retrospect) migration schedule was devised, and even

the most politically somnolent programmer could see the writing on the computer room wall: Master new programming and operating system skills, or work at a job of diminishing importance until your talents are no longer required.

For the company, its IS managers and employees, programmer training had suddenly become a matter of survival.

Failing to Hear the Silence

Most of the younger programmers were willing to learn the new system. Some of the senior staff members with many years invested in the HP platform were understandably less eager. A good number of key people were flatly resistant. The department was proud and protective of what it had built. Everyone had reservations about the proposed pace and personal impact of the migration, but no one wanted to part with Silicon Valley wages. An uneasy silence descended.

Management mistook the silence for consent and either missed or ignored the resistance. In so doing, they made the training symbolic of the adversarial relationship that was growing between programmers and management. For their part, programmers failed to understand the implications of their resistance: The point at which programmers became resistant to change, they also became a problem to their management. If the resistance persisted, those clinging to it would become a liability.

Management’s focus on what they so urgently wanted to accomplish clouded their understanding of what was already there. They dashed off in the new direction, reluctant to invest additional needed resources in existing systems. The old systems, after all, still ran the company and would for the foreseeable future. But they had lost their glamour, and yesterday’s source of pride now embodied a thankless, dead-end job. As a consequence, not a lot of people were volunteering to stack deck chairs on the slumping HMS Packard. Systems that had previously worked well began to slip. More programmers wanted to jump to the new system than were initially needed, motivated by fear of having their careers stalled by being tethered to a dying system. Rather than exercise patience during the inevitable training curve, management brought in a number of IBMers to speed the migration effort. Although new to the company, they were paid more than the most senior HP people.

Within months, a two-tiered programming organization evolved. On top were programmers, toiling on the 4381 doing the sacred work of development. Below, were HP programmers, relegated to the vulgar task of maintenance. Ill feeling, anxiety, and resentment spread like an infectious flu.

Management had divided its own house and, predictably, it did not stand.

Options Not Taken and Prices Paid

In this scenario, management had two available strategies that could have been implemented with probable success. First, they could have trained everyone simultaneously, bringing them over to the new system as their particular application was being migrated. Equity of training and opportunity would have been assured. Conversely, if some people had to be left behind for budgetary or timing reasons, management was obliged to ensure that they were acknowledged and appreciated, respected and regarded, given adequate resources to do their jobs and, when logical, kept to a salary on par with their IBM counterparts.

Creating a divided workplace was a costly mistake that would have extraordinary ramifications. From the employees’ perspective, the deck was stacked. They felt disrespected and unappreciated, their past efforts on behalf of the company discounted. And their discontent manifested itself in a thousand subtle acts of sabotage. Try as management might, more than three years later, not one single HP system was fully retired. Most of the management team was replaced. Many good people ended up leaving, frustrated by the lack of progress. Shortly thereafter, IBM sold the company, unable to assimilate it.

An extreme case perhaps, but there are many lessons here, not the least of which is that good intentions and $3.25 will buy you a latte, but not a successful training program. The best-intended decisions that affect the lives and careers of others, if made behind closed doors without employee buy-in, will be a tough sell.

Where change is a way of life, constant learning is survival. How managers and programmers approach training today will determine the quality of professional life for all involved tomorrow.

Lessons for Managers

Quickly is not always wisely. This is true on two levels. First, unless you deal with employees’ resistance, they will sabotage—albeit unconsciously—your training effort. Listen for the silence. Those chosen to participate will have issues: “What will you expect of me after I complete the training, and will there be additional support?” Those left behind will have issues: “Will I lose an advancement opportunity if I continue what I’m doing, and will all the good jobs be taken by the time it’s my turn?” There will be dozens of questions. Ask for them. It may all seem trivial in the rush to keep pace with technology, but a little time invested up front acknowledging and answering the concerns of your staff will save a great deal of time dissecting what went wrong later.

Second, it’s true there are a lot of new tools coming our way and it’s getting harder and harder to keep up. But it is better to dissuade users from using systems you are unable to support than to provide them with incomplete or inaccurate information when they need urgent assistance. Credibility is too dearly won to have it risked lightly.

Make training a way of life, not an emergency-response policy. Training should be an ongoing part of an employee-development process, tied to the changing needs of the company. If users introduce new systems to the IS environment, implementation should accommodate sufficient training time for the staff. When that is not possible, ask the user to contract for temporary outside support.

No one wants to be the last kid standing when choosing sides for basketball. For a variety of reasons, training is usually selective. Those who are not offered training may have equity issues. Be sure they understand the reasons behind your training strategy. The goal of training is not to create a department of “haves” and “have nots.” It is to strengthen your team, improving its ability to achieve shared goals.

Honor those who are currently doing the work of keeping the company alive. If a shift to new technology makes a “house divided” inevitable, do not forget those left behind doing the unglamorous but critical work of keeping the house standing. Ensure they have the resources they need to keep doing their jobs. A wise person does not abandon the old house before the new one is completed.

Create safety by banishing ignorance and exclusion. These are the two great enemies of employee morale. People don’t work or learn or retain well when they are frightened. Have frequent meetings updating your progress. Stress that this is a team effort and that the development could not succeed without the effort of those underpinning old systems. Find small ways to reward contributions.

Understand and communicate the strategic importance of the training. If training is viewed as the capricious pursuit of this month’s technological fad, it will have limited appeal. People need to understand how their part impacts the whole. Why is this new skill important? How will it support the end user? The company? Is it compatible with individual career goals?

If users are moving so quickly that the strategic importance of their technological choices cannot be measured, that signals a larger problem: a lack of strategic and tactical direction at upper management levels. When the IS director is unable to set and enforce technological direction, catch-up will be a familiar mode.

Teach the structure of business. Understanding the basic structure and principles of accounting, manufacturing, inventory, marketing, etc. will give programmers a broader

context for the work of supporting a business. Specialization breeds isolation and often limits the usefulness of the end product.

Discover learning modalities. Even under the best of circumstances when everyone is willing and eager to learn, training may fall short of its intended outcome because people are not being taught in ways best suited to their personal learning style. There are three primary learning modalities: auditory, visual, and kinesthetic. Auditory learners do well in the classroom and will “get it” by having someone explain it to them. Visual learners may do well with manuals, flip charts, or computer-based training. Kinesthetic people need hands-on practice and may be confused, for example, by a strict lecture format.

People learn differently, and employees will seldom tell you that the training offered is inadequate for their needs. They will simply learn what they can and try to hide the blind spots in the hope that things will become clearer at some later date. People can be tested to determine their dominant learning modalities, but just ask. Even if they cannot immediately identify their favored learning style, they will undoubtedly know what doesn’t work for them, and you can adjust accordingly.

Train in groups whenever possible. Few people work in splendid isolation, and even if they do, their work impacts others. If they work in teams, have them train in teams or pairs, invested in each other’s success. People will ask much more candid questions of their coworkers than of their managers. The likelihood of admitting confusion to a peer and asking for help is far greater than risking embarrassment by asking a superior.

Make the training measurable. The employees that IBM sends to school are rigorously tested, and the results are sent to their managers. Failing is not an option. Set expectations high; it’s easier to trust when you verify.

Neither remedial nor promotion are concepts that relevantly describe technical training. Companies often frame training in one of these two ways, but neither concept is particularly useful in this context. Remedial implies prior negligence on the part of the programmer. A promotion may be something a programmer achieves after mastering new skills and providing a new level of value to the company. The former devalues the trainee; the latter sets unrealistic expectations. For employees, training is an opportunity; for management to provide it is an expression of esteem.

Lessons for Programmers

Resistance to change will make you a liability. If it’s comfort you seek, you are probably in the wrong job. Change will come as surely as Windows will crash. It’s best to make change a friend. Almost everyone will experience some resistance to leaving the familiar. But a steadfast refusal to grow will shift the way you are perceived from being an asset to being an obstacle. Your manager will have his or her own performance goals to consider and will not be able to carry you indefinitely. If you are genuinely uninterested in the new direction taken by your company, move to a place where your talents are in demand.

Be honest when you need help to do your job. You will know before your manager when you are pushing the limits of your knowledge and need additional training to do your job. It need not be self-serving or self-deprecating to ask for additional training. Managers want to know what you need to do your job successfully. Their success depends on yours.

If the only tool you have is a hammer, after a while, every problem begins to look like a nail. Every problem will have an appropriate tool for its solution. Trying to squeeze every programming project through the cheesecloth of a single development tool is neither elegant nor realistic. The more tools you have in your toolbox, the more fitting and problem-specific the solution.

Motivation is an inside out job. There are times when keeping a job or even a roof over your head seems insufficient reason to keep going. Family and financial obligations certainly play a motivational part, but each individual must be his own impetus. Those with the greatest chance of surviving change will be programmers who are open learners, embracing the fact that, on some level, they are and always will be beginners.

If you are already saturated, admit it. You can’t learn if you’re feeling too overwhelmed to assimilate another thing. You may need some relief or reshuffling of your current duties before undertaking additional training. Being honest about your capacity allows you and your manager to plan in your best interest. Otherwise, your learning block will leak out in ways that will affect your performance.

Observations on Technology Overload

Technology overload stalks everyone in our industry. It impacts the quality of our work and the quality of our lives. Consider this analogy for a moment: Programmers are the top guns and prima ballerinas of IS installations. Without them, the AS/400 dwindles in usefulness, reduced to serving as a pricey plant stand. For all their eccentricities, programmers are the creators that breathe life into inert computer stuffings. To do so, they must keep atop a bull that never stops bucking.

Programmers—like people engaged in ballet or combat aviation—have a common enemy: time. The latter two dread time’s passage for obvious reasons; these are pursuits of the young, and time too quickly forces a change in occupation. Time, of course, affects programmers differently but no less sternly. The physical changes it brings may not be career-threatening, but over time, the constant, dizzying pace of technological change can be. As wave after wave of new technology crashes relentlessly against the bulwark of IS installations, even the most flexible coders (and the people who manage them) eventually exhaust their ability to adapt. S/36, S/38, AS/400, OS/36, JES, OS/38, OS/400, DOS, Windows, TCP/IP, POSIX, X.25, Ethernet, Token-Ring, the Internet, data warehousing, client/server, telecommunications, wireless communications, BASIC, RPG, COBOL, Java, Domino—it never stops. Seemingly overnight, today’s experts become tomorrow’s novices, then train again to become experts, knowing that the only thing that awaits them at the end of the tunnel is another novitiate. Over the course of a career, a programmer can die a dozen vocational deaths. If a programmer stays in the business long enough, sooner or later he will tire of chasing technology; he will want to be left blessedly alone to practice his finely honed skills and not have to reset his career counter—yet again—just when it’s beginning to add up to something tangible.

I recall the blanching face of a senior systems engineer when the AS/400 was first announced at IBM. “I don’t think I can take another operating system,” he said. He paused to consider. In his 25 years on the job, he had mastered 22 operating systems and 16 programming languages. His mind recoiled at the thought of assimilating another piece of technical information. He was saturated and worn out.

Simply stated, people who have served the company long and well deserve consideration and compassion. Often, a creative accommodation can be found, perhaps a lateral move or a leave of absence. Employees who are technologically fried have an equal responsibility to honestly disclose their condition. Pretense serves no one. If the horse is dead, it’s time to get off.

The IBM Professional Certification Program

IBM stands ready to assist with AS/400 training through its Professional Certification Program (www.ibm.com/education/ certify). A variety of courses are available, ranging from AS/400 operations to system administration, e-business applications development, and client access. At the rainbow’s end, the candidate emerges as either a specialist, solutions/systems expert, advanced technical expert, developer, or instructor. Typically, IBM took a fairly straightforward thing and managed to complicate it. Only education roadmaps and sample tests are available at the Web site. Before you can take the actual certification tests, you must contact another company to arrange the testing and jump through assorted hoops. The cost, however, is affordable, ranging from $120 to $170.

It would be grand if, once we learned our jobs, nothing had to change until we were ready. Unfortunately, life is seldom that obliging. With the advent of the Internet and e-commerce and the suite of attendant software development tools, and the demand for new

applications to be delivered on ever-tightening schedules, we work against an unpredictably changing landscape where training is our guide.

Mark Twain, in a slightly different context, observed: “A man can seldom—very, very seldom—fight a winning fight against his training: the odds are too heavy.”

Let’s prove him wrong.