Slashdot Mirror
Ask Slashdot: How Do You Tell a Compelling Story About IT Infrastructure?
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?"
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 hate sigs.
give them a system that doesnt function how they want.
When they complain, give them what they want
profit!
have you seen my sig? there are many others like it but none that are the same
Talk about how servicing web requests pounded your application servers long and hard during peak hours.
You can't cut back on funding! YOU'LL REGRET THIS!
Try this one:
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.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
If you can relate the work to how it is saving or making the company money that would likely be well received.
Hire Morgan Freeman or Patrick Stewart to read your presentation. They can read a phone book and still give folks pleasant, comforting feeling, reassuring your audience that all is well.
Or if you need to terrify the motherlovers into never crossing you, get Samuel Jackson.
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.
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.
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?
WHY WON'T YOU LOVE ME, CHIEF DADDY OFFICER?
Pay attention to meeeeeeeeeeee!!!!!!!!!!!111111eleven
Don't listen to all these bitter pricks.
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.
How do you tell a compelling story about IT infrastructure?
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.
How's that, OK for a start?
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 you replace it. You get a leaking roof and you patch it. Occasionally, you need to deploy more extreme measures when the rats get in or termites are in the walls -- but if you put out the bait traps first, you might avoid expensive repairs to begin with.
Is it possible to do nothing on your house for a little while and it will keep functioning? Sure. But the longer you go without painting the siding and patching the roof, the deeper the problems get as wind and water and mice and termites start eating away... and suddenly you're stuck taking out a home equity loan just to do repairs.
I don't know if this is the kind of "story" you're looking for, but you can probably come up with some sort of analogy using anything that requires regular maintenance to explain what you're doing. It may not be the kind of language you'd use in an official report, but if you're chatting with the management, it can at least get across the necessity of the kind of work needed in the background to keep stuff working.
To this "story," you can add the use of graphs and visuals. "Look at this trendline -- this is how much money we start to lose if we didn't do X, but we implemented a new policy, and now look at the savings!" Emphasize measures of "efficiency," and make comparisons to what would happen if you didn't pay attention to whatever routine things you do (with graphs illustrating the difference).
Visuals + compelling (though potentially inaccurate) analogies in plain language will generally get your point across to non-tech specialists.
http://www.youtube.com/watch?v=UTBsm0LzSP0
"Kill 'em all and let Root sort 'em out"
Churn the network, storage and server vendors to constantly reduce costs. Money talks.
I have never seen an electrical outage not related to a major disaster that kept everyone out of the building anyway
Oh, man, that must be nice. In the USA we have outages every few months as there's no redundancy on the grid.
and that IT should get more appreciation than it does, which is questionable at best
While it's silly to need such appreciation, humans do. Do they want to get accolates from the CEO? Just tell him that employees who feel very appreciated will work for up to 20% less. True story - it's fiscally irresponsible to allow any of your employees to feel unappreciated as they will demand more money and have lower productivity. And also it's not very kind, but if your CEO is a high-functioning psychopath, that doesn't carry much water.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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. 'Predictable' can not be overemphasized.
At any time, you should be able to tell the business managers what your infrastructure will look like in 1, 3, 5 years, what that will cost, what alternatives you have considered, and what the major risks are.
The problem is that if it runs without issue, then there is a tendency to assume that IT is just doing nothing, and the top brass will start cost-cutting by dropping headcount, outsourcing jobs, and so on.
Pennywise, pound foolish, but that is how a lot of companies work.
Infrastructure is boring and complicated. It's like a bridge: it takes smart people, good engineers and science to build one, and then ten-thousand people a day drive across it and most never notice. To really appreciate it, you need to have a great deal of specialized knowledge.
Your management doesn't care. They care if the bridge falls down, but not if it stays up. So, change the conversation. I bet there's a ton of stuff you do that they -do- care about. Have you saved money? Have you delivered a new business intelligence metric? Have you made the office environment nicer to work in? Have you automated a process and saved some labor hours? Have you made sure all the higher-ups have the best new tech gadgets?
Your management cares about the core business operations. Learn from them what they think about, what's on their minds. Read the same trade journals they do. Learn the buzzwords. Then proactively think of IT solutions to business problems. If your IT department isn't cash-positive, think about how it could be.
If all you really do is infrastructure, you're boring and replaceable. Strategically locate yourself closer to the center of the business, get off the fringes, and participate. That's what will get you seen and appreciated.
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.
Life is not for the lazy.
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 the first place. But that's kind of the way it goes with heroes.
$5 / month hosted VPS on linux = awesome!
to do it for less money.
Check out this Forbes web-article re: "The Way Americans Die" as (what I beliueve) is a fastastic way to convey (boring!) information in a web-based compelling way: @ http://www.bloomberg.com/datav... If you view-source they are using D3.JS to do the charting (in a great way, I proclaim) Thats what guys like me 'do' if you need help in creating such a thing. I say this is how 'all' info will need to go to management, eventually (but inside a mobile-tablet app) over a secure connection will become the norm over time. Just my 2 cents. Cheers //GH
Months since someone made us your problem: 3
Months until our budget must go up 8.67%: 7
Months until somene makes us your problem if we don't get our budget increase: 8
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.
Your second point is a good one, though one that's easily generalizable. EVERYONE should get more appreciation than they do. Janitors work a lot harder than I do, their work is worse and they get paid a fraction of what I get paid. But boy do I bitch if I come into an office that looks filthy. (Although, to be fair, I do go out of my way to say thank you.) So, yes, it's true, IT should be more appreciated. So should everyone else.
And - if we're being honest - then we should ask ourselves if, in general, we deliver a product that's so good that we deserve commendation for it. In my experience, this is rarely the case. In the industry - IE, when talking to other IT people - we know the difference between a good shop and a bad shop. But for someone on the outside, 99% of IT shops provide a bad user experience. We're ALL bad shops. So yes, it might be better to pat the plumber on the head - but honestly, if I'm the CEO, I really just don't have time to salve the feelings of a whiny plumber.
sorry spell-check greg, spell check "what I believe") LOL
No, it's because management is likely to treat them as disposable and excess expenses that need to be cut. Being boring and dull is not necessarily cheap, it can be quite expensive, and to the average person, they don't care, even though they should realize that somebody has to care.
And no, the submission didn't indicate that providing electricity was easy. They indicated it was thankless when it worked normally, but only when bad things happen do people care.
So yeah, the question is actually premised on the opposite direction than you think, and the driving force is probably a thoughtless management that wants to be dazzled or it shuts off the money tap.
You will rue the day!
RUE!
Never answer an anonymous letter. - Yogi Berra
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 a functional company where the people making the budget decisions don't recognize that infrastructure has value.
The best IT shops - the few and far between where things truly "run without issue" (and I've never been in such a place, though I was in one or two which were pretty close) are like that because management DOES recognize the need for the proper investment and support for these mission-critical systems. Frankly, I'd LOVE to see a counterexample. While we love the idea of the bastard systems engineer who keeps his systems running like clockwork despite being hated and despised... that's not the reality. If things are working well, it's because there's support at every level.
Again, your mileage may vary - and if you have been in a shop where this was in fact the case, I'd love to hear the actual story.
But the OP didn't suggest that the money tap was being shut off - just that they weren't getting their RDA of head-pats.
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 good, if things are boring.
This puts it in concrete numbers that you're doing your homework and preventing the fires from even starting.
Occasionally living proof of the Ballmer peak.
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 reduce the risk of errors during deployment that would lead to downtime." "Added 10 TB to the SAN to provide necessary amount of redundant storage to meet current needs." I mean, some of the stuff will never sound exciting, but if the reasons you're doing them are understandable, that should help. If you're lucky, some of the things will be exciting with a big payoff: "Wrote a new bookkeeping app to cut the time needed to process timecards by 50%."
In all honesty, it is like trying to describe what a utility does, or what any normal person would do in their day-to-day life. "Replaced carbon in filter to prevent people from getting sick from drinking water." "Put gas in tank so I would continue to be able to drive places." "Cleaned my room to make it easier to find things later when needed." Maybe not exciting, but if it's understandable, that's a start. For everything you do, there needs to be a result, and the result should either be a benefit, or a necessary action to maintain a certain level of functionality. Spell it out every time.
Yes, it'll sound to yourself like you're just finding 100 different ways to say "I did my job because it needed to be done", but if that's what you need to do, that's what you need to do. I have to do the same kind of BS for my yearly job-performance stuff -- setting goals and then assessing myself. It's painful because my job just boils down to "Do whatever my boss says needs to be done", but I have to phrase it like it was my magical idea to get data from one system into another. "Created and implemented a plan to move data from A to B so the accounting department could continue to function" -- ugh. But it's what they want to hear.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
...but nobody ever reads those.
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 to show improvements. You can also show how user / customer incident volume goes up over time, and how much time you're spending on specific projects.
Specify new goals - "reduce SLA response by 5%", "build new system to mitigate this new risk you guys made"
Your in the drivers seat to show how you're doing the best for the overall business.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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 time. One day, to pass the time during a flight to Washington, I took along a couple of binders of source code (printed on the old green bar paper, of course) 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.
CUR ALLOC 20195.....5804M
If you're primarily focused on meeting the letter of "service level agreements", IMO you've already entered what I'll call "metrics hell" -- a desolate realm where meeting some (more likely than not) ill-conceived measure of "performance" takes precedence over actually helping your users get their jobs done more efficiently. Closing helpdesk tickets within some predefined timeframe is meaningless in the grand scheme of things if you haven't actually solved the users' problems.
So...bear with me here:
- 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.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
xx
Bukowski said it. I believe it. That settles it.
Engineers are great at math but you need someone who excels with language.
Competition Good, Monopoly Bad.
I really, really, really hope you're just joking/trolling. Because if not, I think "electricity is just wires" is my next "the internet is a series of tubes". :-)
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.
baffle them with bullshit.
- W. C. Fields
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 meltdown due to poorly designed switches).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
99.998% uptime, 974 exabits moved without error, 56 firewall intercepts of phishing variety, 12,467 blocks to blacklist sites, 14,273,996 successful shopping cart transactions with 2 abandons, 67 helpless desk calls with cust satisfaction of 99% on survey, 3 new C-level gadgets installed of 3 requests, projects on or ahead of schedule... aw, what the heck, 2 BOFH reports and 3 replacements hired...
if this is supposed to be a new economy, how come they still want my old fashioned money?
Electricity is, outside of the actual generating plants, just wires.
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.
And I don't even really know anything about the power grid--I'm just a consumer. So you have given us a shining example of the classic IT nitwit arrogance: "anything I do not do is trivial" ;-)
"We have twelve thousand users accessing our resources daily. Those resources have collectively exhibited a 99.997% uptime.
"We see nine terabytes of data flowing through our networks on a weekly basis."
"We manage nineteen B2B connections representing 22.5 million dollars a month in company business."
"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...
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Hi there, in the month of April, this is what we saw:
1. 248,000,000 spam killed at our outer gateway that never made it to employee inboxes.
2. Major security announcements verified in April: Heartbleed, we use our scanning tools and have verified that we have no exposure to this issue.
3. No down time in messaging, payroll/HR/Finance systems.
4. Moved 250 separate pieces of code into production across various systems.
5. Completed IT installation at new facility X.
6. Etc.
Give them numbers that don't mean a lot, but show that stuff is happening.
My mom says I'm cool.
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 systems seem to experience significant outages somewhat more frequently than utilities do. I would explain this by noting that IT infrastructure is generally a little more complex than utility infrastructure (though usually on a dramatically smaller scale), with less reliable hardware and significantly more frequent changes.
I will street the day? Damn you French-Canadian wannabes.
Just start your presentation with the line "And then this one time, at band camp..." and you'll have their undivided attention.
Ken
A compelling story? Okay, I'll get it started for you all:
"On a dark and stormy night, as the release deadline loomed..."
Disclaimer - I run a team managing datacentre installations / removals for a blue-chip IT company. I'm also a CDCD and a CDCMP
First of all - do you actually want management looking at what you do that closely. The best departments should be along the lines of 'you need to fund this many heads or else bad things happen'. If you want to put numbers in front of them you can talk about DCiE / PUE, and point out that the multi-million energy costs actually went down in relative terms due to adherence to best practices. You can also talk about ASHRAE, the EU code of conduct for datacentres, and every other 'badge' that you've signed up to as this makes management feel happy and they have something to compare with.
If you really want to make a point then talk about just how many other projects across the company relied on your team to deliver new infrastructure or services, how much new revenue was based on your hard work.
Of course, the longer you do the job the more you realise that all the awards and accolades end up with the guys there at the end of each of the project. And they all conveniently forget that it's your team that's installed 200+ servers, laid 50km of data cabling, and connected every single system correctly before the application guys could even start their job.
On the other hand, you have job security, you have one of the few jobs they can't outsource to India, China or Poland, and provided you keep your nose clean you'll still be there when they turn the lights out. So be happy being considered part of the furnture because in todays society the benefits of your job security far exceed any need for recognition.
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.
mindless outsourcers, contract buyers, and CIO magazine readers
In other words jobs and people you know nothing about, sort of like how executives know nothing about network infrastructure, right?
Disclaimer: I'm not "picking on you", I'm acknowledging you are human.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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?"
[Fuck Beta]
o0t!
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 hard to put a bit of cheer into someone's day, especially when they are having a rough one and still get the job done, but don't fuck it up by expecting, me to go out in the rain and thank you for doing your job.
* I already knew that - the first half of my working life was day labouring and blue collar jobs, if you have never been part of the "working class" then you don't know what "underappreciated" feels like. After 15yrs "digging ditches" the first thing I noticed when I moved into an office job was that people said please/thanks just for doing your job. I know they don't really mean it, it's just good manners.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Meanwhile, the janitorial staff are over on their blogs asking "how can we present a compelling story to management?"
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... That is also a great thing to show improvements on. Because if infrastructure is slowing new money making projects from getting off the ground then that is a problem. And, those projects are going to move to cloud services in an attempt to get around infrastructure for good or ill.
Move over to the Engineering/R&D en masse, then they'll really appreciate your work when nobody is doing it (or at least doing it correctly).
Have a squat over at the hobo house.
Wish I had points to mod parent further up.
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 (like chip fabs), the environmental control may be extremely complex.
I'm not saying this to diminish IT, it does require excellent people who put in a lot of effort. Its just that other infrastructure support also requires very skilled people, they just happen to have to literally get their hands dirty.
Those who truly remember the problems when "the lights were off" are happy when the lights continue to remain on without incident for long periods of time.
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 * revenue .5-2.0
minor adjustment is company specific level of enthusiasm: usually
vertical percentage is a percentage of revenue spent across the vertical
revenue is the company's revenue.
Why do you give status updates? What does it tell them? Nothing. That is why they are so bored.
... You notice that I put the word management behind every aspect. That is because all these aspects require activity on your part (and choices are to be made). Choose your aspects in a practical manner (lets say between 20 and 30 items).
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.
The reason that it is difficult to tell anything about the 'process' 'providing service' is because it is a very undefined business process requiring skills on all sorts of areas. I prefer to say something about the aspects of the process. These may include e.g.: security management, incident management, hardware management, external supplier management, hr management, personnel knowledge management, building management, computer system management, release management,
The next thing is that you identify the following for every aspect: You describe shortly the current situation (e.g. operating system mgmt: We are running Debian Wheezy with automatic updates on wednesday because that is our service maintenance window. Sometimes packages are necessary from upstream). You describe the 'ideal situation' (e.g. for personnel knowledge mgmt: We would like all tasks to be able to be completed by two persons because people have holidays or may be sick. We have weekly knowledge sessions). You describe already known issues that need to be fixed. And lastly you give a grade: 1-5 if this aspect is a risk getting you goal achieved and 6-10 if you are (firmly) in control of the aspect. Remember: A 10 is probably a waste of money and other resources.
If you covered your area well, described all relevant aspects, you will then get something new: You are able to identify the largest risks (even if they did not go wrong) and unique selling points. In 9 out of 10 cases you will realize you are far from done with your work. In the 10th case you realize you can do your job with fewer people. When you have identified your aspects you should (partly) report on that.
Btw A great marketeer once held this speech. Since you are presenting something you should know a little about marketing (which is about making people enthousiastic).
nosig today
"This month, we set up a new system for department X that helps them accomplish task Y in 50% less time"
Work to build an understanding of senior management business objectives, work to align your scorecard to key business goals and initiatives and focus on performance against these in your report, senior management will be able to relate to your contribution and may start to see IT as a value partner in achieving business agility and industry leading performance instead of as a utility provider.
it might be tough to start with as you will be starting to report on their expert area and from time to time they will have a different perspective on success to you but if you declare what you are trying to do up front then you can likely buy the cooperation of a key business sponsor that can help you speak their language and make it work.
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.
http://yro.slashdot.org/story/...
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 continually changing to adapt to needs of all kinds of organisations and people. If you compare the number of people working in electric utilities to the number of people working in IT I'd say IT is about 10 times as complex.
utility workforce http://energy.gov/sites/prod/f...
IT workforce http://www.globalization101.or...
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.
If you must moderate, please moderate as irrelevent, not something bad, because I'm sure someone will find this interest
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 would be noticed. If it isn't noticed by higher management, IT management should have the metrics to make a report showing it over time. I know correlation isn't causation, but it makes for a decent argument.
If you must moderate, please moderate as irrelevent, not something bad, because I'm sure someone will find this interest
Like the electric company, yes, you should strive for 100% uptime. But that should be a footnote in your report. The main report should show how you have leveraged IT to lower costs in other areas, make the company more efficient, and you've improved the customer experience in a meaningful way. Stop thinking your job is to keep the computers running. Start thinking your job is to help the company run better.
What have you done outside IT today?
LOAD "SIG",8,1
LOADING...
READY.
RUN
And whoever modded that as "troll" is clearly an idiot. Read BOFH sometime.
it strikes me that if you have to ask, there probably isn't a compelling story to tell. why do you feel a need to tell one? the best IT is an IT that no one is aware of. IT *should* be an utility. if it's not, you're not doing your job.
Tell them that the XYZCo. just hired 5 more workers, increased uptime by 5%, AND increased ROI by 12%. Hell, use my numbers. Unlikely they'll know how to check.