Slashdot Mirror
Reporting To Executives
chopsuei3 writes "As a System Administrator, I am charged with providing more insight into the functioning of the system. What types of reports and information do other System Administrators submit to executives and on what frequency? Measurements such as uptime and average page latency are useful, but our site is relatively stable and we see minimal downtime, so I'm looking for other important and useful information I can report up to better illustrate my efforts. Our system is also unique in that about 70% of the traffic we see is from devices and not human browsers. I am a lone System Administrator in a 20-person company which specializes in web-based irrigation management. I also simultaneously perform all IT-related tasks in the office, which may also be important to report up to executives on regular basis."
Numbers and stats are nice and all, but beyond the headline numbers, your job is to give an executive summary. Here is what I've been doing. These things are working well. These are improvements that I am targeting or hope to target. Here are the unique challenges (you described one) and risks that we face and how I plan to deal with them.
I'm not a system administrator, but I don't see how the above is any different no matter what your job description.
The question as to why will imply that they will take action at certain points. It does not mean that I change the numbers, it means that I have some insight in what they want.
The phrase I hear a lot is "actionable decision-quality information." If the executive has to ask "what does this mean to me and the company", you're presenting too much raw data. It's not filtered enough, cooked down and crystallized. Really, if you understand something of the business goals the execs are working towards, you'll know you've distilled the technical data enough if you feel like you can make the business decision with that data.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Alrighty, I AM a CTO of a 20 person company with a single admin and here is what I'm interested in.
1 - problems and their resolution
2 - potential issues
3 - time sinks.
So I get info on:
What broke last week and how did we fix it: a list of hardware software outages, their root causes, the fix applied, whether that fix is a long term of short term fix, if short term, a recommendation for a long term solution
Issues that my admin sees as 'near term' problems (2 months): list of systems low on resources (disk, cpu, ram, ...), applications that have repeat issues, upgrades that are due and are non trivial (potential downtime, critical app where the 'upgrade gone wrong' may lead to down time, ...), etc. This includes a list of any planned downtime and a description of the planned downtime (including 'the plan'/timetable of events) so I can remind or co-ordinate with others.
Issues that my admin sees as 'mid term' problems (12 months): list of systems due for replacement, applications/OSes that are near end of life, need for additional hardware (network switches, firewall upgrades, ...), etc
Any single issue that he spent more than an hour on or anything he is repeatedly spending time on, those are my definition of time sink.
Why am I interested in those specific items:
Items in category 1 are apt to come up in conversation with my boss. They are also items I need to monitor to ensure that the systems, applications, and yes the admin staff, are not causing the company headaches.
Items in categories 2 and 3 fall into planning and budget issues that I need to plan for, or co-ordinate with others.
Category 3 also allows me to eventually understand that application A or staff member B or 'department' C are killing us and I need to find a better way for the company to work. It also allows me a better understanding of whether the week is an anomaly or if I need additional admin staff or training.
None of this is in a rigid format, so no I can't forward you a template :). It is currently done via office visits/conversations, emails, and hallway conversations. That is working and I see no need for a more rigid structure unless we start to have communications issues. When we do, I'll setup a more formal status reporting system (currently, if it ain't broke ...).
Bottom line, in a small company, single admin case where that admin reports to the CTO, the CTO is effectively the systems/IT manager as well as the development manager, the CTO or corporate level planner, and the executive level consultant/evangelist on IT matters to the CEO and CFO. I do NOT necessarily expect the admin to be an IT manager, being an admin is frequently hard enough. However, that 'department' is not my only concern so to some extent the admin needs to summarize stuff and not ship me logs/raw data, I have too many hats.
Does that help?