Posted
by
CmdrTaco
on Monday November 09, 2009 @09:38AM
from the justify-your-existence dept.

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."

Asking the pointy haired what they want is a fool's errand. Best to come up with a straw man and some reasons behind it. Build a CGI (or something) and put it on a web page. Make sure it prints nicely.

The numbers could be entirely fictional - as long as the report looks good and seems to trend the right way it will never be read.

You and your parent will go far in life. I can't wait till someone finds you out if you are doing this because executives DO care. You are a fool if you think an executive doesn't care about things like system up-times.. I know from personal experience how seriously pissed executives can get with IT persons for reporting false information about the IT capabilities of the organization. When an executive hires a person they trust that person to report factual information. Just because they don't call you out on mistakes doesn't mean they don't care. It means they are busy as fuck, probably working way more hours than you assume, and don't have time to look up "quasitron" to ensure their employees are fucking with them. They will take the report at face value if you say everything is great.

To chopsuei3:

The best things to report are things that affect clients or are otherwise extremely important. Since you mentioned you are providing services to devices that I can only assume you are a type of "command and control center" for I would think the most vital thing to report is the up time of that system and any other pertinent information about that system. If it had gone down, why? and on a related note, what is being done to protect the system's up time. If there are no issues with this aspect and you think nothing will happen before the next report you may glance over it quickly, but still make sure critical systems are the first thing you report on. It will demonstrate you understand what is most important.

After that I would report on the status of any ongoing projects, not with numbers or charts but with words. This could come before critical systems if the project is critical but that should be obvious.

Finally I would report on the status of less-critical functions like the internal IT stuff you do. This can be as simple as saying "I dedicated 20 hours this month to desktop support, this has been the average for the past several months." with maybe a little analysis if you want to work that number down.

I think the preferred format for an executive would be more written or bullet points rather than charts and figures. Help them to understand what is going on so they can better help you accomplish your goals. A chart that has up-times on it is worthless to an executive unless you thoroughly explain it so you might as well do the analysis and then explain what it means rather than presenting the charts as eye candy. An executive wants a "what does this mean" perspective not a load of information that they have to derive the "what does this mean" from. There may be times when raw charts and figures are important so don't completely scratch them, just make sure you aren't just throwing information out there just for the sake of having stuff to present.

Delivering concise, well thought out, and informative reports are way more effective than a "data dump" just to prove you do something every day you come in. The executives are busy, they don't want to waste their time reading a huge report on unimportant shit.

Mocking up? You might as well just make it up. Stick a few trekkish terms in there - quasitron throughput and such - and see if anyone bites.

And when the CFO, who unbeknownst to you has a BS in physics, gets angry? Executives aren't as dumb as people here like to think, generally they just tend to lack practical, hands-on knowledge of the technology, because they honestly don't really have to know.

Also, think about it yourself. What does the network do? What measures can you make that describe whether it's working well? If someone were trying to improve the network, how often would they want to see those measures?
Management usually doesn't know enough to know what to ask. You're the expert, figure out what they should be looking at.

Also, think about it yourself. What does the network do? What measures can you make that describe whether it's working well? If someone were trying to improve the network, how often would they want to see those measures?

Management usually doesn't know enough to know what to ask. You're the expert, figure out what they should be looking at.

Just a small reflection on this comment.. I think this points out a flaw in how us engineers think. Management doesn't know enough to ask about the network but does it matter? How the network works is really not that important to them. How is your network contributing to the business as a whole? What metrics management want are probably more related to that and the business side of things then trying to educate them on how it works. After all, their job is not running a network, it's running a busines

Management is looking for you to bridge that gap between technology and business, which can either be bridged by you framing things into a business perspective or making them learn more about technology so they can do it. Your value to the company will increase if you take the former approach.

Second the first part of that.
Try to put yourself in their shoes:
If I were running this company, what would I need to know about the IT stuff?
"The sales staff is unable to access the order system for 15 minutes pe

In the past, many executives used to be engineers, or at least had an engineering or technical background. As an IT worker, you could have technical discussions with them and they'd understand the general concepts, even if their background was in mechanical or civil engineering, for instance.

