Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "Every month we submit status reports to upper management. On the infrastructure side, these reports tend to be 'Hey, we met our service level agreements ... again.' IT infrastructure is now a lot like the electric company. Nobody thanks the electric company when the lights come on, but they have plenty of colorful adjectives to describe them when the power is off.

What is the best way to construct a compelling story for upper management so they'll appreciate the hard work that an IT department does? They don't seem particularly impressed with functioning systems, because they expect functioning systems. The extensive effort to design and implement reliable systems has also made IT boring and dull. What types of summaries can you provide upper management to help them appreciate IT infrastructure and the money they spend on the services it provides?"

It's highly unlikely they will care, but try to make it fun and use lots of specific numbers, management types like that.

I was going to say roughly the same thing. Dazzle them with different, huge numbers. Tell them how much business data your SAN is currently backing up to protect it from loss. In bytes. Tell them how much bandwidth your firewall safely filters on average. In bits/second. Sure, after a few rounds they will start to ignore those reports too since they will all look alike, but you will have fun doing it right?

Disclaimer: I am not a corporate drone, this might be a totally bad idea, luckily I don't have t

I used to work in an organization associated, primarily, with aviation. Many of the projects had nothing to do with actually doing any flying but the director of the organization was an avid pilot with a gazillion hours of instrument flight experience. Any projects that offered an opportunity for him to contribute by doing some flying seemed to always get his attention. My projects tended to be simulations or other studies that resulted in a lot of equations, charts, and graphs but no chances for flight tim

I took along a couple of binders of source code [...] that I annotated during the flight with notes about changes to make, places where more comments were needed... boring stuff like that. In the following monthly progress report I noted that my software had been flight tested and the results were promising. The director was not particularly amused.

Well, of course the director was unamused. During flight testing you noted documentation errors and several out-and-out flaws in the code, and then you tried to pass that pile of dreck off to him as "promising". Be honest--your code only survived the landing because the pilot intervened and took control of the aircraft. In the future, maybe you shouldn't try to sugarcoat things.

"We are happy to inform you that as of this month, our IT infrastructure is 100% Animal Cruelty Free!"

The best part of that is the presumption that it previously was not. This is the point at which you are forced to explain to your IT director that a squirrel cage is not, in fact, animal cruelty, but rather an essential safety system. It can only go downhill from there.

"It was a dark and stormy night; the datagrams fell in torrents â" except at occasional intervals, when they was checked by a violent gust of BGP requests which swept through the infrastruture (for it is in the Datacenter that our scene lies), rattling along the NICs, and fiercely agitating the scanty flame of the LEDs that struggled against the darkness."

When I see things like this, I tend to think, you know that everyone times is money, right? So it a report is written, assuming that every is suitably busy, reading a longer report is going cost a lot more than an executive summary.

That said, what I might do is include an addendum that list the major events of the period, maybe a bit of the troubleshooting involved, and the solution. This could be included under the guise of documentation, without actually identifying any single person as the hero. Anyt

``...try to make it fun and use lots of specific numbers, management types like that.''

Be careful, though. Some years ago someone in IT management where I was working invented a metric to be reported to upper management that, basically, was "disk space used". The (boneheaded) idea was that more disk space in use means business growth. The trouble was that when we asked for clarification about what disk space was to be reported the reply was that we were supposed to report ALL disk space used by the system

give them a system that doesnt function how they want. When they complain, give them what they wantprofit!

Bonus points: make the mis-function a small matter of changing the configuration files; that way you can spend a week or two "fixing" the problem.

...on the other hand, I once fired someone for doing that - repeatedly. You can fool the non-techies that way, but if your IT Director or internal customers are gearheads, or you service a development team of any size, you can screw yourself over very quickly.

Jane felt there were too many cables under her desk so she took her scissors to several of them and cut them back to the floor opening.

Our team successfully ran new cables and got the network up and running in the space of half an hour as well proactively took steps to prevent such an occurrence in the future by tossing Jane out the window.

Jane felt there were too many cables under her desk so she took her scissors to several of them and cut them back to the floor opening.

Our team successfully ran new cables and got the network up and running in the space of half an hour as well proactively took steps to prevent such an occurrence in the future by tossing Jane out the window.

Wrong approach. I suggest this:

The slow throbbing of the server room A/C barely distracted from the stifling heat. As Jane sat restlessly in her thigh-length, red skirt, a bead of sweat dripped onto the network cables below. Her display, a pitiful 17" CRT from the mid `90's, flickered a 404 error. Jim, the strong but quiet network repair main, soon knocked on her office door. Despite wearing a workman's coveralls, his powerful frame was clearly visible with each move he made. He casually walked up to Jane's desk, leaned in close, and looked at her intensely with his sea-gray eyes. He said casually, but close in, "Cable trouble. I need to get down there."

