Who Is Really the Head of IT?
-
A regular discussion in SMB IT circles is how hard it is to convince management as to technical decisions, or CEOs / owners step in and make final decisions, or technical details have to be presented and "sold" up the chain. This presents a continuous challenge to IT and one that we need to learn how to face well, but before we learn how to tackle it we also need to learn what exactly we are dealing with.
We often know of an IT person identified as the CIO, head of IT, Director of IT, or whatever. But rarely do these positions in the SMB get to make judgement calls on their own, they need to present their technical decisions up the chain to other management positions for approval. This presents a conundrum - the head of IT is not the person making IT decisions?
Titles are dangerous things as they are given out capriciously. So let's define something. Whatever the "buck stops here" end all of IT management is will be the last step to have direct insight or care about "under the hood" technical details. From Head of IT position will present upwards to whomever they report to in the business chain through a business interface. They will discuss risk, cost, investment, business plans, growth, regulations, opportunities, efficiency, outsourcing, offshoring, staffing, finances, budgets, planning and other business aspects. However, they will not talk about details - they won't discussion RAID, SANs, servers, cabling, networking gear, applications (within reason), databases, vendors, etc. This concept is critical. Above the Head of IT, discussions are business related, below them they are technical.
What this tells us is that in nearly all SMBs, no "IT staff" runs IT. Final IT decisions are almost always made by people "above IT" who do not identify as IT and do not study or likely understand IT technicalities. But this is very important to understand, IT professionals often feel that they or their predecessors carry a responsibility for running good IT in their organizations, but are rarely given the tools, responsibility and authorization to do so. IT Pros need to understand when they are or are not tasked with actually running IT. Often IT Pros feel that they carry a burden to ensure things that they have no power to ensure. Making good recommendations up the chain, of course, should happen; but feeling responsible for decisions that IT does not make is not feasible.
-
These concepts are critical for conveying responsibility and role to other companies, IT pros, vendors, etc. An "IT Manager" that implements a disaster while claiming to be the head of IT carries responsibilities for bad business decisions. But an "IT Manager" that simply carries out orders technically to the best of their abilities only carries responsibility for the implementation within their scope.
-
In some cases, understanding when you are or are not may only be important for understanding your own scope and responsibility. Knowing that you are not responsible for data loss when someone in management above you refuses recommended backups is important for sleeping at night or telling a future employer about a previous role.
Knowing that you do (or do not) actually run IT could be potentially important for explaining in a court case who is responsible for decisions leading to breaches, data losses or violations. Titles do not matter in court, roles do.
But in a more day to day, practical sense, explaining to management "above you" at your job that they have decided to take over as the head of IT and that that impacts how you and they need to think about your job. Maybe this can make your job better, maybe this can help management understand business failings. But if we can't put these things into words, we cannot begin to address them.