In the US today, that's no longer the case. Being a executive these days isn't about providing leadership and making decisions based on knowledge. It'

Agreed perfectly, with one big, fat caveat: Have a very good handle on what you have, and can and cannot be done. Also, never, EVER promise anything up-front w/o studying the problem.

Recently, I got one for my own employer, in that our CEO wanted to simply open his cell phone and search all contacts in the group...

...err, the whole multinational group, across four continents. At first, it sounds easy (IIFP doing most of the grunt work), but then the fun began. One site used GroupWise instead of Exchange (which by default apparently reverses the contact info names from MSFT AD's 'Last, First' format). The version of Cisco Unity (VoIP handling) we have only reads one field - "IP Phone", and will only let you do one forest as a whole, or 5 OU's max (which means even more scripting). We had to deal with language localizations (esp. Korean). We had a huge bucket of duplicate contacts. I've had to learn more about Exchange 2007's GAL handling than I ever wanted to. We had to coordinate it all across multiple time zones (12 hours back to Asia, 8 hours forward... oh, and the South African office), which means a lot of early mornings and the occasional late evening.

Long story short, it's doable, but it eats a lot of resources to get it done (fortunately, we haven't had to spend any real money for it, but it's not quite complete just yet). While I doubt that every request would start getting hairy like that, you'd be amazed at how often the most innocuous of CxO requests can end up eating a mountain of time once you get into the minutiae.

Finally, I'd suggest that no matter the request, you never take your eyes off the prize - keeping existing systems running with as much uptime as possible.;)

Why didn't you explain that the different mail and phone systems you're using are not compatible for that project and suggest unifying them all into one product? Why bang your head against a door to solve a problem that a vendor somewhere has already solved for you? The CEO isn't going to care how much effort it takes, nor will he care about the money it costs to institute something else. Either way you'll look like a hero, so just take the easier solution and move on to something else.

Yep - and was told to "solve it", but given no budget by the CIO to do so, thus the script-fest.:)

Most of it is working, and it has had some nice side benefits (now, anyone can email anyone else anywhere on the planet).

But... the point is that we never would've bought the mess if the CIO had the cojones to first say "let me look into it and give you an answer by Friday", then stand up on that Friday and say "we can do it, but it will incur time and cost - here's why". Instead, he gave a blanket promise to

Wear a tie. Polish your shoes. Make sure the colour of your belt matches your shoe colour, and your socks match. Get a haircut the day before.

Small things, but they make you look professional. I'm not sure if you dress like that every day, maybe you do, but if he glazes over during technical blurb you may find him considering whether you get a bonus based on whether your shirt does or doesn't have a burrito stain on it.

...unless you have a boss like I had a while ago, who said his techs have to come in t-shirts and jeans because it's his firm belief that if tech people come in suits they want to sell snakeoil and don't know what they're doing.

I am not kidding. I got the job because I was the only applicant who came in pullover and jeans because I didn't have time to change into my "I wanna have this job" suit.

Despite their rather odd hiring policy it was a pretty well run company with a lot of very good people and a manag

"... but you'd be amazed at how much easier things become when you ask people what they want."

The problem is, especially with suits, is that what they want probably isn't in the same galaxy, let alone ballpark, as what they need or what they can use.

The upshot is once you get that report all nice and automated they'll ask you for the exact same report three months later having entirely forgotten its existence. Don't tell them they've been getting that report daily/weekly already for the last three months. T

The problem is, especially with suits, is that what they want probably isn't in the same galaxy, let alone ballpark, as what they need or what they can use.

Right. They're all a bunch of idiots and got where they are by sheer incompetence. Almost makes sense... I'm sure you understand their job better than they do - after all, engineers like you and me know everything right?

The upshot is once you get that report all nice and automated they'll ask you for the exact same report three months later having entirely forgotten its existence. Don't tell them they've been getting that report daily/weekly already for the last three months. They don't like that for some reason.

Gee, wonder why they might not like a condescending answer...

Perhaps the reason they don't like your answer is found more in how you tell them than what you tell them.

