<
To get an accurate assessment of how systems programmers were identified prior to the early 2000’s (when I began to teach mainframe) I asked my good friend Reg Harbeck, a systems programmer for over 30 years, for an overview of how it was done. These are his reflections on his career:
Around the 1980’s and onward, as the IBM System/360-originated ecosystem began to mature, organizations adopted a number of paths for onboarding mainframe technologists. The factors they needed to take into account included:
- The number and nature (and urgency) of positions they needed to fill, including operations, applications, systems and networks, security, and database management, not to mention user liaisons whose responsibilities overlapped with their local organization and the mainframe functions they worked with. Because mainframe training at university was already scarce, whether a candidate had a degree or not, they still normally had to do a great deal of learning, and particularly getting experience and being mentored, on the job.
- Organizations that have mainframes are often bound by numerous rules, which may include strict adherence to HR definitions, not to mention differentiating union from “management exempt” positions. Differentiators such as salary (vs wage, and amount) and responsibilities were linked to degree requirements and non-union status.
- Threading one’s career through such a maze was easier if one fit a template, such as a degree – though not necessarily in Computer Science – and especially requisite experience. However, people had to come from somewhere, and so advanced roles such as systems programmer were often filled by bright lights who started out as operators or “tape jockeys” and showed strong aptitude and attitude.
- People who came up through operations made up a large portion of the high-end systems staff, but often had to be “grandfathered” into place due to lack of degrees. Typical mainframe organizations didn’t have a predefined path for people without degrees to move into responsible roles, leading to the existence or creation of apparent crises that mandated bending the rules.
In my own experience, after completing my Computer Science degree and spending some time working on Intel machines, I designed a business card for use in applying for more career-oriented jobs in which I naively described myself as having “broad experience from micros to mainframes” as I inaccurately perceived large UNIX boxes to be mainframes, a misperception that is still widespread. Based on this innocent mistake, I was given preference in the hiring process when I applied to work as a CICS Systems Programmer, as it suggested I already had some mainframe experience – which I consequently did.
Reg’s serendipitous entre into a mainframe career was not atypical. Most future systems programmers, degreed and non-degreed, more or less stumbled into a mainframe career. Companies used subjective criteria – formal or informal assessments – to determine who might be a good fit for “data processing” careers (the nomenclature used for what we call mainframe positions today). As we will see, industry is at present finding it difficult to onboard mainframe candidates the same way they onboard other IT positions.
The next post will cover what has happened over the last 15 years or so that has made Reg’s experiences a thing of the past – or are they? We will see that, for the most part, the standard way companies onboard IT talent in other areas does not work for the mainframe space, and we will offer our theories on why this is the case.
I thank ASG for the opportunity to share my experiences and thoughts on something near and dear to me: bringing new faces into the mainframe space. There are a number of approaches that over the past 15 years I have found successful that can be scaled. My goal is the eradication of the pushback points for industry in terms of the future of Z: “We can’t find the skills.” I hope I have irrefutably proven this does not have to be the case.
]]>
