Okay so, job titles right?, quite important because they tell you (or give you an idea) what a position may be about, but there’s absolutely no convention whatsoever for these, and an “IT Engineer” may end up being the same as an “IT Systems Administrator” or an “IT Service Desk Specialist”, it is an abstract concept and it depends entirely on the company (working culture and country are also factors) and the hiring manager. Being job titles so abstract and open to interpretation, your best approach to keep things under control (for your own sake) could be “Job Descriptions“.
Unfortunately Job Descriptions are often overlooked by hiring managers, avoided by HR departments (because they don’t want to compromise if mistakes are made), and have a bad reputation in the IT industry since they have been used before to add abusive contract clauses (e.g. you need to clean the restrooms when not repairing laptops). However, a good Job Description is a powerful tool that can save your own department from specific individuals always looking for ways to circumvent policies and work as little as possible, which as a result saves you the headache of having to mediate with such people, and eventually start the hire/mediate/fire/interate loop. It’s about setting clear expectations for each role in your department, regardless if you call your staff as Engineers, Specialists, Technicians, Wizards, Jedis, etc…
Given the lack of popularity on all fronts, you will not be always allowed to write Job Descriptions until after a big incident, basically until you can make a use-case, sometimes you won’t be allowed to do it at all, and sometimes HR will rewrite some parts of your draft to “mitigate risks”, which are often just fear from HR to get compromised if you later need to terminate someone over not doing something writen down in this document. The effectiveness of the Job Description also depends on your country’s labor law, whether you use contracts or not at all, and if you can legally bound the Job Description to the employee contract, which is the ideal scenario.
This document should clearly define the purpose of the job, the expected performance within a list of key tasks, and the resulting accountability. Very important, keep it results-oriented and not task-oriented, you are looking for results and expressing clearly that not achieving those results may have consequenses for the employee. A baseline Job Description should include the following:
- Job title and brief description of the role.
- Who the employee reports to, and whether the position has direct reports.
- List of accountabilities (use action + subject + activity)
- e.g. Keep the network infrastructure under stable operations within the uptime SLA of X%
- Core skills for the position (subject + tool -if needed-)
- E.G. Network configuration management with Ansible.
- Qualifications: Desired education, work experience, certifications, licenses, etc…
- Environment: Working conditions and hazards (e.g. lifting/moving heavy loads, industrial environments, working at high altitude, etc…)
After finishing a Job Description draft please read it, put yourself in the position of the employee, think about an average day at work, and try to find any gap for which you wouldn’t want someone to perform poorly. Hiring someone to do a specific job just to find out later the individual found out a way not to do it and still get a paycheck is one of the worst headaches you can experience as a manager.
All-in-all, a Job Description is an results-oriented high-level document, and a good step forward to keep things under control in your department. If needed, you can go one step further and create Position Descriptions, which are low-level very technical documents, listing the specific activities, technologies and accountabilities associated to the job, however being low-level, a Position Description is final, whatever you include in there is what the employee is intended to do and nothing beyond that, therefore it can be a double-edged sword and must be used at discretion. Stick to Job Descriptions as a first step as these tend to work out well most of the time, and go with Position Descriptions only if strictly necessary.