You horde your information because experience tells you that when you share it, bad things happen.

You always give a bullshit answer, because you've been nailed to the wall before because something that you thought to be the case turned out to be wrong, and, in the meantime, the phb you told that poisonous factoid to, turned around and told everyone up the food chain, and now YOU have to find a way to make something happen, which you've just learned is impossible.

If upper management wants open, clear, and honest answers, they need to understand the complexity of the question, and the reality that expensive problems can crop up in routine-seeming tasks.

I know, I know. Talking to people, particularly executives, is a daunting task for some in the IT world, but you'd be amazed at how much easier things become when you ask people what they want.

Ask?!? Actually asking a question is verboten in IT! First, you have spend meaningless hours researching the question and finding your own answers and then, after exhausting all of your options, then, and only then, can you go and ask a question.

If you don't follow those steps in that order, you will get a snarky condescending answer of "What? You couldn't google it?!" or some other asinine statement. Or the fact that admitting ignorance in IT is equated with stupidity.

It's really awkward when you have to report to someone who's not in IT and they ask "Why couldn't you have just asked in the first place?" It so hard to explain the childish and retarded social dynamics of IT to folks who act on an adult level.

Ask?!? Actually asking a question is verboten in IT! First, you have spend meaningless hours researching the question and finding your own answers and then, after exhausting all of your options, then, and only then, can you go and ask a question.

Well, guess what the IT guy did to find out the answer to your question. He probably googled the answer, before or after you asked him. Since googling isn't exactly complicated, it's not such a terrible requirement to expect you try to figure out on your own first.

There's a big difference between asking a question of random people on the internet when you're too lazy to google (although, it sucks when the answer is not available on google and you still get berated), and asking your boss about your perceived performance and any goals he may have for your dept..

I too worked for a 20 person company for in a role similar to what you did. I tried asking them what they wanted, but I quickly learned that I need to guide what they asked of me. You will probably need to educate them on the what you do.

I had a weekly status meeting with 2 execs to where I prepared a one page document with:

1) Here is what the main projects are, and my perceived priority (chance for them to change the IT priorities to match the business priorities).2) Here are any potential roadblocks to the projects (keep them aware of business risk).3) Here are tasks that were completed from the last week (advertise yourself).4) Here are the some potential large money items or other significant items that could occur in the next 6-12 months (depends on your company's planning horizon) (prevent surprises).

Number 4 is very important. Good executives don't like surprises. If you see ANYTHING that could be a major problem down the road. Tell them that you have discovered something, what the potential ramifications are, and what you are doing to identify, isolate, reduce the risks associated with the discovery. If your executives do like to keep their head in the sand, then you should keep an eye on the long term viability of your company.

I agree, and I'd like to add a subtle addition to #4, think about what sort of activities would require the company to hire another IT person. If you think your company will grow enough in the next 5 years that this may be a possibility, it may be a good idea to quantify your time such that it is easier for the managers to see that indeed your "use rate" is trending upward to the point where another person is needed. (This falls into the above poster's "no surprises" mantra.) I would guess at your size comp

I fear that you get that paper back with an earmark note stating simply "Yes. That." In other words, they want all the information. Only to complain later that there's far too much information to read it.

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".

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.

Execs usually don't care about the how. They don't also care about the why. They care about the whether, what and when. They want to know whether it works, what is required to make it work and when it's done.

Your boss will probably want numbers to answer a few questions. You are selling a service, at least that's what I read into the info you gave. What makes people use our service? What parts of our service are popular? What are unpopular? These questions answer the question where to pu

Start out your presentation stating that you're willing to dive as low as the executives ask you to but you're going to give them a high level view. Have slides after the end of your presentation as backup to support this claim. Keep large numbers of systems generalized with figures next to them to let the executives know how many devices or users you're supporting. Include meaningful statistics like 'requests per hour' to give them a good hint of how capable your system is.

If you're briefing one or two executives, see if you can pull up their calendar for the past few months and see what kind of meetings they've been in. If anything overlaps with what you're presenting do not brief the same thing twice. If you have multiple executives, tailor your presentation to the top one or two in importance. Nobody wants their time wasted with something they've already seen.