The wire wound its way around the steel-hard rod. Electrons pulsed their way up the wire, gently feeling their way through each quantum hole in the wire. As each electron pushed through the wire, the rod trembled with tiny Foucault currents. Each electron made the rod hotter...

What the hell is wrong with me tonight??? If this isn't a sign that I need to get some sleep, I don't know what is. Cheers.

Why is it that they need to be told a compelling story? Appreciation is nice, yes, but is it necessary for them to be wow-ed in every future report? Like OP said, they expect functioning systems and get functioning systems, and people get mad when things don't work right.

Precisely. Does the submitter walk into an office building and think to themselves, "I'm glad those construction worker's knew what they were doing, must remember to send them a thank-you note"? - Of course not. If you want your employer to "appreciate" something you provide then stop providing it, but be prepared to be sacked for your disruptive narcissism.

What is the best way to construct a compelling story for upper management so they'll appreciate the hard work that an IT department does?

In my many years of experience none of this will ever change until a mass exodus of the IT department occurs and all the unappreciated talent leaves. And even then executives will probably never be able grasp how good they really had it because they'll be in recovery mode for a minimum of the next 3 years.

The only other situation I've seen is when the CTO is a really charismatic guy who can describe the most simplest of task in the most interesting way and can play enough politics so people kiss his butt to make sure he's happy. Then the CTO tells his underlings how appreciated they are by the executives even though they themselves never thought to say so.

Another good situation can be if some people in upper management have recently moved from a company whose IT infrastructure was totally borked, to a new one where stuff actually works. That can lead to some genuine appreciation of how good things are, at least until the novelty wears off. Kind of like if you move from a building where the HVAC system is shit, to one where it keeps temperature and doesn't smell like mold, people will have glowing comments about how great the HVAC is in the new building... at

IT Departments fail from the inside over time, and are replaced by mindless outsourcers, contract buyers, and CIO magazine readers. Productivity decreases drastically as the employees are blocked from effectively doing their jobs by infrastructure problems, and no one at the top even understands the problem enough to be upset about it.

It sounds like you're upset because upper management is treating you like infrastructure, rather than the heroes you are?

You made the point yourself - nobody cheers when the lights come on, they get pissed when they go out. IT SHOULD be boring and dull. To an average person in your company, they shouldn't - EVER - care about how or why their systems work.

Do you think providing electricity isn't a difficult enterprise, requiring a huge number of highly-trained people doing a bunch of things right, 24/7? And I bet, a hundred years ago, people looked at people working in "electricity" the same way people looked at "IT" twenty years ago.

