Reporting To Executives 301
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."
an executive summary (Score:5, Informative)
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.
Comment removed (Score:4, Informative)
Ask the executives (Score:3, Informative)
Why don't you ask the executives what information is important to them? They are your customer so you need to gather their requirements, not ours. Once you know what questions they want answered, you can then generate reports that answer them.
Re:Ask them (Score:5, Informative)
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.
Re:Honestly, as little as possible!! (Score:3, Informative)
I think the term is called Return on Investment
anything you buy or spend money on has to do one or more of four things
1. enable the company to make more money
2. save on operating costs compared to the current hardware/software in production
3. protect the current investment/revenue stream in case of disaster or outage
4. enable development projects to be done faster so the product can ship faster. similar to #1
the third is more like insurance where you trade off increased cost for no return on investment to chance that a bad thing will or will not happen and the consequences of the bad thing happening. this is why a lot of cloud computing only lives in the tech media. when you crunch the numbers it doesn't really save you much money or any money and there is the risk of the unknown for large organizations.
What I do ... (Score:5, Informative)
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?
Re:Here's an idea... (Score:3, Informative)
how about asking them what they want to see?
In a small company like this, it's an okay method. In a large company, it's career suicide. Executives don't know what information they want. They want *you* to know what information is important; you are the specialist in your field after all. If you force them to choose a metric, they'll chose something like "problems solved" and reprimand you for a stable environment unless you list daily log-checks and backup restore tests as "problems".
Re:Random figures (Score:3, Informative)
I read the post, yes.
I outlined the utility of reports.
If his boss was wasting peoples' time he should have went to his boss's boss. What he did instead was lie. Lying is bad. By falsifying data in the report, whatever utility in the report existed is gone.
I have assigned reports as a task to ensure that the task gets done yes. I find it reasonably effective, especially when I don't have the time to do my own day to day inspection of work. I myself have also found problems when I have produced reports that I know will likely not be viewed. But I did find problems. And this was entirely due to having done an actual inspection that was required by the report spec.
I don't really consider myself a techie, that is true. I began programming around 1980 on a TRS 80 model 3. I wrote video games in basic. I didn't get back into programming until the early 90's doing database stuff in Paradox for DOS. My latest IT job has been intranet programming in Perl, and MySQL.
I also have an MBA in Entrepreneurship, with a Certificate in Business Ethics. My focus was on ethical strategies for new business development and re-engineering. I'm the turnaround guy that can come into a company and tell you what is going wrong, provide you with a new business strategy, and give you a list of the people you should hire and fire.
The report may have been pointless. However, it was not for the one producing the report to decide. It was between his boss and his bosses boss. If there was a problem it should have been made known to upper management so they could remove the report.
Management may have been incompetent, but this was malice. This was intentional deception of management to serve a personal interest.
Re:Random figures (Score:2, Informative)
Yes, according to the poster, it was not used for anything. However, the one that requested the report has not spoken as to its utility. All we have as proof of it being used by the manager is the word of someone who admitted falsifying reports. Granted, the admission was meant to be commiseration, so the act of falsifying reports may have been overstated, but the act was stated nonetheless. And as I said in this thread, the report has many uses, some of which are meant purely for the report producer.
And even if the report were truly not being used for anything at all (the employee being in no position to judge), that does not grant the employee the right to go maverick. One works for someone or one works for oneself, not both.