If they want a low level view, you might put together an example story of the flow of information from the sprinkler A all the way back to your server and the response back with all the challenges faced along the way. Keep it interesting, uncluttered and as simple as possible unless further questions are asked.

If you've got budget, pick up the three Edward Tufte books [wikipedia.org] on The Visual Display of Quantitative Information, Envisioning Information & Visual Explanations. Read them and incorporate that sort of data presentation into your reports.

Another great thing is if you can get interesting metrics established and defined and then develop scripts to ingest this information automatically into weekly reports (think of a perl script that digests very large log files). Have them create a cover sheet with the most general metrics and convert it to PDF or whatever the execs prefer to view them in. If you've got time, tailor them to the specific reader (your CTO is going to be interested in different things than your CEO or marketing director).

Start out your presentation stating that you're willing to dive as low as the executives ask you to but you're going to give them a high level view.

This is a really REALLY important point for just about anyone, really. I suppose it's a rehash of the old aphorism: "Know your audience." It took me a while, but eventually I learned that most people (even technical people) really don't care that much about the gory details and supporting data. Boil it all down into factoids and front-load your presentation, email, whatever with the simple stuff. If people want more, they'll ask for it.

Presenting executives with log files, or web stats is no way to communicate with your boss. This will give him/her an idea of the work the server is doing, but not you. You might want to present your to-do lists. These to-do lists should include completed and incomplete tasks. Since it is a small company and you are the only SA, you might try to attend the companies planning meetings. Be a part of the company instead of just an employee and you won't have to worry about CYA all the time.

Pretty "executive" reports is what they like to see, bar graphs, pie charts, etc. Also, stick with "top x" reports rather than 50 page reports which mean little to executive level people.

The problem is that most free tools out there really lack in reporting so you may want to figure out ways to export your data and write some sort of custom reporting tool in whatever environment you are familiar with, ms excel, php, python...etc. The answer is not easy, sorry.

I do reporting and give that to executives. I ask then what numbers they want and also why. 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.

Asking them will explain what is important to them. That could be completely the opposite of what you think they would think is important. Uptime might not be important if all your downtime is outside of office hours.

Also look at what your own goals are.

However do not give them more then 3 or max 4 numbers. They won't understand and will not know what to do with it. Save details for the quartely meetings. I have made so many reports onn request where they say: what are the numbers for XYZ and each time I ask them: what will you do if they are good/bad?

There is no reason in measuring things where there will follow no actions due to those numbers.

Also be prepared to answer questions that you can not explain or are very hard to defend. "Why is the uptime not 100%? That is what we pay you for."

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.

I don't mean to sound flippant or like a cocky IT jerk but they really have no idea what you're talking about. You'll have to translate it into terms they can understand.

In my company, the issue we're looking at is trying to quantify the value of IT. What management does not understand it devalues. So there's a bunch of geeks in a room doing shit. But what does it mean for the bottom line? Just filing reports on trouble tickets doesn't do the job. One ticket could be for showing a person where their start menu disappeared to and another could represent an continuing problem that took a hundred hours of work to resolve.

Staying until 2am to fix a problem in the server room doesn't count for diddly if all anyone sees of you in public is you being rude to a secretary for losing her word icon. That's all that will be remembered.

Staying until 2am to fix a problem in the server room doesn't count for diddly if all anyone sees of you in public is you being rude to a secretary for losing her word icon. That's all that will be remembered.

The only executive who would be meaningfully impressed with technical metrics would probably be in your direct up-chain (e.g., CTO), so tailor those metrics towards their concerns. Things like performance measures that allow you to spot trends ("Is it me, or do those new servers crash more often?") and predict future necessary action ("Are we nibbling into our system resource reserve? Time to budget for upgrades.").

Outside of geek-ville, measure stuff which translates into business terms. Compute uptimes and responsiveness and scale transaction measurements against sales, or eyeballs, or whatever your company is really about.

