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."
Dear Slashdot, How do I do my job? Sincerely, Chop Suey
how about asking them what they want to see? Prepare a short document listing what information you can provide them and in what format, and ask them what they want to see. How often, what detail, etc.
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.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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.
"What types of reports and information do other System Administrators submit to executives and on what frequency?"
TPS reports, of course!
Now bring on the Redundant Mod!
Loading...
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? Getting "mean web-page loading time" is already a big step.
My first program:
Hell Segmentation fault
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 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).
My work here is dung.
If you are concerned about supporting the reasoning behind the
existence of your job, it is time to depart.
Got Code?
Operations is a bottom-line game. It really comes down to how you're providing the service at the lowest possible cost.
I'd suggest trying to plan and execute projects that will bring down the hardware cost per user (ie, start compiling PHP. That could drive down cpu-cost-per-user).
It sounds annoying, but really that is the math game. Identify cost per user, cost per hit, cost per account or some other metric that management will understand, and then work to push that cost down.
Report on those efforts.
.
better illustrate my efforts.
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.
Flexible bare-metal recovery for Linux/UNIX
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."
Don't fight for your country, if your country does not fight for you.
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.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
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.
Welcome to the Panopticon. Used to be a prison, now it's your home.
How many execs do you have in a 20 person company?
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.
They went out of business, obivously.
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.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
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.
Not sure if you are virtualized or not, but VMWare client offers many great reporting features to give you CPU, MEM and HD utilization usage per server. Also, if you are running Cisco networking, the management interface can give you detailed reports with pretty graphs and such (which we all know executives LOVE to see). Another tool which I find useful for web-based environments is Statcounter. They provide very detailed information about pageloads and unique/returning visitors, all based on IP.
Loading...
It's always heartwarming to see a Sysadmin ascend to the point where they begin to slowly realize that justification for their salary is going to have to involve some lying.
80/20 rule - show them the biggest, heaviest hitters. if someonly happens .01% of the time, its a waste of your time to investigate it, work on it, etc.
I want to delete my account but Slashdot doesn't allow it.
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
If you were blocking sigs, you wouldn't have to read this.
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.
Seth
$5 / month hosted VPS on linux = awesome!
Reporting to executives effectively requires that you try to understand what is important to them as opposed to what is important from a system administration perspective. Some years ago I was responsible for a 24x7 data center operation and had the same dilemma. In the end I formulated a number of indexes based on operator workload and processing -- as absence of user complaints around service delivery were their hot buttons. As long as they saw workload and results as independent variables they were more than happy to cut back on resources. But by tracking workloads and report delivery it was possible to show the relationships. It is not the data but how it is represented to the exec -- simple words suitable for children and important executives. Their time tends to be pretty fragmented -- and their perspectives can be very different from the yours. It might be helpful to talk to them a bit to learn what matters to them. And if you can connect their issues to yours -- bonus.
You'll just gave yourself more mandatory busy work for no reason. Then if mgmt decide they want these every week or month, that's less time you have for projects or fixing things that are more important.
My boss did the same thing at another company, and now one day every week he has to spend creating charts and getting this information from baselines from scratch because he can't script for information and the company won't buy him any software.
I worked for a Fortune 100 engineering/manufacturing company as a Sys Admin for over 20 years. In my last position I worked in a small niche of the company outside of major machines and applications but still in a place where a system problem that lasted more than 24 hours could shutdown multiple factories. My immediate management did not want to know anything. My favorite quote was, "The best you can do, is to not let my phone ring with a complaint !" Any management above that level (incorrectly) assumed that the PCs on engineers desks were all that was required for them to get their work done when in fact all of their work was conducted on servers under my control. Worse, the servers in use averaged between 8-12 years old, some running "retired" OS's, most of which had no hardware maintenance contract as we had "spares" or could reconfigure them with less CPUs/memory until replacements could be obtained from the used market.
I would recommend taking some extra time to provide an explanation of what all the information means in terms of that executive's department so that they can accurately tell you what they want you to report. Many people want to hear everything because they aren't sure exactly what they are looking for but end up suffering info overload and read nothing. As eldavojohn said, your CEO will be interested in different things than your CTO.
I do not have a sig. You are hallucinating.
are high-level summaries of how the space is assigned out to our various branches located all over the US. I follow that up with a summary report that lists the total amount of storage each branch is allocated compared to how much storage they are actually using.
That's followed up with a per-branch breakdown of total number of files, total space used, and how many of each type of file are being stored at each branch. Going deeper than that is not always necessary, but I have the following reports ready in case I am asked:
How much data (per branch) is duplicated (same filename, same modified date, same file size)
How much data (per branch) is over 3 years old, over 5 years old, over 7 years old (legal requires us to keep some files for up to 7 years)
How many files have ###-##-#### in them or ######### (in case someone got stupid enough to save a file with someone's SSN in it)
How many Audio Files & space taken by them
How many Video Files & space taken by them
How many Picture Files & space taken by them
How many Executable Files & space taken by them
How many Outlook PST Files & space taken by them
Folders with "Personal" or "Backup" or "Archive" in them (users are not allowed to store personal files on shared space)
etc...
(there are actually a lot more options and queries I haven't mentioned)
I also use access enumerator to show the differences in ACLs of folders in case there are permissions issues.
Sig Follows: "Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself." -- Mark Twain
Agree with your executives what your mission is: security, stability, reliability, user friendliness, whatever...
Then the reports you need are those that demonstrate how well you are fulfilling you mission. Anything else is just extraneous BS.
Genesis 1:32 And God typed
Ask them, but some examples are Costs broken down, expected time line of current equipment, most common IT issues (with some breakdown of cost to the company). Then depending on the Tech awareness of the company, have a pie chart of where their IT budget goes, or an automated report where they can get more granular results.
But as a Sys admin that also does all the IT needs for the company, or at least coordinates them, you may also want to include some educational concepts, like links to articles about ideas that you believe can be done and would improve the bottom line. However know your audience so articles from Financial Times (FT.com) or other trade publications in your industry would be helpful.
Very important for management is future planning.
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. Especially with future scaling issues.
be brief, be gone.
That's about the best I can give you.
Your whole summary should fit on 1 sheet of paper, with bullet points.
The whole presentation should take less than 3 minutes.
Ask yourself, if you were flying at 30,000' over your operation, "What would I see?"
That's what the execs want.
And if I were in your position, the very first thing I would do is ask them what kind of reports they want.
Unless your executives have loads of extra time on their hands (very unlikely), they will only want a short, concise report, aptly named an executive summary. So you will want to focus on making things concise and to the point. Loads of numbers are usually not appreciated, only the most relevant ones, and a short description that may overview other issues that aren't representative of those numbers.
Your executives will probably give you a fairly good description of what they want to see, it will be your job to interpret that into the actual numbers you have available, how you will present it, what is or is not relative, and so on.
Aside from reporting statistics etc., what would be most useful from a business point of view would be some sort of e-strategy that is aligned with the overall strategy of the company. Executives usually spend lots of time envisioning where they want the company to be in X years. Figure out what this is, and formulate a plan for IT to facilitate this.
These days, the role of IT in all sorts of business ventures continues to increase, and can offer real strategic advantages for companies. They just have to realize this, and make the most of it. You can help with that.
Fox can take the sky from you.
What pages are people reading?
What are they searching for?
Country/city/network do they come from?
There is a wealth of market information in web and email logs.
Understand your business and how you can make it better, cheaper, faster, more profitable.
Deleted
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.
how about asking them what they want to see?
...
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.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
I don't know what you want to put in the report but I do know I would call it a TPS Report.
It really depends on the industry you're in, as to whether or not there should be daily, weekly, monthly, quarterly, or semi-annually generated reports. Personally, I would speak with the boss, first (if this is the first time you are being asked to provide reports, etc). Find out what the boss wants and press on. Ask if he would like a graph (Well said, waduva...) or a detailed list (by user, etc...). If you are working for small-medium company, you will probably be asked for a graph, possibly for each network user, once a month. The larger the business you work for, the more detail will be required, generally. However, be warned whatever information you gather is owned by your employer and not for you to judge. I've seen network admins dumped after water cooler talk about some other user's network habits (surfing, etc...). Remember, with great power comes great responsibility. And, a final thought, Remember that most CEOs, CFOs, and Presidents of corporations will understand a good percentage of what you're talking about. Do not talk down to them, but just give them the basics. Nothing too specific, unless they ask for it. Good luck and God speed, man! --Stak
Holy happy hippy crap!
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.
no, I don't have a sig
You don't want some bright young MBA to come along and wonder if your job could be offshored or done part-time. You want a metric that shows that you are irreplaceable. Hours spent on various kinds of task is a good one.
A lot of your reporting should be verbal. Make sure you have a good personal relationship with the higher-ups. Whatever you do, don't just hide in your office diligently doing your job. When the bright young MBA comes along, you want the big boss to be able to tell him that you can't be replaced and the place would go to hell in a handbasket if you weren't around. Only a personal relationship can do that for you. All the paper reports in the world won't cut it.
How much spam you've thwarted can be an interesting statistic, we're at about 3 Billion in the past year. Though, we don't actually report this to management, but it's an impressive number nonetheless.
There's your first mistake. No, providing more insight is not what you're doing. Your job is to:
Everything else about any reports you fill in for them is just incidental.
Go grab a copy of Dilbert and read it in the can (might as well do it on company time). That's the real world.
Be cognizant of the fact that while the executives can translate actionable data into... action... they are often unable to figure out the information the data is conveying. Remember your audience. Instead of a latency chart, you might explain that 99% of customers (devices, etc) wait no longer than 10 seconds. Other great points above are: ask the executives, and agree on a mission statement. Is your job just to keep the computers running, or to lower capital costs? Do you take ownership of investigating possible hardware upgrades and new technologies?
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.
EvilCON - Made Famous by
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 actually need.
The other main criterion for efficiency is cost; standard costs are bandwidth charges, power, and A/C. But be warned, if you give them a number, executives will want to optimize it, so be prepared to do so.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Show how the various systems and services directly support Business operations and overall goals like profitability, customer service ratings, etc..
Point out wherever technology is a business hindrance or obstacle, and provide multiple options for systems or software integration to alleviate the problem.
In short, use the opportunity to remind the execs that IT is more than a cost-center, and how its proper usage can enhance profitability.
Careful though; if you do too good a job, they might make you a (gasp) manager, and then of course, you are screwed.
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 words, check the report section of APA 5) and use a clear style of writing, expecting my readers to be college educated, but not to the extent that I am educated. However, I tend to be writing lengthy project plans, audits of projects and systems, and in depth analysis of business processes and products.
I treat status reports differently. Status reports are rarely over ~350 words, weekly reports trending at ~150. Brevity is king here. I put in a table of all of my projects with their status, next milestone, CPI, SPI, and EAC. I might also include PDFs of relevent reports that I had published that week.
In God we trust, all others require data.
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.
Just look at your job as anyone else who is not a sysadmin would look at his job. I mean: what is your goal? Then answer:
Did you reach your goal? If yes/no; what's your progress?
What are your next goals? Do you have the manpower, being on your own? How long will it take? How's the planning going along?
How is the system doing on a technical level? Is it fast enough? Room for improvements? Is the security up to par with todays threats? And how do you keep up with the latest IT developments and security threads?
How is the system doing for personel? Is everybody satisfied? Room for improvements there? Etc.
Is the system 100% fit for its purpose? Is it still functioning well enough? Do you need hardware upgrades? Etc.
Awnser these questions in a nice format. Google a status report format that is NOT an IT status report and use that one. Finally give it to the person. Just ask him if he wants a monthly or quarterly status report.
That should get you going.
PS: Do not report on anything too technical like "Our BLT drive just went AWOL" and you should be fine ;)
Here be signatures
As an executive I want to see how much additional growth I can add to a system before I need to expend additional capital.
A report saying XYZ resource is at X% and can handle Y% more growth before we need to spend $Z to expand capacity is immensely valuable.
Now I hope and pray that I will But today I am still, just a bill
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 businesses depended on response times (like financial trading companies, where response time = trading = money).
How are you saving money? (ROI, reducing expenses such as power/cooling/hardware). How are you improving efficiency (automation, consolidation etc..).
Also as someone that has presented many times to CxO level people, remember this if you have to give a presentation of your findings, "You are not in control of the presentation." No matter how much you prepare for it, or think you'll be giving a controlled presentation; fully expect them to look at your first slide and ask you a bunch of questions which are not covered anywhere, completely derailing/hijacking your presentation. Be prepared for "buzzword" questions, "Have you considered transitioning to a cloud based...?"
Last one. Check your ego at the door.
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.
While your text implies a static system, are your backups not consuming more bandwidth each year? What will be the implications of moving voice and video onto your network? Do you have the granular levels of QOS required? Would file de-duplication lead to lower bandwidth costs and lower costs site-to-site?
You indicate your company's purpose is "web based irrigation management."
Is there anything you can propose about the use, and/or deployment, and/or expansion of your network that would make your company an ever better choice for your customers?
Are you at the end of your contracts and can you combine voice and data lines and cut costs?
Could your network be expanded to provide any of your customers with bandwidth and service they don't get now?
Could you save your company money by outsourcing any part of your network or could you bring in more revenue by marketing your extra bandwidth to to others?
In general, what intersection might there be between things your team does best and challenges annoying your customers?
Combine your technical expertise with any knowledge you can develop about your employer's industry and opportunities and your contributions may increase in their value.
I hope one or more of these questions leads you to the answer you seek. Good luck.....
Live Long and Prosper - Thanks Leonard. You are missed.
You should avoid long winded discussions of operations that sum up to "everything's OK". You risk looking like an attention grabber if you try to cram too much detail on the way.
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 new issues this week. Size and number of objects in Subversion, Maven, TFS, ActiveCollab, etc...
Big trick is to have graphs showing usage increasing over time, and to be able to put numbers on these (we have doubled the number of items in our repositories this year!!!) etc. management like that; and find it very easy to justify.
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
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 year? Get creative. At worst, even if it doesn't work out, they will at least know you are focusing on the right thing: the bottom line. Then do it again next year. The point here is this: you should be relentless in your pursuit of driving money to the bottom line. ie: profits. That is the minimum expectation for anyone working for a business. Yes, by being employed, you are on a team. Act like it and try to attain the team's goals (profit).
Too many IT shops operate as one giant suckfest for money. Then, when having to explain themselves, they hide behind fancy jargon and technology -- none of which the typical executive cares about.
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, etc). Lots of pretty, shaded, colorful, pie graphs will help.
now we need to go OSS in diesel cars
Numbers are nice, numbers are safe to hide behind. But giving executives numbers means they automatically get something to hit you with regardless of whether they understand it. Thus, you make yourself their victim by doing that. Do something else instead.
Ask yourself what you'd want to know if you were in their position. What things should executives know to take the right strategic decisions about system administration?
One of the first things I'd think about is my workload. Am I achieving what I want to achieve? What do I need for that? Money? More hands? A weekly chat with the top bigwig?
The thing about executives is that they have this tendency to get stuck in full-out "tl;dr" mode regardless of whether them being them justifies that. It really is quite insulting to well-written missives and worse, all too easily abused, but it appears to be the status quo of global management, which isn't very good at that. So, you really need to look at it their way and tell them within an elevator pitch and with a very few numbers (as already pointed out) to basically make it a rubberstampable decision, except that if I were an executive I'd demand at least three options with explanation what it means for cost now and later and doing the same thing in the future again.
And yes, this comment is too long; I really should cut it down to just half of the previous paragraph. (Excercise for the reader: Which half?) But! I'm not an executive, and neither are you. Deal with it.
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.
What I am still working on is data collection - simply putting things into a relational database. I try to collect everything that might be interesting - user logs, running processes, network traffic counts, etc. I find that managers don't really want to be bothered when things are fine; they just want to know when they have to take action. So I would suggest that you focus on giving them data that allow them to predict what money they will have to spend on upgrades and repairs.
In my experience, if you demonstrate an enhancement of some sort, something that shows value...they'll love that. Create something - execs appreciate that.
This is the only defense against the next Carly Fiorina working in your company.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Just a starting point.
Uptime / Unplanned downtime
MTBF
MTTR
% CPU Utilization
% Disk Utilization
% virtual servers
% virtual workloads
Any counts of hardware failures by type and vendor.
Any software logical failure issues by type and vendor.
Help desk tickets resolved over time and unresolved.
Average time to new equipment deployment (lower is better), provided it doesn't impact other "failure" stats.
Some of these things help determine whether good decisions were made previously. Bargain networking equipment isn't always a bargain. Cheap servers aren't always cheaper. Commercial software isn't always better than free and vice versa. Not having a SAN can prevent flexibility, increase time to deployment, and increase downtime.
Then discuss which statistics the business users may want. Be cautious to measure something important and statistically measurable, not something to make someone feel good or bad.
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 blindsiding that may be able to be prevented with extra investment, that kind of thing.. This way, they get to see that you're not actually costing them money, you're one of the guardians (if not THE guardian) stopping them going down the pan. Most metrics (calls, bandwidth etc are useless; bandwidth is handled through accounting anyway as a payment, calls can be anything and are a useless metric, uptime, the same).
As an executive and a system administrator:
- timesheets
- list of tasks done
- list of tasks outstanding
That's it.
SR&ED
Here's my update template:
SCHEDULE
Projects working on and how are they progressing against defined schedule.
RESOURCES
What percentage of time is being spent on server builds, maintenance, HD
RISKS
What risks have been identified and how are they being managed
ISSUES
What issues have arisen and how are they being managed
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 and when systems need to be redistributed.
Basically you want to give managers a warm, fuzzy feeling that they're getting their money's worth out of the hardware they've bought, and that they won't be losing customers due to down websites, etc.
You also want to let them know what systems are getting old/off warranty or are otherwise in need of replacement. And if every system you have is going to need replacing in 3 years, maybe some should get done early...
And these days, something that indicates how close you are to everything up-to-date on patches, etc. is a Good Thing. Antivirus reports from your AV package are good for keeping them mindful that you're always under attack.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Last week I was asked to clean an executives blackberry. His track ball was dirty and he couldn't get it to work. Never-mind taking the phone apart voids the warranty. I cleaned the phone (90 minutes) and during that time I posted in my Sametime (company instant messaging status) Cleaning an executives blackberry. 2 hours later I got written up. So the lesson to be learned is to never tell people what your doing for executives cause they may get pissed off.
Reporting is designed to help with the following (not in any particular order)
1. Satisfying management that someone is paying attention
2. Forecasting upgrades
3. Dealing with puzzling downtime issues (even if your network is stable, the time will come soon enough when it isn't)
4. Pre-empting complaints by whining users who overstate problems. Some of these people can be satisfied if you can positively confirm or deny the legitimacy of their perceived problems. Either they are whining and the stats cause them to shut up, or they are correct and you now have a clue.
Pursuant to items 1-4 above, I suggest the following:
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 its meaning and/or how to interpret it ("Smaller is better, and the goal is less than 1 second per request.")
For the irrigation management service, because that is in almost direct support of the customers, you should learn how the process works from the customer's point of view (Are my sprinklers working? How much am I saving?) and from the company's point of view (server capacity, money saved by average customer, estimate of customers unable to connect to server, server requirements per customer). Some of the info may be of interest to different departments: IT, Irrigation Maintenance, Design, Sales, or Accounting. Then see what you can measure and decide what to report... and what to request in order to add more information.
isn't this just a case of the executives saying "tell me stuff." in as vague a way as that? It sounds like I am employed in a similar way to you, but when I was asked this type of request I basically dismissed it. Maybe it's just me, but it seems kind of rude for someone to ask such a vague question. Soon after I started I had an exchange that was kind of like this.. Hi, we want reports that show which employees are good. How do you measure good? Well, employees that start work on time and are efficient with their calls. How do you measure call efficiency? blah blah blah. This went on until the person I was working with was specific about each measure. That's how things go now.
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?"
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.
An excellent point, and one which most IT folks fail to comprehend.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
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.
Being a SysAdmin is a lot like being a lifeguard. A good lifeguard spends his whole shift sitting in his chair, occasionally blowing his whistle at a problem. If a lifeguard is making lots of rescues then he isn't doing his job. So how do you go about evaluating that situation.
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.
Your arrogance really sounds like ignorance to me.
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 better.
Summary of Previous Quarter (aka What I did, and why you paid me for it)
- Illustrate changes made to the architecture/infrastructure
Current Status (aka Aren't you glad you hired me to worry about all this)
- Make qualitative data quantitative, so it can be compared to previous quarters
- Group broad technical concepts together into categories that can easily be weighed in terms of risk/benefit ratios
ex: security, infrastructure, storage, architecture, auditing/reporting, backups, disaster recovery
- Include the effects to the overall business (the 30,000 ft/km view)
Expense Report (aka How much I really cost)
-What you spent, where you spent it (again, encouraged to stick to broad categories ex: software, hardware, security, training)
Incident Reports (aka Why you don't pay me enough)
-Document incidents, illustrated how they were resolved, what was learned, and what measures were taken to prevent them from occurring in the future
-Though painful, its generally good to point out your grievous errors here as well
Next Quarter (aka Why you're going to keep paying me)
-Make sure you know where your executives priorities are in terms of Availability/Reliability/Security/Cost and make goals for the next quarter
Hope this helps
It's a focking RED STAPLER! (as in eight different bosses...)
And if you feel the urge to mod this comment -1 offtopic, hand in your geek card ASAP.
What you're really asking is what is the value to the business of IT Operations "keeping the business running".
What's the point of IT Ops?
What revenue do those systems bring in? How are people not able to do their jobs when something's broken?
Talk to people and find out the cost basis for lost hours of any application being offline, including the hourly financial cost to the company when x number of executives are sitting on their thumbs when your mail server is offline.
Or, talk about how much money the company made because you kept the systems running.
Figure out any and all cost savings measures you've put in place, such as aggregating support contracts to save money.
Find out how many hours of staff time you saved by preventing that last virus outbreak.
Figure out how long it takes to get a laptop replaced and how you've improved that over time.
Figure out a few basic ideas for one-time spends that have 3 year cost returns, like replacing all those CRTs with LCDs.
Other than high level stats, 'did you know we run this many servers?' which are interesting but don't really mean anything, most of the statistics we IT geeks would come up with are just going to come across as confusing or self-gloating.
The only numbers that really do matter are the ones you can map back to the company earning more dollars over time and the staff hours saved (which should map to a salary/hour cost).
Money and time.
Then do a half-hour presentation of all those numbers over the past year, call it a 'Year in Review'.
Then, put on your teflon jacket and ask for advice on how IT can provide better service and keep the business running.
They hired you so they didn't have to know any of that. It took me a while to realize this, but the fact is; The just don't give a shit.
You can try and teach them how to cut and paste all day long, but in the end you'll still have to walk over to their computer to see what the fuckery they screwed up.
Sometimes, the answer is to just destroy it all.
Your executive (or usually the administrative secretaries) should communicate to you what they want. If they are not giving you an indication of the metrics they want, and they're leaving it to you, then you have the danger of boring them with useless and irrelevant information. Not repeating the 30k feet, brief, don't use IT speak comments; you likely want to engage someone close to them to figure out what metrics you gather, or can gather, and which are actually meaningful from the BI view. Oddly, information by itself is useless. Let me explain... I work for big oil/gas company (doing corporate reporting). One thing I provide is spill reports. They use this to scorecard divisions (for bonuses). But the information itself isn't very useful, because it doesn't say what products are spilled (specifically sometimes huge numbers come out re fresh water spills, and these are reportable to govt., but not as dangerous as sour gas...). The divisional guys get really annoyed because they're compared to previous years (so its spilled volume over time), and they really want me to speciate by operation or commodity, but I can't because the executive committee in charge doesn't care. They want ONE line item for an overall metric in one area of the business. So to reiterate, its really important to talk with them or someone close to them to figure out what is useful and what the "destination" is. Process improvement? Health check? Benefits/bonuses? Lots of categories to chose from.
/\/\icro/\/\uncher
What have you done? The you here can mean the IT Dept, the systems supporting the company, or you personally
What is on the schedule to be done? upcoming audits, maintenance windows, software renewals, hardware refresh (backend and user facing). you can break these up into near term, and longer term.
What obstacles are holding you back? do you have any major projects on hold?
Ignore the posts telling you to ask them what they want, at least as a basic open ended question. You could ask them if there are any specific items they are interested in, ask if there are any standard company-wide metrics/questions that you need to answer. You need to know what the 'requirements' are or any report you create will fail to satisfy the 'need' and it will get roundfiled, despite the fact you will probably keep producing it.
Having a short relevant report is a good thing. Try to keep it under a page if you can.
submit to executives and on what frequency?
(do not submit paper reports, just supply the following):
uptime report == beer.
traffic report == steak dinner
TCO report == golf day
ROI report == night clubbing
staffing and capitalization report (money used) == invite VCs.
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?
A lot of the sort of reporting on the IT end of things that would normally be included in this sort of report assumes an enterprise environment with a large support department, so it would normally include things such as average time to response after a trouble ticket is opened, average time to completion, etc. These aren't really appropriate and indeed may be harmful in a small company with only one administrator: I have been a lone admin in a tiny company like that, and when the boss got his hands on some metrics like that from a huge company (I didn't provide them, he saw an article on it in a business magazine) he suddenly expected that I was single handedly going to provide the level of support that would have required me to be a 5 person team, and demanded I produce metrics to prove I was doing it.
All of that said, I would do one particular IT metric for management: a summary of support requests by category. Select the categories you feel are relevant, and then start tallying the calls. Usually mine include things like computer hardware broken, software needs configuration, software inadequate to task, new software requested, printer difficulties, new hardware requested, and EOBUE. The latter is "Error Occurred Between User's Ears", and I usually phrase it more politely on the report to management, something like "user difficulty". Sometimes I break it down further into things like "training needed" and "user wants admin to do work for them" if that's a significant problem.
Anyway, this report can be useful in several ways... if you're having a lot of hardware problems, it demonstrates that management should be investing more in replacing machines because they're costing downtime and admin time, so it helps you argue for a better IT budget. Same with software inadequate, or requests for new hardware or software. The EOBUE stuff helps you argue for two things: training for existing staff, and that computer skills should be part of hiring selection. Yes, I have worked with companies that didn't screen for this, and they consequently got a bunch of computer-phobic twits who were used to doing everything on paper and tried to get the IT department to perform their every interaction with the computer for them. By showing that these idjits were running the support group ragged with constant stupid requests, I was able to get the company to start asking applicants about their computer skills before hiring. And in another case, I was able to get the employer to send an entire department for training, after which they were told that they could no longer pester me to do their work for them because they were supposed to know how now.
Figure out where your time is being spent, and report on how this improves their operation and reduces their headaches.
Report what did ~not~ happen because of your good work. For instance, maintenance discovered impending problem X and prevented any outages this month.
Figure out what would happen if you were not there.
Recommend budget items that would improve their profits.
Create statistics-based analyzes that show your bailiwick is more effective than the national averages and try to ascribe reasons (what you did to deserve it) why this is so.
simple, whatever data you are pitching, turn it into a stoplight.
Green = good. bask in the well deserved credit of superior executive skills.
Yellow = warning
Red = Bad! Yell at someone.
so simple any steely eyed, type A executive can understand....
with cost reduction projects.
Burn FAT not OIL
I work in a consulting-type field and I would say 90% of my time is spent talking IT to business and talking Business to IT.
Don't ask executives what they want (cause they don't understand IT and therefore could probably not tell you what they want), instead ask them what their business goals are or, more simply, "What keeps you up at night?" Get the executive's "top ten issues" list or put one together, then respond to those key items with how IT supports (or doesn't support) those initiatives.
This approach has seen more success than I can start to explain, because the majority of the time, the business completely relies on IT, even though they don't know it. So, you put yourself into those key initiatives and provide reports/dashboards/whatever that show your involvement in those items. I think you would be surprised at the executive's surprise in finding out how critical IT truly is to his/her business.
Also, remember the 5-5-5 rule: No more than 5 slides, with no more than 5 bullets, with no more than 5 words in each bullet....but you can have lots of pictures. Similar to the point above...they don't want a ton of details, but LOVE pretty pictures. =)
Give some thought to what you can do, and implement what you feel you may need (saved logs or databases), but don't go out of your way to decide what would be nice for them to have. If they ask for something- give it to them. If you can't- tell them you can't, but will find a way to provide it. (Nine times out of ten- they won't ask you for it again anyway, but at least if you implement it- you will have it for the next time.)
Most executives live for data/reports. They will happily gobble down whatever you send them, usually without reading it. If you offer them a big menu of reports- they will want all of them, and then you will have to spend much of your time doing nothing but generating them.
I know this sounds cynical, but I've been in IT for the better part of 20 years, on both sides (sysadmin and executive) for several companies ranging from small ones like yours, to "large" corporations. They are all pretty much the same when it comes to IT reports. Spend your time where it is important- making sure your systems are secure and running at their peak. Stay on top of new technology and security bulletins, and find ways to improve operations and lower costs (executives like that even more than reports). Usually the only time you will have to produce reports is when something goes wrong. Be proactive, be prepared to hand them whatever data you can think they might want, but don't create a lot of unnecessary work for yourself in the process.
He's 100% on. Any 20 person company that needs TPS reports for executives is either trying to become too big too fast
or has a bunch of "leaders" who don't understand core business concepts. Either way, the mere existence of that should
be a warning sign of impending trouble. Statistics and metrics on anything in the IT/Software Development world are almost
alway a poor substitute for sitting down and _LEARNING_ the business from the ground up to understand WTF is going on
especially in the scope of a small company or focused division.
For example, I'm in a 42 person software division of a much larger company. Our TPS reports exist because the top brass don't understand jack shit about building quality software. However, they trust us enough to have given us room for 10 years and so we give them pretty pictures:)
*** Sigs are a stupid waste of bandwidth.
More than anything else, executives don't want to be surprised. Giving them the weekly page response numbers is fine, but what they really need is forward-looking analysis based on those numbers and your experience. Something like "looking at the current load capabilities of our web servers, we will probably need to spend some capital on additional web servers if we add more than 500 additional reporting sites. Looking at our current growth rate of adding 50 sites per month, it looks like that money will need to be spent in less than 10 months to support continued growth." What they REALLY hate is when you run into their office at 12:30 on Friday afternoon yelling "Our systems hit the wall with that last new customer. I need $25k NOW!" Also, you've covered your butt by notifying them about serious issues that could affect the business with enough time to plan.
They may not actually spend the money that you have recommended, but if you have a trail to document your recommendations, you may be able to avoid getting blamed when the web servers can't handle the load when that big new customer gets signed.
First of all, don't ask them what they want to see. They almost certainly don't have the insight required to even begin to ask meaningful questions. Save yourself the work of producing meaningless output. :) Surely you have security measures in place to repel intrusions. Knock up some reports from the output of your HIDS/NIDS.
Uptime is nice, but there's not much to get excited about when it's always the same high percentage.
Do regular updates to your OS/applications? Document it, even it's just output from yum (or whatever), and put it into a report.
Backups? Report the number files/bytes backed up.
Sure, all this stuff is probably automated, but it represents work that you did to make it so. There is value in that work and those numbers are quite often the only way you'll have to show that.
Have you considered the possibility that the only reason why they want to know about the systems operations is so that they can outsource your job?
I don't see how the other person can be condescending to you if you ask them what you can do in order to serve them better.
I once had a signature.
What you are asking is too broad a question, you could involve business/time/budget management ,
you could also involve networking security, and advanced bandwidth analysis.
The problem is you have too many jobs rolled into 1!
A budget plan, is essential, as is the reason why you need to do the things you do, like replace hardware
such would be the analysis part, each document leads to another, each position, would extend their document to the next one,
such as your budget would have to encompass the replacement of the hardware....
How much time do you have to do all of this?
But also, don't tell them what you get done. Tell them how hard you work! A lot of suits don't understand what you get done, but they love it when their people show enthusiasm.
Having done so, it is much easier to stay close to your users and understand their problems. This is the key. Understand the business. Ask them what they do and what slows them down the most. This will determine 90% of what you.
Also:
1) Emphasize the cost of down time. Say: you have x number of employees billable at y dollars per hour. If we go down for 1 day the company loses $z dollars". Then talk about the importance of backups, redundancy etc. Make them value you and the service you provide. This is job security and makes equipment and hardware requests easier.
2) From my opening statement, list what your clients are talking about and seems to be their main problems. Emphasize you can increase their efficiency. Create drawings and case diagrams of their business process, they may not even know what their own people are doing. You are in a great position to add value by doing business process analysis. When I worked for the small company, I created graphs of what their process were which opened their eyes. Show them where you can eliminate bottle necks and save the company money.
3) Divide things into 3 classes: easiest, harder and hardest to deliver. Show them which ones will have the biggest benefit. Then create priorities. Also emphasize opportunity costs, e.g., if you do project A project B will be delayed.
And *always* under promise and over deliver.
Since they are involved in irrigation I assume they may have an Engineering background, like my old company. This is an advantage since you can take a quantitative approach. But always know your users and what their problems are. If you are concerned with them they will trust you and value you.
It can be fun.
putting the 'B' in LGBTQ+
Make sure it is in Powerpoint (regareless of what format is mot appropriate), no more than 2-3 pages, and has lots of multi-colored graphs. Execs often care more about the presentation than the actual content. (TPS cover sheets anyone?)
And please, don't mod this post 'Funny'. I'm being quite serious here.
Any insufficiently advanced magic is indistinguishable from technology.
There are several common themes presented in the collective wisdom above. Here are my 2 cents.
You are not a sysadmin. You are a businessman and a salesman. Never lose sight of those two responsibilities. Your company is not in business to run computers. Your company uses computers to run business. Everything must have a relationship to your business mission.
Everyone is in sales. Period. You have to sell your skills, projects, ideas, worth, etc. every single day, no matter what job you have. Your goal is to ensure the business leaders understand the value you contribute, not by the details you provide, but by your insightful way of connecting the techie stuff (irrelevant) to the business goals (important).
My advice is to keep the reports high level, with a structured format that makes them time-efficient and easy to digest. Include a project summary dashboard - what is going on and how is it going? Red, yellow, and green are excellent status indicators. Highlight any items that cause a business risk, especially to revenue. Understand how to express opportunity costs. How much more revenue or productivity could be driven if your ideas are implemented.
Quite simply, at some point you hope your 20 person company is a 50 person company (and beyond.) At some point the executives will look at you and decide if you are the right person to continue to connect with the business, or are you a techie person who needs to be managed by someone who can more adequately bridge the gap between business and technology. Your own self-impression can influence this greatly. If you wake up every morning feeling like a sysadmin, then you will soon find yourself with a new IT manager that you report to who basically makes twice what you do and yet you still do all the 'work'. Or you could become an essential business partner who knows how to communicate with the executives using language they speak.
It sounds to me like you're in an ideal spot to manage your career forward given your hands-on activity and yet your interfacing with pure business folks. My advice is to take this as a wake-up call to become more fully-rounded by better understanding the business and sales aspects of your role. If you don't fit into those shoes, someone else will sooner or later.
Doesn't "web based irrigation management" sound like a euphonism to anybody else? If so, do I really want to know what it means?
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
Never allow or create a report that runs on 'current' or if possible, even data that is one day old. Use a reporting database. Have it update daily, and if-possible exclude data that is only 1-day old from report results. If you do this, they won't hit your server every 15 minutes for an update, and bug you with questions about why no change in the last 15 minutes. And, if you do the second part, they won't be all over you if the reporting 'warehouse' build breaks one day. Don't become a short-order cook with this reporting. Oh, and if possible, contract out the making of reports. Then every time they want a new report, or tweak a report, it generates a cost and that slows the production of insipid reports.
> I am charged with providing more insight into the functioning of the system.
That's pretty generic. Do they have certain metrics they want to see in black & white?
> I'm looking for other important and useful information I can report up to better illustrate my efforts
Then that's your answer. You just need to find out what is important & useful to them.
> I also simultaneously perform all IT related tasks in the office, which may also be important to report
Whatever you send them, be sure to word it in terms of business value. As far as providing insight - you may want to create overview docs of most ALL of the processes/systems you manage; your job will be that much more secure if the non-tech folks are truly aware of how much you do around the office. As the only IT person, you provide biz value that no other in-house employee can, AND you save them money. Show them how by providing high-level workflow diagrams of these processes.
Heck, you may even get a raise if you word it right. ; >
At a small company, it shouldn't be difficult to keep your boss informed unless he's rarely around or isolates himself using The Hierarchy. If you have a difficult time showing you're worth your salary, just work a little harder and make note of what you do. Weekly, or even daily, send a report of what you've accomplished. Better yet, fire off emails as requests and jobs are completed.
Where I work, we are broken down into departments, even if there's only one of us in the department or we're responsible for several departments. Requests don't go to an individual, they're sent to that department. As such, emails aren't sent to employee@workplace.example, they go to department@workplace.example. It can get silly at times when firing off an email from one department to another even though you're in the target department and will also handle the work sent to that department.
No matter what, document the work and the work flow. It will come in handy should your company grow to the point that you need help in your deparment, or if that other department where you're also the sole employee needs to have someone else dedicated to the job. It will come in handy when you need to train your replacement when you get ready to move elsewhere.
And another hint: Document common problems and the procedures to correct those problems. If there are others around the office that are competent, you can give them enough access to fix these problems should you be away on vacation. There's nothing worse than being bothered 15 minutes into your first vacation in two years with a minor issue that a trained monkey can handle. Better yet, automate as much as possible so even that won't be necessary most of the time.
[I am a project manager on software development project] Definitely do weekly status reports and release notes (if you have software releases - I do). You will achieve 2 goals doing status reports and release notes: 1) communicate what you do to other people 2) improve your visibility and justify your necessity to your company. Both should be a list of items accomplished within last week (or implemented in latest release). Separate user-facing and back-end changes in 2 separate groups - non-technical people will only be interested in user-facing changes, so if they are separate and in the first group - there is more chance people will actually pay attention. To make it easier to do each week I recommend using some bug/issue tracking software (I use Axosoft Ontime) and if you do any coding - source control system (I use Subversion). When including item in the list also put the number of item in your bug tracking system at the end of the line. Subversion can be configured to required comments before commit and send email notifications to interested parties after commit. I force my developers to always put descriptive comments and related bug # (if applicable). This makes it easier for me to do weekly status reports/release notes - I just go through these emails at the end of the week. Send these not only to your boss but to other team members as well. To find out if someone actually reads these put somewhere in the middle of the list "17) If you are reading this please reply to me with "the eagle has landed" in the subject line". Don't let the fact that only 10% (at best) will respond to discourage you - this maybe the only people that count.
Only IT guy in a 20 man buisness? Well basicly you can't move up the latter, so set up some report generating scripts that through together whatever numbers you have available, along with some automatically generated fuzzy text like "uptime rose slightly" ect.
Then start slacking as hard as you can. Then maybe a year from now when the stats drop tell management you need assistants, and negotiate a promotion to IT manager or similar, then when you assistants do the same down the road, you'll properbly move up to some other non-IT management role where you can collect even more slack.
But seriusly don't worry about the contents of the reports, put some nice 3d Pie charts in there and they'll be happy, they are quite fasionable right now.
[I am a project manager on software development project]
Definitely do weekly status reports and release notes (if you have software releases - I do).
You will achieve 2 goals doing status reports and release notes:
1) communicate what you do to other people
2) improve your visibility and justify your necessity to your company.
Both should be a list of items accomplished within last week (or implemented in latest release). Separate user-facing and back-end changes in 2 separate groups - non-technical people will only be interested in user-facing changes, so if they are separate and in the first group - there is more chance people will actually pay attention.
To make it easier to do each week I recommend using some bug/issue tracking software (I use Axosoft Ontime) and if you do any coding - source control system (I use Subversion).
When including item in the list also put the number of item in your bug tracking system at the end of the line. Subversion can be configured to required comments before commit and send email notifications to interested parties after commit. I force my developers to always put descriptive comments and related bug # (if applicable). This makes it easier for me to do weekly status reports/release notes - I just go through these emails at the end of the week.
Send these not only to your boss but to other team members as well.
To find out if someone actually reads these put somewhere in the middle of the list "17) If you are reading this please reply to me with "the eagle has landed" in the subject line". Don't let the fact that only 10% (at best) will respond to discourage you - these maybe the only people that count.
Make sure it fits on one page of powerpoint and includes some traffic lights, preferably showing green.
Your job is important to them only insofar as it helps them do their job. Therefore, knowing what they need to know is key to structuring your communication. Most execs like a 'dashboard' style view that summarizes the current activity. You might suggest things like:
1) new customers added, canceling customers subtracted
2) system incidents in pass week and month, summarized by type and severity
3) Budget activity (expenses/month/year, against planned costs)
4) System activity of interest (unique customer visits, page views, complaints, support requests, etc)
In most of my jobs, I add a weekly status report that reports what I did last week, what I'm planning on doing this week, planned absences (vacations, etc) and finally, Issues Requiring Management Attention, which are the items that I need them to attend to. The status report becomes the agenda for my 1:1 with my manager.
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
There's a standard approach to doing this.
From your post, I'm going to assume that you are talking about a routine status report and not a one-time stand-up presentation, so we don't have to worry about whether you have a fresh haircut or how nicely you're dressed.
What your management wants is assurance that all is in order and, if it's not, where's the problem? This can usually be done with a few numbers and/or graphs. Metrics.
The first thing you need to know is what is important to your users (and the owners of the devices you refer to).
The second thing is to figure out what you can count that says something about how those things are being supported. Find unambiguous metrics, so that you could send five people out to do the counting and they'd all come back with the same value.
The third thing is to design effective presentations for the data. As a manager, what I'm going to want to know is
One metric can easily be presented with a couple of numbers and a sparkline for the trend (read Beautiful Evidence, Edward Tufte). You can use Excel's graph feature to make the sparklines. You can mark the acceptable range on the sparkline for maximum clarity.
You can probably report everything you should with at most a half-dozen metrics across the top of a sheet of paper, followed by whatever narrative is needed to highlight points of interest. Take a look at http://tanda.on.ca/notebook/securitydashboard.html for an example.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
Dear executives. The Internet tubes have no clogs and there is a free demo of Peggle.
Don't blame me, I voted for Cthulhu.
There are three key things that executives want to hear:
1) What has the department done in the past? The core of this point is to get to the question "Does the past justify continued investment?" and its correlary "We've sunk so much money into IT, what have we gotten from it?" This is where usage statistics (website hits, business transaction data, dollars-per-downtime and Nines, return on cost-saving measures, etc) are presented. This should be in high-level terms with drill-down slides available, but only presented on request. Focus on the trends of service delivery vs. IT budget and/or headcount.
2) What is the department doing now? Here we focus on what is happening with their current business. This is where a primary element of capacity planning comes in: The Headroom Metric. How much additional user load can we support on our current systems and network, before the service is degraded? In concrete terms, ignoring everything except CPU, if you're delivering 100 pages per second, and using 40% of the server's CPU, you have a headroom of 150 additional pp/s. By extrapolating this to the business need - say the marketing department has launched 5 campaigns this year, the current systems may be able to support 10, but should not be expected to support 20 without additional investment. Note that this headroom metric must look at the end-to-end utilization, like disk, memory, network, and most importantly administration effort in order to be accurate.
3) What will the department do in the future. What are the business-focused projects that the department is working on? How will the investment in these projects result in money coming into or staying in the business? What is the Return on Capital, Return on Investment?
As far as timing, there should be at least an annual "full report" on the state of IT. Depending on the dynamics of the business, quarterly updates should be sufficient, unless something changes significantly. And depending on the team and scope of the projects. You don't want to face this with a "we haven't done anything since the last report" status. But it's also important to reconnect with the executives regularly so that they don't forget about what you're doing, and also so that you can react and change to meet their changing business plans.
The most important thing we in IT can do is to be aligned to the business. This means focusing on the things that matter: delivering the product or service in exchange for money. Everything else is overhead. And the better your IT department is at aligning itself, the better you look when an outsourcer tries to talk your executives into cutting everything except the "core competancies".
--Joe
Start by defining the services you deliver. For example, email. The exec's don't care about your internet connectivity uptime, server disk space, etc. They care about services they consume, and the availability and cost of those services.
So, think about it from the perspective of the execs going shopping to replace you. They'd go to IBM and give them a list of what they want from IBM, in language that you'd expect from a business-focused non-technical user. Now build that list in your head, and associate the underlying components with each of those services and start monitoring both the service and the components, and report back on the service availability quarterly.
Next, they'll ask you how much each of those services cost (they're always looking to cut costs, be ready and surprise them with a list, and demonstrate how you're the best choice.)
Our system is also unique in that about 70% of the traffic we see is from devices and not human browsers.
That is highly unusual. Most networks get 100% of their traffic from devices running software. But a massive 30% of your traffic comes from humans you've somehow wired up directly to the network? Where do you work, the CIA? The Dollhouse?
... and then they built the supercollider.
Turn the spam filters on the mail servers off for a day. They will really appreciate it when you turn them back on and should be quite happy about the time you save them everyday.
How about asking your customer's what metrics are important to them? Then creating the relevant metric for you derived from the customer driven metric?
Sad but true, I watched somebody give some mockups/samples with real sounding but bogus data to an exec. The executive later used that data in a presentation as if it were real data (*face palm*). Apparently he remembered seeing the mockups and needed that sort of data and forgot it was bogus.
Put giant watermarking saying "SAMPLE DATA ONLY!" or something like that on it, or it could come back to bite your butt.
Cost, money. That's what they want to hear: how much does it cost? What is be benefit? What is the risk factor? What planned next?
The manager hired YOU to know the technical side. Give him enough so he understand the basis of your decision making. Don't waste his time with details unless he ask for them.
- Time spent surfing the web for things unrelated to work
- Time spent surfing the web for things you think is work related
- Time spent trying out new software that is not associated with any kind of formal company effort
- Time spent talking to people about non work related items
- Number of times you sent the executives call to voice mail
Executives see systems this way: Does it work or not? Does it cost money vs. does it give us money.
Your report should look like this: All systems running, no money loss.
Don't you ever bug them with: System X works. System Y has a lag problem. System N is down.. Then hell will brake loose for nothing. And for god sake don't feed them with up-times or down-times.... They don't know what it means.. And numbers, figures, and bars will just confuse them because they will lag a $ dimension.
In order to form an immaculate member of a flock of sheep one must, above all, be a sheep.
"Executives" are interested in money - what earns money for the company, what costs money for the company, what can increase future money for the company, what prevents increasing future money for the company.
Think about the main things you are doing, or plan to do over the next week, month, quarter, year. Which of the four results (earn, cost, increase, decrease) do those things do? Can you mitigate (reduce) the negatives? Can you improve the positives? What are the costs (time, money, resources)? What are the impacts/benefits (save or increase time, money, resources)?
Here's a couple of examples:
"Our mail system is aging and is struggling with the current load. I estimate it causes up to two hours delay per employee per month. I plan to increase the memory and disk space. It will cost $x hundred, and take 3 days to implement. The benefit will be the increase in productivity and delay the need to buy an entire new server for two more years."
"Our finance dept is struggling to keep up with the number of invoices that need to be processed. With the CFO I am evaluating three new systems which can help automate the process. The cost of the system is $x in capital expenditure, and then $y in annual licence fees. The CFO estimates that it will reduce the time to invoice clients from 10 days to four days, and increase cash flow for the company."
So, think in terms of money. Think what business problems or opportunities that IT makes better (or worse). State the problem or opportunity, what you are doing / want to do, say what the impact of your proposal is / will be.
Stick to this basic formula, and you'll soon be seen as someone who brings answers and adds value, instead of the stereotypical geek who complains, costs money and does little of value.
I have never worn a neck tie all my life, that is not to say I am not presentable, my shoes clean, I dress smart casual where everybody else normally wears neck tie.
My professionalism is my introduction card, punctuality, efficiency, attention to detail, etc. is what earn me the respect of my business superiors.
And sometimes my hear is quite long, no pony tail long, but long, but it is clean and combed.
In synthesis your stupid stereotype may not be as applicable as you think.
IANAL but write like a drunk one.
In big companies (what is big to you? I am talking multinational corporations with as many employees as small towns) your bosses know exactly what they want to know and they will let you know.
Nowadays they may be even legally liable to know things in the technical side of the business.
IANAL but write like a drunk one.
In which companies is the same person doing both jobs?
Very small ones I suppose, so even there the big boss would know what is more important in the overall picture.
IANAL but write like a drunk one.
A Sys Admin is not supposed to be messing about with the business data.
That would actually be against the law.
IANAL but write like a drunk one.
This is a 20 person company, correct? Just go over and talk to the guy/gal in charge and ask them what they like to be kept up on. Yours is a 20 PERSON company, there is no bureaucracy to navigate.
... but the quality of the replies is frankly appalling.
The amount of snide remarks about decision makers in any company, regardless of the side, just goes to probe that "the hungry's favourite topic of conversation is bread".
In other words, if you think you are so clever, why are you not running your own company?
The first step to provide important information to your bosses, peers and users is that you approach them with the respect they deserve.
IANAL but write like a drunk one.
No-one's mentioned risk.
You need to have a list of risks (and opportunities); their likelihood of occuring and their impact. Multiply the two to get a factored cost of risk. Sort. (google risk management)
Decide whether you need to accept; transfer or mitigate each and everyone of them.
Certain high-impact risks will need management review regardless of their probability - eg. your datacentre burning down, or anything that could kill/maim anyone.
Initially MGT will fine-tooth comb everything you do but if you get the format
(
As other have mentioned, you need to be able to say
* what assets you have and what their potential and actual capabilities are, plus their financial state
* why you are spending the money you spend;
* how that translates into money earnt and
* what your efficency is - in terms of %availability
* what issues you have that you need MGT to deal with and when
)
For bonus points,
* discover your MTBF and MTTR distributions for all your assets
* start applying a little SPC or PCA to your failures/outages/traffic loads
* write down all you plans/procedures. Backup, repair, training, technology road map. Review and update annually.
Management has been described as the art of making and sorting lists. If you add "scheduling and acting" to that, you're pretty close to the truth
-- Butlerian Jihad NOW!
Listen man, The best system administrator is the one who keeps things running smoothly. I want the most BORING SA report-out ever. I don't want to see graphs and charts with spikes and trends, I want UPTIME. Flat lines. Predictability. If there are problems, face into those and knock them out. Shift that flat line upward once in a while and wow them with your ability to troubleshoot and problem solve. But if it ain't broke, don't fix it, and remember that executives need to focus on other things to ensure you keep your job. Uptime and reliability are paramount from the executive standpoint. Good questions.
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.
This is a great question, you’re at the same point in your career as me.
You need to report on the metrics that measure your departments performance, these are monetary values and I know they may be difficult to measure and it’s not accept to suggest the business wouldn’t run with the IT group. Although this statement is true, it doesn’t address the department’s performance.
Try breaking up what you do for the company into Service Desk, Service Support and Change Management. The number of helpdesk enquiries has value to the business, they’d pay maybe $10-$50 per call if an outside desk was used and even more if administrator would be involved and you’re saving the company money.
Maintenance work in a Service Support role and managing system changes could be related to the cost for a contractor and the reduced cost of running the system versus additional revenue generated by the users to determine how much you’re saving the company money.
That’s the small stuff, now work out (with the other departmental/divisional managers) how much of *their* department relies on IT and relate that proportional of their revenue to the value you support for the company. Especially important to look at sales staff if they use a CRM tool that you support.
If all else fails remember it’s how much your department supports the production side to do or enhance their job that counts then second is the cost you incur on the company.
Regards Sinesurfer A Nerd is someone who lives for technology, A Geek is someone who lives for technology and loves it
All the advices can be summarized to this: Report everything that would make the executives happy and report everything that would make the executives feel concerned. The rest is superfluous.
It's about proving you're doing it right.
If the system is functionally normally, pass on a monthly report and ask for a raise.
If the system malfunctions but you can fix it, mock up something good and stay under the radar.
If the system malfunctions and you can't fix it, let the next guy figure it out.
The flip side of that is if you are staying until 2am and getting no recognition (financial or otherwise) then there comes a point where dealing with idiots who have clicked the 'sort by' heading and think all their new email has been deleted for the 5th time gets a bit much and staying polite is a tough gig. I always try and remember that we all make stupid mistakes. Then I belittle the user...
The alternative flip side is that if you are staying until 2am then you aren't doing your job properly - me I keep plenty of redundancy so I can switch over to keep critical services available and fix problems at my leisure. This means I don't stay until 2am, I fix problems during the day.
My experience is that managers want something when they ask for something - they rarely know the details. Give them a slimmed down version of the stuff you find useful - the overview section of most reports is enough. Once they see it a few times, unless it directly affects 'the bottom line' then they will lose interest, until the next bright shiny rolls past. Don't over complicate for your sake and theirs. Keep it simple and concise.
Yet another rather stupid and very insulting generalisation emerges from the peanut gallery.
If that's part of the change window that's when you work so that a lot of others can work at 9am. Also stuff happens that is beyond your control on occassion, especially if it's somebody else's stuff that you are called in to fix at 2am.