opinion: Six Ways to Keep Your Mainframe Staff
Many of the sites I visit are justifiably concerned about retaining their mainframe technical staff. These staff members are often (or usually) over 50 years old, but remain essential to keeping the mainframe and its applications going. Sites find it difficult to find new mainframe talent for many reasons, from headcount and budget limitations to a lack of existing experienced, local talent.
You'd think it important that these sites retain their existing staff to keep things going in the short term, while planning for 5-10 years down the track. And yet I often meet disillusioned, unhappy staff that are counting down the days until they can afford to retire or move on.
So, in this article I thought I'd put down some ways I think sites can retain mainframe staff by, well, making them happier.
1. Don't Overwork Them
Everyone is concerned about budget, and mainframe teams have usually seen staff reductions over the years. In many sites, I see staff that regularly work 50 hours a week. Many of these are out-of-hours: early mornings, nights, weekends. Now, mainframe staff regularly need to work unfashionable hours to implement changes, resolve problems, and have telephone meetings with staff in other time zones. However, many sites still expect these staff to be at their desks between 9am and 5pm, five days a week. They're overworked.
Do this for a month or two and things are fine. But if this is the norm, staff will quickly get burned-out and unhappy.
The solutions are easy: give staff less to do, and provide in-lieu leave for overtime worked.
2. Give Them Fun Things to Do
Many mainframe sites I've seen are doing no real mainframe development. Existing systems are maintained, new software is installed to retain support. And that's it. No new projects, no innovation, nothing new, nothing fun.
Anyone working in such an environment is not going to be happy for long. They will feel unappreciated and bored. Their productivity will slow down, they won't be as responsive to customers, and the really good staff will look for other jobs with more action.
But there's a lot that can be done with almost mainframe system. Let's take some examples for systems programmers:
- Implementing new products like Spark for z/OS
- Implementing new (or not so new) features. For example, RLS for catalogs, zAware, Predictive Failure Analysis, CICS Explorer, z/OS Management Facility
- Reviewing security: check all required records are being recorded and checked, work with security administrators to improve security reporting/recording, review security related parameters, review the different ways users/applications can access z/OS
- Reviewing WLM to see if workloads are achieving their goals. Possibly working with business units to confirm that these goals are still relevant and suitable
- Educating application programmers on new functions like the CICS asynchronous API or CICS bundles.
In fact, I'm a strong believer in giving technical staff some 'free time' and encouraging them to explore and find their own things to do. Not all staff will take advantages of this, but the best ones will.
I remember in one job a while ago I had some free time, so went and checked all the hardware support agreements for our DASD. Doing this, I found a way of saving $100,000 a year by retiring some older DASD and using newer unused capacity. Paid for my salary.
3. Let Them Learn
IT staff are always going to learn. But if they're overworked and in a constant state of crisis, they will skim manuals and articles to get them through the current issue, but won't go deeper than that. This is not good.
Mainframes and the environments around them continue to change. So, mainframe staff need to do more than the bare minimum. They need to go deeper: learn the why rather than just the how. Learn about all the options rather than just one which will fix the current problem. Learn about the strategic issues rather than just the tactical.
Unfortunately, this often doesn't happen. Training is often the first thing to go when budgets are tightened, and mainframe training options are rare. Mainframe staff are often their own worst enemy here, believing that they already know what they need, and don't need training.
I believe that all technical staff should be required to perform training regularly. There are many ways this could be done:
- Send them to conferences like Share or IBM Z Technical University
- Give them access to online training modules such as those from Interskill learning
- Invite vendors to come and present on new features or issues with their products
- Get technical staff to train others. For example, CICS systems programmers could have training sessions with application programmers about new features or best practices
- Get technical staff to present. I find that when I present, I learn more than the people I'm presenting to. So perhaps a monthly meeting where one or two technical staff present about a project they've done, or an issue they've found. This could be internal, or to a wider audience
- Get technical staff to write. The articles I write are a great way for me to learn about technical issues. So perhaps a monthly internal magazine where technical staff are required to contribute a certain number of articles every year. There are other options and publications that staff can contribute to. Perhaps provide some encouragement or prize for staff that get published in an external publication
- Give them projects. In the point above, I argued that technical staff need 'fun things to do.' Staff will always learn more when doing these projects. Perhaps they could then present or write about them
- Put them on a Redbook residency (though these have just about dried up)
- Move them around. Often staff get 'stuck' working on the same area. For example, maybe one staff member is responsible for exits. Or only one works on CPSM. Moving staff around different areas will keep them fresh and learning new things.
The fact is that many staff won't voluntarily accept these options: they may need encouragement. This could be in the form of a prize or reward if they achieve something (say, a free dinner for two if they present in an external conference or get published in an external publication). It could also be a requirement. For example, lawyers in Australia are required to achieve a set number of learning 'points' every year. A points system could be setup for some of the above learning options.
4. Recognise Their Achievements
I remember a few (well, many) years ago I upgraded our z/OS version, including all the add-on software like ISPF, JES2 etc. Months of careful planning, work and testing culminated in a stressful weekend moving it into production. And it worked.
The problem is that I did this alone. And on Monday morning, no-one knew that anything was different. Now this is the sign of a successful change, but it can get you down.
Often we're caught up in the daily issues and 'fires' that we constantly fight. So, we don't take the time to recognise and celebrate achievements when they happen.
We should recognise and reward successes. If a z/OS upgrade is successful, let's throw a party. If someone goes above and beyond to solve a problem or help a client, shout this success out to others. Perhaps even a prize to show appreciation.
5. Involve Them
A (long) while ago I was in a mainframe storage team. One day, our management announced that they had purchased new storage. Without asking us.
Like anyone, technical staff want to be recognized and heard. Technical decisions made without consulting technical staff is always going to leave a bad taste. In fact, I'd argue that technical staff should be actively involved in all decisions that affect them.
For example, if there's a new CICS application to be created, the CICS systems programmers should be involved. If a new mainframe will be bought, the z/OS systems programmers should be part of the team deciding on the mainframe and terms. If an external consulting group will be performing analysis on the mainframe, relevant staff should be consulted before this is decided.
In many sites, I meet technical people that have ideas on changes to make things better, but can't get management approval. If we don't listen to our mainframe staff's ideas, they will stop providing them. And become a little less engaged in their job.
6. Be Flexible
I've met more than a few mainframe staff that have a commute of over an hour, each way, each day. So, they're spending around ten hours a week a car/bus/train/ferry in transit.
The VirtualVocations 2017 Year-End Report states that 20-25% of the US workforce telecommutes (works from home) for at least some of the time. And those with long commuters will welcome this opportunity.
Being flexible will help in retaining an ageing mainframe workforce. Some will want to start working from home. Others may want to work three days a week, or work on a Saturday and take Mondays off. Some may have always dreamed of taking six months to travel around Africa. And there will be some that need to take care of a family member and want to only work for three hours per day.
If we can allow our ageing mainframe staff to do what they need and want in life while keeping them employed, everyone wins.
Not Just Money
You may have noticed that I haven't talked about money in this article. No recommendations of higher salaries or better remuneration. There's no doubt that these will be welcome. But I'm not convinced that these are as important as the other points I've made in keeping staff.
I believe that the reality is simple: to retain mainframe (or any) staff, they need to be happy. They need to be engaged in their job, feel that they're appreciated, and be free to follow goals outside of the workplace. Happier staff will stick around longer.
Disclaimer: The author is working on projects with Interskill Learning.
David Stephens
|
Home
| Press
Room | Contact
Us | Site
Map