I worked in a 15 person company that had a CEO, 4 VP's and 2 high-level managers, too many chiefs, not enough braves. I used to get advice from the CEO about how we should go and rewrite our software in PERL, or PHP, depending on the article he was reading.

15 person company needs 1 CEO and that is it. if the CEO cant manage 14 people then he is a incompetent idiot.

One Competent CEO with 4 competent staff below him can easily, EASILY manage a company of that size. Idiots that hand out titles like candy are incompetent, be wary of a small start up with all executive staff.

PERL is Perl, and not an acronym! Or do you write PERL on your Apple MAC?

Practical Extraction and Report Language?

Yeah, I know, it's written Perl. I write too many reports with too many acronyms to care anymore.

On another note, does the increase in the use of automatic spell checkers make you feel all sad inside? What I mean is, after losing your main hobby and apparently sole purpose in life, I could see you getting depressed.

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.

Here are some items that my execs liked to see as they could understand them:
1 Amount of spam based on incoming email blocked.
2. Attempted intrusion attempts on firewall.
3. Virus outbreaks on network.
4. Since you run IT do you get phone records? Maybe the number of calls per department or inbound vs outbound and where all of your ld costs are.
5. You might want to look to see how accounting has your department's financials set up and maybe present those.
Just thoughts.

Focus on the benefits the systems provide for the business. For example, if you were sysadmin for a website of a major airline, you would focus on the amount of tickets sold online. Management is way more interested in seeing how much money the web site makes, or in what ways it helps people do their job better and more efficient, than purely technical data like system/service uptime or page visits.

Reporting numbers that are from a different department is silly. sysadmin for an airline website? report costs of operation, and current load with a reminder of where you need to upgrade. if you are a sysadmin and you are dipping into the database to look at sales numbers, you are not doing your job, you are doing the accounting departments job.

Website operational costs $xxxx.xx per month we had XXXXXXX visitors in that time period and are operating at 46% capacity. Currently experiencing a 6% growth from last month and a 1% growth from last year at this time. At this growth rate barring any hardware failures, we will not need any capacity upgrades for XX months. We had to replace a hard drive array at a cost of $X,XXX.xx and will be scheduling a 12 hour downtime window later this month for software upgrades to protect the company and site from fraud.

That is what an executive wants to see, distilled down to a small paragraph that gives him everything he wanted in less than 30 seconds. Also if you distill it tightly like that, you end up showing up the other guys that report because you are concise and to the point not wasting any of his time. They REALLLLY appreciate that.

Those are good if you run an airline... but this guy doesn't seem to be in that boat. This may be small enough they only have a few u's at a colo, or in house servers. Their system costs could be hundreds a month, not tens of thousands. When the yearly cost of IT services is under 10 grand, even a 50% cost cut isn't really big news. In that case, you have to show how you have improved the usability, improved information availability and BS like that. It's actually much easier to just report tech number

my thought exactly. emphasize ROI especially when it comes time to buy pesky things that maintain the business. selling redundancy can be hard, but one good outage will illustrate how important it is. i had a client who was running a small accounting office, so tax time was his critical uptime. no raid, not even mirroring. i scared the hell out of him by asking a simple question: it's april 14th and your server won't boot - what do you do?

Collect the amount of water pumped reported by each sensor as a trace between 9:30 AM and 4PM on the days the market is open. Find the correlation between this trace and the S&P500 index with a two minute time lag. See which sensor has a correlation coefficient more than 0.05. Use that info to come up with a trading strategy to buy and sell the exchange traded fund IVV. Propose a project find the leading indicator sensor for more securities like QQQQ, Diamond, XLF, XLU, XLV, XLP and the stock ANSS. Upper management is mostly made up of idiots who fall for such things. Build an empire under you. Watch the cash flow of the company. Just before it goes bust, put all this experience in a resume and get a job in the ultra high speed trading division of Morgan Stanley.

Due to all of your decisions being brilliant. As you can see from thesereallyquicklydisplayedpiecharts, Nobody in the history of $WHATEVER_WE_DO does $WHATEVER_WE_DO as well as we do $WHATEVER_WE_DO, thanks to your amazing leadership. I recommend that we keep on doing what we're doing, only with 5% more budget for my department.