It's not 100 years ago. It's not 20 years ago. And we're not heroes or geniuses. We're plumbers. (Except that we're too dumb to unionize.) If anything, we are incredibly lucky that our uses are satisfied with the - in most cases - poor level of service they receive. Think about it - in all the time you've worked in IT, how many times have you seen the electricity in a building just go out, without explanation? Now, how many times have you seen major server outages, costing more than a million dollars in lost productivity? For me, I have never seen an electrical outage not related to a major disaster that kept everyone out of the building anyway. I have seen at least 5 outages that led to $1m or more in losses - and three of them were for stupid, easily preventible things. (Really? You upgraded both the primary and backup SAN at once, and killed the entire network for six hours when the patch turned out to not run properly?)

Take another look at your question. It's premised on the proposition that IT SHOULDN'T be boring and dull - which I disagree with entirely - and that IT should get more appreciation than it does, which is questionable at best. What's driving you to ask those questions, in that way?

Uh, I live in the USA, and I've worked in IT or other fields in three different major metro areas, and a dozen or so smaller areas. I've never - NEVER - seen this happen. I'm not saying it never happens, just that I've never seen it. Major, crippling IT outages happen all the time.

I even live in an area right now with a power provider to my home (Pepco) who is absolutely awful. Never seen an electrical outage take out an office I worked at.

Uh, I live in the USA, and I've worked in IT or other fields in three different major metro areas, and a dozen or so smaller areas. I've never - NEVER - seen this happen. I'm not saying it never happens, just that I've never seen it. Major, crippling IT outages happen all the time.

I have held my current job (I am also in the US) for about 2.5 years, and in that time we've seen 3 non-disaster caused blackouts. I work in an office park in a small city.

We have seen around 10 service-provider outages impacting WAN, internet, or both. At least 1 of these outages was caused by a major disaster.

We have had 1 internal issue that could be characterized as a "major, crippling IT outage."

Keep in mind these comments are all anecdotal, as are yours. I do agree with your premise that IT

And transformers. And lots of electronics to monitor things, all geographically distributed. And interconnects (with lots of transformers), which will be remotely controlled to shunt power between sub-grids. And fancy algorithms to monitor demand, and weather, and predict future demand, and start bringing generators (and sometimes entire plants) on- and off-line with enough lead time to meet actual demand. And the bringing of generators on- and off-line can be a very complex process in itself.

not to mention banks of giant capacitors to keep your voltage and current in phase, reclosers and other safety systems to enable quick recovery from interruptions due to small trees or animals on the line, and humans who can respond quickly to more severe and dangerous problems.

AC OP has overstated the simplicity of the electric grid but his main point is still valid. Power is a bit like cable TV, everybody gets the same subscriptions. People don't care what power plant has generated their energy. As long as power is available within certain parameters it's good. People do care a lot which bits they receive from a network. If they get their colleagues email instead of their own it's mostly worse than not getting email at all. The storage and processing of information is continuall

Nice to see someone who gets it. I've been in the IT infrastructure business for many years now, and I think that plumbing, electrical, or another skilled trade is exactly the right analogy.

That said, the answer to the question that I've found is that the compelling story you tell about infrastructure is all about the future. Specifically, how you plan to evolve that infrastructure to support the changing IT environment and needs of the business while staying within reasonable and predictable budgets. 'P

Nice to see someone who gets it. I've been in the IT infrastructure business for many years now, and I think that plumbing, electrical, or another skilled trade is exactly the right analogy.

The problem with that analogy is that plumbing, electrical, and HVAC are all extremely front loaded costs with relatively fixed (predictable as you said) long term expenses.

IT is a constantly moving target, subject to hardware refreshes every X years and likely software refreshes every Y/X years.And no one ever said "hey, we can cut back on the maintenance for our HVAC because what does that guy do anyways?"

Think about it - in all the time you've worked in IT, how many times have you seen the electricity in a building just go out, without explanation? Now, how many times have you seen major server outages, costing more than a million dollars in lost productivity?

Uh, my infrastructure has a MUCH higher uptime percentage than the local grid, we've had to send home the entire main campus workforce 3 times in the last 2 years due to power issues, we've had to do that once in the last 8 years due to IT issues (SAN

Coincidently the electricity went out at my home last night (after the pole went off like a giant bug zapper). A truck turned up within 30min, someone had told them I had seen sparks so they knocked on my door to ask me what I had seen. The lights came back on soon after. it was cold and raining pretty hard, I put a jacket on went up to where they were working and shouted "thanks gents", the enthusiastic reaction from the group of wet and miserable men told me it doesn't happen to them everyday*. It's not h

Yes, IT infrastructure is complex. So is electrical, HVAC, plumbing. As with those jobs, some of the work is simple maintenance that can be done by almost anyone who has received the proper training, some requires large amounts of experience or talent or both.

The relative complexity of the systems depends on the installation. For some engineering firms, the IT infrastructure may be quite complex relative to the other systems. For some industrial applications (lik

This has never been my experience. This sounds like the kind of thing a lot of people SAY happens - but I've worked at enough places, in and out of the server room, that I question whether it actually DOES happen. Does IT need to justify its budget? OF COURSE. Everyone does. Every single department, every year. But in most places I've been, IT budgets go in one direction only - up. (And in the federal space, where I've been working recently, they go up hugely, for a terrible product.) And I've never been in

That's kinda backwards except at unusually ignorant companies. When a system works without fail, that means it is properly funded and staffed. It is possible that it is over-funded and overstaffed, so it is something that would likely be reviewed. But, few managers thing that a system that crashes regularly is normal. That would indicate incompetence or or possibly good people not allowed to do their job. So if a good system deteriorate and it correlates to changes in staffing and/or funding, that woul

Ignorance of good computing practices thankfully isn't quite as dangerous, but it can become very expensive when someone decides to copy confo-info data to a personal system "to work from home" or the like.

Execs know the job of IT is to maintain systems and to increase work-efficiency through collaborative technology.

Instead of being boring "yeah everything fine, piss off" announce internal initiatives and goals that even a commoner can understand. Talk about important milestones or stories of exceptional (and actual) personal achievement. If you track your hours, announce how many man-hours were placed into a particular project. Show me the numbers.

Execs know the job of IT is to maintain systems and to increase work-efficiency through collaborative technology.

Instead of being boring "yeah everything fine, piss off" announce internal initiatives and goals that even a commoner can understand. Talk about important milestones or stories of exceptional (and actual) personal achievement. If you track your hours, announce how many man-hours were placed into a particular project. Show me the numbers.

If you fall into that "we work hard" crying bullshit, fuck you. My cat works trying to get that god damn dot with no results. I want to see results that people OUTSIDE OF IT actually like. If you did something that took 5,000 hours and everything sucks and the users don't like it... why did you do it in the first place? That's when the inquisitions start.

And include metrics like hours/money saved by efforts, improvements to the corporate bottom line. Metrics about improved efficiency. Metrics showing things like help desk calls by technology. THEN you make the pretty graphs. You could work on some initiatives like providing dashboarding for anything THEY think is of value so they can just look at nice green and red buttons on a single screen.

I'd also like to suggest examining the users that have submitted the most (non value) Help Desk tickets to see if y

Once upon a time, there was a filing cabinet. This was no ordinary filing cabinet, for it sat beside a large server rack, and every day it gazed longingly at the shiny, blinking machines and wondered what it was like to be in the cloud storage business.

What the Highway Department's chief IT guy for the new computerized roadway hated most was listening to the 'smart' components complain about being mixed with asphalt instead of silicon and made into speed bumps instead of graceful vases, like the one today from chip J176: "I coulda had glass; I coulda been a container; I coulda been some bottle, instead of a bump, which is what I am."

I don't know how you tell compelling stories getting into actual details without jargon and descriptions that will probably cause management to shut down and stop listening. ("He's going on again about some electronics crap I've never heard of...")

But one can easily create analogies. Your infrastructure is like your house, for example. You need to maintain the shingles on your roof, paint the wooden siding on your house, caulk up the cracks when they appear. Occasionally, you get a rotten board and yo

If the IT Infrastructure is working, then why are you needed?If the IT Infrastructure has problems, why are you not fixing them for what we are paying you?

Many companies despise the IT dept because it doesn't generate revenue. It's a parasitic requirement knowing they must sink money to maintain and keep up with the rest of the business world. Queue the worlds tiniest violins.

Give out an annual award to someone on the IT staff who jumped on more Severity 1 tickets than anyone else. When everyone else wanted to be in bed asleep, this person was the one who tirelessly answered the pager and ran into the burning buildings to rescue the crashed servers. The holder of the award is your best first-responder. Having this plaque on the wall reminds management of the crises that were resolved in heroic fashion.

Sure, there's no award for the person who prevented drama from happening in t

From Slashdot, or any other place where people complain about horrible incidents that should have been prevented, but weren't (e.g. lack of power backup plan takes local hospital offline for hours, or severe data breach costs local company their customer's trust.) Of these stories, keep a list of the ones YOU took the appropriate steps to prevent. Then tidy these numbers up into a graph that shows the total number of potential incidents versus your total number of actual incidents. The ratio should be goo

Start with, what is the hard work that you're doing, and why -- specifically -- are you doing it? Installing patches? Writing scripts? For what reason? And never just "because that's what we do" or "because that's just what you do to keep things good" Describe everything as "What we did" -> "Why we did it" with a specific goal for each action. "Installed Acrobat and Java patches to keep desktops secure against 4 new exploits found this week." "Wrote a script to deploy patches in an automated fashion to r

Having produced these for many years, the compelling story management wants is how your department impacts the overall business.

Tie your report back to the business because that's the only thing management cares about: people, time, costs, risks, major or significant projects / changes, future plans to improve the business or reduce costs and risks.

Develop metrics so that you can show how well you're doing on your current SLA's, downtime, hours / incident, etc. You can provide a graph week over week

You talk about something the listener wants to hear. Things that interest them.

It's simple in principle but tough in practice because you need to know your audience. The only way to do that is to listen to them. What are *they* talking about? What are they trying to get the company to do? Use that to frame your story. So if it's trying to cut costs, tell them a story about how you successfully cut costs; or even better, how you *failed* to cut costs and but then later on figured out a better way. If they're pushing some management theory, show how you are putting it into practice, and how it's going to solve some long standing problem you've been struggling with.

There's not a "clear bright line" between effective communication and kissing ass. Superficially it looks much the same because both involve getting the audience to connect your story to something significant to them. The difference is in what you intend the audience to take away. If they come away knowing something about IT they didn't know before, that's solid communication.

Communication requires some shared frame of reference; a common model to which the symbols you are exchanging refers. I learned that on the first page of my data communications theory text, and it's true for human communications too. To communicate effectively with an audience you have to speak in their language. If you don't, everything you'll say just sounds just blibber-blabber to them, even if they're a *smart* audience.

That's another simple-sounding principle that's hard to put into practice. If you want to communicate unfamiliar information to someone, you have to bridge the gap and familiarize yourself with their mental landscape. Imagine a cosmetologist is tasked with explaining to you how to select and apply make-up. If she talked to you the way she'd talk to another cosmetics geek, you wouldn't learn anything. If she related it to something you already understood, like the OSI network stack or the 3SAT boolean satisfiability problem, you might learn something. But it would be a lot of work on her part; it's a lot easier to pretend you understand what she's talking about and hope you come away with something.

We work in support services - unless you are an IT service provider you aren't part of the business that makes money. You support the business, but you aren't the business. Think about all those other support functions, HR, finance, legal, office facilities - they are all needed too but I don't often hear them asking to be appreciated by management.

To the OP - What is your objective? You say you want management to "appreciate the hard work t

it's possible to have service level agreements about things like uptime of a service that is wholly managed by a provider that are sane. Things like how much is guaranteed before payment is reduced or no longer expected.

However that's not what IT departments deal in. No IT department starts losing funding if they fuck up the DNS infastructure for 2 weeks. No IT department loses its funding if they fuck up the spanning tree for the 5th time in a single year.

- If your team worked their tails off to make sure things ran smoothly...tell them what you did to make it run smoothly and why it's helping.- If your team kept the lights on and averted disaster in some way...tell them what your excellent monitoring facilities helped to detect in advance and exactly how you prevented the problem before it started- If your team responded to tickets / infrastructure requests from development and helped other teams reach their goals...tell them how you did that

Is it so much of a stretch to not just say "Well, nothing died. You need not know why." and actually tell them WHY everything runs so well?

In company meetings and reports you aren't supposed to be humble. You're supposed to brag on yourself and your team because whoever is giving the report is the sole advocate for why your team is valuable. If you have somebody who is not doing that, then you need somebody else representing your team at these meetings.

Start billing other departments. No seriously, track projects and maintenance tasks to a bare minimum so you are able to do some mock calculations how much you would cost if you were outsourced. That is the only language they understand.

Agreed, just do the metrics of what it costs to run your workload on Amazon, when the Amazon price becomes cheaper then look for another job... This is the way it will go as IT infrastructure is a utility, nothing more. Now if you are doing specialized IT (HPC, healthcare, R&D) that can't be easily moved to the "cloud" it will be staved off a few more years, but in the end I would expect 90%+ of all computing to be done at large data centers that sell cycles... After all it is the bean counters who tend

Have you noticed many businesses use AWS and on despite that, they still have IT people? The point is really IT is seen by many only as a cost center, just because often they do not keep tabs on what value they bring to the organisation. "Billing" other departments could be an interesting exercise. IT also boils down to your size, if you are a middle to large organisation, it is not wise to go without your own IT services.

"We process an average of 120 helpdesk tickets a day, with a mean time to resolution of eight minutes."

And so forth. I've also seen reports on capital equipment vs overhead, trending over the last X number of years. It's useful to show, for instance, that the majority of your costs are not personnel related, lest upper management get the idea that they could save a buttload of money by outsourcing personnel to a bunch of taxi drivers in Nanjangud.

Customer satisfaction surveys could also be important, especially if they're substantially better than, for instance, the average customer satisfaction for offshore IT...

As others have said, the less visibility you have the better. Mention things like how your system is not vulnerable to something like Heartbleed when the execs read headlines, then go back to playing minesweeper.

Infrastructure should be boring. Cheer the boring. If there is a time period where things just went smoothly, put a big exclamation point on it. And, then list why.

Things like clean failovers.System patches without downtime.

One other thing that is a pain at my company that you could also show it provisioning speed. When requests come in for VMs, or hardware upgrades how fast a re they served. How many are queued, how many are awaiting management approval, waiting on vendors, waiting on quotes, POs, etc

IBM has lots of smart people who try and do this. What they've found across their client base is that

IT spending = minor adjustment * vertical percentage * revenueminor adjustment is company specific level of enthusiasm: usually.5-2.0vertical percentage is a percentage of revenue spent across the verticalrevenue is the company's revenue.

Why do you give status updates? What does it tell them? Nothing. That is why they are so bored.

What they really need to be able to do is 'manage'. Giving them status updates (about service levels) are not the information they are looking for. Managing is about achieving a goal having certain risks and costs. Your goal is having happy customers about the service you provide. Even though that is formalized through SLAs, that will never be why a customer stays or goes.