What are you going to do with your staff? Until recently, mainframers ran the business computing systems, and the Unix people pretty much kept to themselves -- out of sight, occupied with pilot projects on new information technologies. Seemingly, all of a sudden, those Unix "techies" are Strategic IT Personnel rightsizing your organization to new enterprisewide, client/server, distributed-computing systems.
If you've played any management role at all, you know full well that the Human Resources aspect of your job can be just as complicated and time consuming as the technical side. And that's just to maintain the status quo. What should you do when personnel cultures are as different as the computing paradigms they operate and maintain?
When we, the mainframers, were "volunteered" to rightsize Sun's business systems about five years ago, we stepped into much of the same kinds of personnel hassles that many of you are now encountering or will soon have to deal with. We just stepped into lots more of it -- Sun was almost entirely a Unix camp (still is, even more so). The few people who were experienced in the management of business-critical production systems were mainframers. They needed to convert to Unix. The majority of the others -- the Unix people -- we had to "discipline."
We've talked extensively about successful programs and approaches we undertook at Sun to retrain our mainframers to Unix (see "Remaking mainframers," March 1994). Retraining Unix people to successfully manage business-critical production systems is an entirely different problem, which requires a much different approach.
How do you teach Unix people disciplines? It's actually not as difficult as we may have led you to suspect. The thing to do is have them prepare and implement the various RAS (reliable, available, and serviceable)-enabling features in your distributed environment. For instance, we first introduced our Unix pros to the concept of standards. You must implement system standards in order to control costs. We didn't actually try teaching Unix professionals this important bulletin; we just made them do it. We put them in charge of developing Sun's Unix hardware and operating system standards.
At first, they thought it was all just a big waste of time. However, as the number of IT-supported, mission-critical servers grew, but the head count remained the same, it became apparent to our Unix friends why standards and standard configurations are important. (Hint: If you've seen one, you've seen them all.) The same number of people associated with our data-center infrastructure that once supported only 20 servers, are now supporting more than 2,000 servers.
Besides having to document standards, we also put our Unix people in charge of customizing and developing the more sophisticated management processes for our New Enterprise. These include the change management software we discussed in our column in March (see "Managing change," March 1995) and tape management processes, which we modeled after mainframe systems. In this manner, our Unix people became disciplined by current mainframe philosophies and processes, and then spearheaded projects to translate those successful strategies into methods for managing production systems to their New Enterprise.
Hires and fires
Your data-center mainframer staff are invaluable in your transition to Unix distributed systems because they know the ropes when it comes to RAS disciplines. We made an extensive effort early on to retrain our mainframers to Unix when we began our rightsizing efforts.
An important outcome of that training program was our ability to separate the chaff from the seed. At Sun, all of our courses had hands-on assignments that students were expected to complete. Those who didn't complete the assignments clearly weren't interested in pursuing a career change. We also documented which classes, homework assignments, and projects the students completed and made note of their progress in our monthly status report. These metrics were tracked very closely by our entire IT organization, and we identified the winners and the losers. If an employee could not handle this rightsizing transition, we knew about it and took steps to ameliorate the situation.
This may surprise you, but although it's easier to retrain mainframers to Unix than to discipline Unix professionals, whenever you lose a mainframer (for whatever reason), you should go out and hire a Unix guru! Huh? Have we flipped?
Heavens, no -- we're not crazy for hiring Unix pros over mainframers. Experience has taught us, even back in the days of setting up mainframe data centers, when implementing a new computing system, always recruit the best system programmers you can find. Unix is the systems game we play today, and we do recruit the best Unix systems people we can find. We admit that when we set that policy a few years back, we weren't convinced it would work, given our experiences with Unix people and their apparent abhorrence of disciplines. But we went with our mainframer instincts, and the policy has proven itself true.
Let it be known that we really do respect Unix professionals. They are the ones who brought us new and exciting computing innovations. In particular, we're sold Big Time on the excellent computing paradigms that have emerged from Unix, including client/server distributed environments. Besides, some of our best friends are Unix pros.
Morale and compensation
It's every manager's dream to have a cohesive, happy, and focused team. Expect nightmares if you don't pay special attention to staff morale while you transition to distributed computing. If at all possible, do not partition your organization; don't put up barriers between your mainframe and Unix people. Make sure your staff works together as a team, and include everyone in your various projects, training programs, planning sessions, and so on.
Mainframers are experienced in RAS disciplines that are so important to the successful management of your New Enterprise. Unix people know how to implement and maintain that new client/server distributed-computing environment. Combining these complementary talents is a key ingredient for success.
We didn't always take this good advice. While changing from our original HP3000-based data center to the mainframe, we actively recruited mainframe personnel and excluded many of the HP3000 folks from training. Talk about major morale problems! Besides the nearly incessant squabbles and griping we had to listen to, we had some very valuable people quit in protest and disgust. We haven't made that mistake again. We hope you will avoid it altogether.
Senior mainframe people traditionally have higher salaries than Unix professionals. Although that trend is reversing in the new-hires marketplace, your established staff probably still has some salary discrepancies. In particular, your Unix pros may be doing the same basic job and have similar responsibilities as the mainframers, but work for less.
Robin Hood might take money away from your mainframers and give it to the Unix folk. Don't do it. Never raise the morale of one group at the expense of another. Rather, find other ways to balance compensation.
Don't hide the fact that there may be salary discrepancies. Set salary policies and let your employees know what their long-term prospects are for advancement and raises. Also, if you haven't already done so, implement a regular staff-review process and a nonautomatic raise schedule that is based on that review view. Use those nonautomatic raises to balance salaries. For instance, let's say your yearly salary increase per employee is around five percent. Redistribute that to balance wage discrepancies, giving perhaps one percent raises to some and eight to ten percent raises to others.
We've balanced our mainframer-versus-Unix-pro wage differentials (basically the same job description) by giving the mainframers only one to two percent increases and our Unix pros eight to ten percent wage increases over several years. And we didn't hide the fact that it was our long-term policy.
As you can imagine, the mainframers weren't overjoyed. But no one quit. We simply reminded them of all the effort and time we put into their retraining and how that put them in the forefront of the next computing generation. Most of them had already seen the writing on the wall and were well aware of their colleagues in other organizations being put out to pasture.
The rebellious ones
People are your most valuable asset when managing computing systems in general, and certainly when changing to a new computing environment. They are also the source for headaches if you don't train and treat them well and compensate them fairly. Even when you do all those things, you'll still have a skeptical mainframer who won't believe you can successfully pull off a production-quality distributed-computing environment. What we did was make sure they had the same opportunities and training as everyone else. In fact, we insisted they follow through, and if the nonbelievers quit, so much the better.
Make it a point to invest wisely in your most precious resource -- people. If we had ignored them, we wouldn't be here to tell you about our successful rightsizing endeavors.
Harris Kern (email@example.com) is Sun's Open Systems Migration Consultant for NAAFO Market Development. Randy Johnson (firstname.lastname@example.org) owns R&H Associates, a full-time rightsizing consultancy in Boulder Creek, CA. R&H Associates helps people worldwide in implementing and supporting client/server infrastructures based on their proven methodologies. © 1995 Harris Kern and Randy Johnson. All rights reserved.
Pick up a copy of their book Rightsizing The New Enterprise: The Proof Not the Hype, SunSoft Press/PTR Prentice Hall, ISBN 0-13-132184-6, or their new book Managing The New Enterprise: The Proof Not the Hype by Kern, Johnson, Hawkins, Law, and Kennedy, SunSoft Press/PTR Prentice Hall, ISBN 0-13-231184-4. Browse SunSoft Press offerings at: http://www.sun.com/smi/ssoftpress
You can buy Managing The New Enterprise and Rightsizing The New Enterprise at Amazon.com Books.
If you have problems with this magazine, contact
Last update: 1 May 1995