That's the smart answer. Or you could tell them the truth, but please be aware that all companies shoot the messenger. All of them.

This is a one-off idea, but you could meet with marketing and ask for a list of the various campaigns they've launched over the past year. Then you could parse the web server logs to see where traffic was coming from during the dates of those campaigns. It would give execs a metric by which to measure the effectiveness of the marketing efforts. This is important, because as your ship sinks, the execs will look to you for help in determining the ballast that needs to be dumped.

I started working at an organization a while back and I would file a trouble ticket whenever I came across something broken, even if it was unimportant and with an overflowing workload might not be done for a while. A manager was hired after a while who decided to use the trouble ticket system as a meter of progress for tasks done. When he announced this, I immediately closed all of these types of tickets, saved them locally on my machine, and even went into the database so as to delete all vestiges of these tickets. I began only creating tickets when I knew a task would probably be done on-time and quickly. The manager was canned after about two years there - the thing that saved him for so long is that his manager changed three times while he was there, the third one axed him.

What management wants to see is that their investment in you is getting results. If they spend X amount of dollars on something, they want to see how it is helping the company or whatever. Show how successful your projects have been, how your uptime rate is always increasing etc. Use lots of colorful charts, lists with 20 goals and "accomplished" next to 18 of them and "partially accomplished" next to the other two. That type of crap. I mean, if management wants this nonsense from the sysadmin, you're in Dilbert land already.

In France in 1968 there was a massive general strike, with workers taking over factories and the like, and De Gaulle even planned contingencies to leave France and invade it at some future point with the French army and possibly NATO support. One of the wall posters of that time said "The boss needs you, you don't need the boss". Sometimes I think these exercises are more to psychologically mess with you than anything. You do all the work and create all the wealth, the bosses and shareholders don't do anything and collect salaries and profits. By making you do a pointless exercise like this to justify yourself to them, they're putting the idea out of your head of the reverse - of why *they* are necessary to the company. After 13 years in this industry, I'm becoming convinced that the dumb, pointless things management makes you do does have some strange psychological point along these lines. I've quit agreeing with my co-workers that these presentations are dumb and pointless, I think they do have a point - keeping us disciplined, from requesting sane hours and on-call rotation and all of that.

Is the average manager able to understand the type of information a systems administrator is able to provide? Or, put otherwise, is a systems administrator able to provide the information that a manager can understand? I think we have an issue here.

Parent post is wisdom for the ages. The more you can tailor your information to better support the exec the better. Along those lines, some essentials not mentioned so far.

