It seems that in the IT industry nothing is that simple – take for instance IT Job Titles on IT Job Descriptions.  Job Titles are an important element of workforce information in human resource management.  For various reasons we manage to really complicate this in the IT industry.

The IT Nomenclature Problem.

When is a Programmer a Programmer or are they really Developers?  What’s the difference?  What REALLY is a System Administrator?  Do they operate the computer – but then isn’t that a Computer Operator? Or do they look after the administration of the office systems?

And then the worst of all – a Technologist!!  Where on earth did this term come from?  It seems to be used more in the public sector than the private.  And gives the impression that if you don’t actually know what a person is supposed to do in the organisation – call them a Technologist.  Then you also have a Junior Technologist and a Senior Technologist and even a Specialist Technologist.  But we still don’t actually KNOW what the job entails.  It could, and generally is, anything!

Why am I going on about IT Job Titles?  Surely there are more important issues to address.  Probably yes, but this really is also important.

Firstly – I really think that people want to know that they are something.  When they talk to friends and colleagues, they need to be able to say “I am a __________” without the other party remaining unenlightened and confused.

It is also a problem when it comes to career management and planning.  With the flattening of organization structures, the opportunities for growth seem to now be limited.  But IT people like to grow.  They like to feel that they are growing in the organization, and that they have a career in the business.

From a management perspective, confusing IT job titles is even more problematic.  Take, for instance, remuneration benchmarking.  One of the biggest problems in remuneration benchmarking is “matching” the organization’s jobs with those of the specific salary survey.  HR people absolute hate doing this.  But when you have a range of “Technologists”, matching is virtually impossible.

IT people do their own remuneration benchmarking.  They look at jobs being advertised, they look at “public” surveys, they talk to each other – finding out where they are in the remuneration hierarchy.  And, more importantly, are they being paid fairly.

Take for instance the Network Engineer.  For some reason anyone that works on a network has become a Network Engineer.  So your Network Administrator (this is what most of them REALLY are) looks around to see what other “Network Engineers” are earning.  Only to find that they are earning R360 000 while he/she is only earning R150 000.  The company now has a problem.  And it takes time and money to resolve the problem, if only by getting in a consultant to accurately “grade” the job and do a salary benchmark.

When IT people can’t even resolve the problem of IT Job Titles, imagine how difficult it is for the HR people in the organisation.  How can they assist with development, compensation, recruitment, etc., etc.?

But .. why has this happened?

I guess there are many reasons, but high up on the list are three issues that most companies are experiencing:

1. Promotion.  Promotion, traditionally, means moving into “management”.  But there are fewer managerial positions available now-a-days.  So, to be able to have a “career path” we need to be able to promote our IT staff, without moving into management – a “technical” career path.  But the Grading Systems used by organizations don’t easily cater for this.  So IT Job Titles are created to bypass the system.  A Network Administrator becomes a Network Manager, a Programmer becomes a Manager: Debtors Systems – to be able to move up the remuneration ladder!
2. Multiskilling.   Multiskilling is, generally, acquiring, and using, more than a single range or level of skills.  For instance, a System Administrator also does the Disaster Recovery management.  Multiskilling is the way that the industry is moving – now called Competency Management – but the problem is the “plane” on which the Multiskilling takes place – vertical or horizontal.  Vertical Multiskilling in a single stream is what people do anyway when they grow.  They start off as a Programmer, become a Systems Analyst, then maybe a Business Analyst.  They build on skills from a lower level to a higher level.  But what organizations seem to be doing, is calling this Multiskilling and expecting their staff to operate over different levels.  This is difficult for staff to understand and absolutely impossible to benchmark for remuneration and career path purposes.  It is also really difficult to show that the person is actually growing in their career and more often than not, results in morale problems.  Horizontal Multiskilling, or Lateral Growth, is growing competencies at the same level.  For instance, a Senior System Engineer might also do some research on the system environment to propose enhancements or changes – in other words, might acquire Systems Architecture competencies.  This shows positive career growth and gives the incumbent wider choices.  It is also not so difficult to benchmark because the competencies are at the same level.
3. Remuneration.  When a person has been in the company for some time, especially if there is no Knowledge Management or Succession Planning, they become a critical resource.  They know the systems, they know the environment, they have created “quick fixes” to resolve problems … they become indispensable!  Then the inevitable happens – just when you are changing over to a new system, they resign.  What to do?  And the answer is generally – pay them more to stay.  But if they are already at the top of the “salary band”, there is nothing else but to give them a different Job Title that pushes them into a higher band.  I have even found Secretaries being called Senior Technologists – just to put them into a higher salary band.

So, what should we do about this?

The holistic answer is a broader issue – including IT Governance, Knowledge Management, Succession Planning, etc.  But from an IT Job Title viewpoint there are a number of simple principles that can be applied.

1. Call it what it is.  There’s an old expression – if a person walks like a duck and quacks like a duck, it is highly likely that they are a duck!  If  a person writes programs, they’re a programmer (or a Developer if you insist).  If they administer (or operate) a server, they are System Administrators.  If they write scripts and programs for software utilities or optimizing system operation, they are System Engineers.
2. Create growth within the Role.  You might only have one Project Manager at the moment, but you can bet that within the next couple of years that person is going to want a promotion.  If you only have the one Role defined, where do you go?  Also, create a more junior role.  You don’t have to fill the role just because you have it defined.  Defining the role means that you have thought about the role and growth within the role.  You are bound to want to bring someone else in at a lower salary than the present incumbent.  Prepare for it up front.
3. If in Doubt .. there’s always the Internet.  If you have any doubt about what title to give to a Role, search the Internet.  If there’s no-one else using the title that you were thinking of – DON’T use it.  If you find a variety of different jobs with the same title – DON’T use it!

If you stick to these simple principles, you will have a more motivated staff, because they will be able to see how they can develop in the organization.  And you will be able to better use HR services such as Remuneration Benchmarking.