What is an IT job description? Chances are you have held a few in your time: developer, database administrator, system operator, desktop support, technical writer. Beyond these blanket descriptions comes a range of specific activities that each job description is responsible for. Developers write code, DBAs create database schemas, technical writers write documentation.
So far so good, right? Technologies have common themes, those themes are captured in job descriptions, people fill jobs based on job description, and departments are filled with people who share common job titles.
But the real world is not that black and white.
IT job descriptions exist for HR organisation charts, payroll categories, and managerial hierarchies. Maybe when a job description was first written, it made sense both from an organisational point of view as well as technical one. But technology changes rapidly, and new roles are being created at an ever increasing pace. Forbes put together a list of 10 jobs that didn’t exist 10 years ago, and by my count 5 of those are directly related to IT.
Technology is changing far faster than the ability of enterprises to succinctly describe it in a job description. Motivated employees are upskilling themselves in areas that are way outside of the boundaries of their job descriptions and the departments that are used to group employees with similar titles.
Which is actually what every enterprise should be encouraging. And yet while desperately needing motivated employees skilled in the latest technologies, enterprises often hold those very same employees back by dividing work up according to a “best job description for the task” mentality. Developers wait weeks for a new table to be created by a DBA in the internal database, designers have to describe the desired changes to the CSS in the company’s website in a ticket that will sit around for weeks before a developer picks it up and compiles it in, and the operations guys find themselves blocked by one line of code in an internal application that includes a hard coded DNS entry. Every one of those tasks could be done in a few minutes by someone with the right level of skill, and yet projects are blocked because using that skill is “not part of your job”.
There is a simple test to determine if your organization assigns work to the best person for the job, or the best job description for the job.
Am I delegating this task because I can’t do it, don’t want to do it, don’t have time to do it or really shouldn’t be doing it?
Am I delegating this task because corporate hierarchies, job titles or issue tracking categories dictate that I have to, even though I am actually quite capable of doing it myself?
Answering yes to question 1 means that you have found the sweet spot for delegation. Answering yes to question 2 means that you are inevitably wasting time and money delegating tasks because of some outdated notion of division of labour, probably because of a job description that was written 5 years ago and no longer reflects reality.
I’ve argued in a previous article that there is little value in having developers (and indeed a lot of other IT personnel) fixing the same problems over and over again. If you accept that the pace of innovation in the IT space also means that the best practices evolve at the same rate, then it is simply not feasible for a job description written 2 IT lifetimes ago to come even close to reflecting reality. Tools, processes and markets shift, and IT employees need to have the freedom to shift with them.
From the pages of the mighty tome on building productive people and teams called Peopleware are these sage words:
Entropy is levelness or sameness. The more it increases, the less potential there is to generate energy or do work. There is not much you can do about this as a global phenomenon, but you've got to fight it within your own domain.
Job descriptions don’t give IT staff skills they don’t have, but strict adherence to obsolete responsibility boundaries is guaranteed to prevent employees from using some of the skills they have earned. Is it really worth denying your enterprise the skills brought by your best people because they are “not part of your job”?