Internal efficiency versus industry. Your costs versus some NetCraft number that can somehow be shoe-horned into a comparison.Speed versus industry. How cheap and fast can you roll out changes. How cheap and fast is your platform?I would add how you are working with Sales (first!, Marketing last!) to implement their ideas. ('driving

Depending on how technical your executive is, a lot of times they understand things better once you've translated all the technical stats into value and cost. For example, if X problem is keeping you occupied for a day a month, you can translate that into costs to the company. If your proposed solutions cost less, then it's easy to justify. If the executive is technical, then give him the technical stats but also do the monetization for convenience sake.

Executives want to know how well their business is working. One of the basic metrics for that is ROI -- return on investment -- and the way that translates into capital holdings is efficiency. Or, in other words, is it worth having all of those servers sucking power, consuming AC, and justifying your salary and benefits.

If you've already got uptime nailed (congrats!), then mean, median, and max response times are useful. This speaks to efficiency, and helps you, as IT guy, determine how many servers you

Write a detailed report, explaining all the jargon simply, and then summerize it to about 150 to 350 words. Most executives will read the "executive summery", but you will get bonus points from having the further content. However, if you decide to fill the body of the report with junk, you will find out that some of your reports are being read front to back.

Working on my Ph.D., I have a tendency of writing work reports within the 10 to 20 pages range, using APA citing. I use extended abstracts (~350 word

You work for a 20 person company that has executives and reports? What kind of company is this? My experience (as a sys admin and with simultaneous IT support) has taught me that reports are for shareholders' piece of minds unless you work for a really large company. And if you're a private company then the shareholders are the partners/founders and you should just talk to them like as needed.

Don't assume that he knows what some feature is. Think like his level. For example, from a technical standpoint he might only care that you just successfully rolled out a major software upgrade (if your company writes lots of software). This would be the equivalent to eBay rolling out a major release of their trading software, NOT them upgrading their linux boxes to the latest kernel. The only CXO level folks I've worked with that consistently cared about response time were those in which whose business

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?

First, management needs to know what indicators they need to follow to know how to prepare for equipment and line replacements and upgrades. That includes staying current on the moving target of what constitutes "best practices" for network security and capacity management. If your utilization is low enough that there are no spikes to capacity, don't worry about charts and reports. Management wants to know about exceptions and opportunities and most other stuff is not of interest.

I'm in a similar position; so long as the systems I look after are running OK I can fade to invisible, and only show up when there is a problem.

So; I do a small statistics collection every week, and update a spreadsheet (with some attached pretty graphs), and have it included as a slide in the weekly management overview my department submits. I keep a log of these over time. The sort of things I measure includes number of users on our internal issue tracking system (colleagues/customers), total number of ne

Lots of good recommendations but I can't believe nobody has mentioned the most important thing to executives: dollars and cents!

If things run reasonably smoothly at your locale, then the only other thing I care about is this: what are you doing to lower costs and make more money for us? Assuming you are not in govt or some non-profit, the profit is all we care about it. Anything else is just doublespeak for "profit".

How about telling him what you are doing to drive a 5% reduction in costs next ye

Make your report in dollars. Seriously, that's all that these people understand. Since you are a cost center, there's no profit to report. You report costs in dollars (computers purchased, maintenance performed, electricity used, etc), effectiveness in dollars (how this all affects the ability to provide the product or service to your customers or clients), and liability in dollars (the risks of failure due to insufficient spending on certain resources, such as better security, reliability, performance,

I think you should turn this the other way round - you are in charge of keeping the whole thing flying, and what is important is what YOU need to keep a tab on in order to do a good job. I don't know what kind of problems you tend to encounter on your site, but for many it would probably be something about how much your resources are being utilized. Like, how fast are disks filling up? You need to be able to be proactive - ie. to tell your managers that you need more diskspace before the disk is too full.

Each system you support has a cost of outage. You may be able to get around maintenance windows if you have high availability systems in place.
What you need management to be aware of is that there is a risk of financial (plus possibile reputation) losses when a system falls over, and significantly more if data is lost.
A good start is to feed back with a report of "money lost due to infrastructure weaknesses" on a monthly basis. Have this categorised by things such as failures due to aging, random blinds

One of the most important things you need to give managers is an idea of resource usage and trends. i.e. "peak load during Christmas season for the last 3 years indicates this year we're going to need a bigger router, and to split the traffic here across two systems", and how much that will cost, and what will happen if you don't do the upgrade. Big block diagrams of logical systems laid out on physical systems/networks/storage and usage levels on physical links,
combined with trends, lets them see why an

I assume you're providing the public web service, internal network services, and the product operation (irrigation management) services. So provide a summary of those three fields.

The executive-level statistics for the public web service will be easy to choose: How good is the service and when is improvement necessary? As will the internal services... summarize the measurable bottlenecks, including network disk space usage. Provide a number (or rescale it to a 0-10 rating) and a sentence which explains

I've worked in large and small companies, and the one unifying truth of executive communication is that they do not want details. In their mind, they hired you to take care of the details, If you say you need $100,000 to increase bandwidth at remote locations, you had better have a one or two sentence explanation about how this is going to make them money or help them make money. If they want to see a utilization chart or two, have that ready, but you're going to be tuned out if you launch into a long explanation.

I'm not an MBA, but my guess would be that they teach MBAs to focus on strategy and leadership, and to hire people to do the nuts-and-bolts work. Same goes for small business owners, but double -- they're doing crazy 120 hour weeks growing the business - why would they want to listen to a report from the guy they hired to make sure they wouldn't have to deal with "all that IT stuff?"

As long as you keep that in mind, reports to executives will go well. Short, simple, money- or productivity-focused explanations, very little technical information, etc. Think like they are thinking -- "Why am I paying for this?" "How does this make me money or keep me from losing money?"

anything you buy or spend money on has to do one or more of four things1. enable the company to make more money2. save on operating costs compared to the current hardware/software in production3. protect the current investment/revenue stream in case of disaster or outage4. 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 c

I give a report every quarter. This most recent quarter report is outlined below. I'm not sure if it will be useful to you, but I have found that If I can explain to the executives in terms they understand why they pay me, they generally feel more inclined to do so in the future.I put these in financial terms because if you convert this qualitative data (like what you do) into nice easy-to-understand quantitative data (like monetary sums) executives will be able to understand your job and your priorities be

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.

Know the audience. When you have a pointy haired boss, then it's going to suck no matter what. But in the general case, that's rarely the case (with the general case having problems as a matter of mis-communication combined at times with our typical IT sense of intellectual arrogance towards anyone who doesn't work on the same shit we do). But I digress.

When it comes to reports, always itemize the things you work, who requested them, when they requested, when you completed it, and the amount of effort (in term of time and collaboration with other teams) that it took you, including the time it takes you to create the report (seriously.) The first goal is to cover your behind. A report like that will show what you are doing.

The second goal is to, without much effort, have a report in a format (.i.e excel) such that you can do your own analysis. Which employee requests the most crap from you - this will also get you which department represents the bulk of your work, and which systems generate the most work. To the report, add an addendum for extreme circumstances (.ie. it took me an additional 12 hours to recover the site because there was a network failure between us and the DBA servers.).

Surprisingly, it doesn't take that much effort. All you do is keep a spreadsheet in which you log each request you receive, when you started working on it, and when you finish it. Format it well enough (or use a mickey mouse db like Access), and you can create a quick and simple report with a snap of your fingers.

Beware, though, of expending too much time trying to get the perfect reports. If it's taking you too much time, stop. The idea is to report a general ball park figure of things.

Now, if they are trying to micromanage you into daily reports with hourly entries, simply tell them that you will report 1 to 1.5 hours of effort devoted to the reporting task. After a few days, they'll back out very quickly.

A prime example of what's wrong in the communication between execs and techs: We don't know each others fields and we don't care to explain it to the other one.

I tried hard to get my bosses that I have in the course of my career to explain what they wanted to do with the information they asked from me. Not because I'm overly curious about their part of the job, but I want to present meaningful numbers. Often, execs ask for numbers that make no sense, but they don't know that they make no sense. They think t

I used to work for a head of department who demanded all sorts of printed monthly reports and would start getting on people's backs if it was late. Not only was it a boring time drain but it wasn't difficult to see that they didn't really know what the reports meant but weren't prepared to admit it. So for three months I handed in the same report with the headline date on the first page changed, on the fourth month I didn't hand in my reports and, when taken to task about it, took them aside and showed them the last three months reports I had haded in and the real data I had kept back. Fortunately I managed to get out of that company but I didn't produce any more routine reports after that.

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

Dude, just slap together some random figures like the number of occupied inodes in your hard disk -- they are executives after all, what do you expect them to understand about technical stuff?

You do realize that the single most common undergraduate degree among S&P 500 CEOs is Engineering right? Over 20% of them have an undergrad degree in engineering. And of course not having a formal degree in the subject must mean they are an technologically illiterate. After all, Steve Jobs, Larry Ellison and Bill Gates never even graduated college so how could they possibly know anything about "technical stuff". Good thing we have smart guys like you to explain it to them.

Track Hardware age.Present at least a 2 year out management plan for hardware upgrades with likely costs.Do the same for software. But you also need to watch for potential compatibility issues.Do you have spares?

Watch for potential migration opportunities of software and hardware platforms for efficiency and cost. These would not be indepth studies as management would have to approve those. Just keep you eyes open and report when something looks interesting.