Discussion on:

Sanity check: 10 dirty little secrets you should know about working in IT

I've posted my list of them here:
http://blogs.techrepublic.com.com/hiner/?p=546

What are the other dirty little secrets about working in IT that you think should be added to the list?

11)Non technical coworkers will assume that if it's related to IT, you are an expert.

If you're a programmer, expect them to ask you about networking, and vice-versa, if you're a developer, expect them to ask you about support, et cetera...

12) You have no freinds at work outside of IT. IF you're lucky enough to have an ally or two in 'the business' consider yourself lucky, you are a convenient scapegoat and non-IT folks won't hesitate to throw you to the wolves.

13) The business considers you to be a COST center, not a profit center. You need to be prepared to demonstrate your value or you'll be gone the moment there are layoffs.

14) Expect to be out of work, IT is an Ebb and flow industry, when times are good, everyone wants you, when times are bad, nobody wants you. Have at LEAST 6 months savings in the bank at all times.

15) Your IT expertise has an expiration date (based on #14).

Most technologies have a cycle life of 10-15 years, depending on the adoption by the business community. Be prepared to retool and reeducate yourself depending on the acceptance level of the business community.

16)You're only as good as your last project.

17) There is such a thing as "coding yourself out of a job". If you make things to efficient, management might decide they don't need you any longer.

18) If everything goes well with an implementation you go un-noticed. If it fails and you fix it. You can be a hero. The more impact it has the more praise when it is fixed. The more time it takes to fix it the bigger the hero.

and it dovetails with 17 quite nicely.

One of the reason our group got layoffs:

Nothing in the turnover logs.

Since we weren't having problems, we obviously had too many people...

NO, the reality of the matter was that we were so damn good that we knew the systems in our sleep and could correct the slightest hiccup before it became a problem.

The idiots with the huge turnover logs couldn't find their own backsides with both hands and a map.

19) Never give ideas offline (durin lunch break, coffee breaks etc.). A damn idiot Boss would use this as his idea and would get a promotion.

20) As long as you do your work and others work you are a good team player. If you do your work and just give suggestion to the to the needy member then you are not a team player.

21) A boss can pull you into any damn meeting where as you need to put an meeting request and give the notes of the meeting to your boss prior to the meeting. It is better to know why you are called into meeting. Sometime you are as good as a table or a chair.

Some of the replies I am reading seem to indicate that you either hate your jobs or you dislike the people you work with.

To the person who wrote: "Some more Back stabbs"

>19) Never give ideas offline (durin lunch
>break, coffee breaks etc.). A damn idiot
>Boss would use this as his idea and would
>get a promotion.

Wow! Nasty! You should find another job too!

What you should have wrote (as advice to others) is offer your ideas in writing so that there is email evidence that you originated the idea.

The rest of your comments made no sense.

I presented the district IT department with year end ROI and COG. They were the first done. My second year, I did the same - but with two years of data. The district came back with the statement that I had falsefied the report since I hadn't included Support costs. By the third year, I had a HUGE ROI figure accompanied with a very low COG and expense per unit. One of the other schools had me come over and help them prepare the same reports for them. Their report was accepted as a "real" version, my school's was not accepted as it was "not a real representation." The difference was we - like you - knew how to keep the turnover logs down. Very frustrating.

As in the year 2000 "problem". We got reamed for all the overtime worked in 1999 and then there were no problems in January 2000 - obviously a waste of time!

NO - there were no problems AFTER the event because of the work done in preparation BEFORE the event.

yeah there was older hardware that stored dates as two instead of four characters but it was never going to be planes falling out fo the sky and the world bank crashing into oblivion.

It's true that there was many machines that needed to be pached but overall but y2k was a wonderful marketing and business opertunity; remember all the spin off merchandise and novelty "y2k fix programs" that turned up.

"
Since we weren't having problems, we obviously had too many people..."

that is truly absurd. Who are running these companies?

The same people who always have been ? bean-counters who think no mere mortal could possibly understand THEIR job, but are perfectly happy to use management-by-magazine-article for ours. And if that doesn't work, there's always offshoring and downsizing...

Somebody point me to any real, groundbreaking New Stuff in tech for the last couple decades, rather than finding new ways to polish the same old [expletive]? I deal regularly with business folk who simply can't wrap their heads around Web-enabled agile, distributed collaboration. Since they're working for government-linked companies (this is Second World Singapore), they don't have to worry about competition, but dealing with them is painful. Working for them would be more painful, of course, which explains many, many things here.

"chewd" with all due respect, I hope your statement is in jest! Otherwise, IT people like you, give the rest of us a bad name.

Quite the contrary, the longer it takes to fix a problem, the more your colleagues will question your skills.

To re-write (correctly) what you wrote:
"If everything goes well with an implementation, you will go un-noticed. If it fails, you will be noticed but in a negative way. If the implementation offers a clear and noticeable improvement to a business process, you will be a "hero"; especially if you provide timely and well documented training.

Bottom-line, make it work the first time and make it reliable (by testing before going live). Don't expect to be noticed as a "hero" for reliability / low or non-existent downtime. Rather, you will be a "hero" for useful/appropriate constant innovation.

Unless you're working for a disreputable person or company, delivering new solutions that have clear business value does get noticed. It's rarely just one person behind a significant IT project, and leaders who spread the praise and credit around honestly will improve team loyalty and engagement.

If you're implementing technology whose main value is in preventing down-time or doing the same things for less cost or with much greater capacity, a good CIO/IT Director will have a communication vehicle they can use to keep the business aware of these new capabilities. Again, an honest improvement deserves to be noted and recognized.

Title says it all... (Job Role: Corporate-Level / Senior Management (SVP, VP, Senior Manager, General Manager)
Location: Burnaby, Ontario )

I've been at this for 15 years. And it's always the "SVP's & VP's who don't have a clue...

You've provided documented best practices and industry standards, along with experiences of successful and non-successful implementations to the project team and management. But because some business area needs to get 'something' completed FAST, your IT management buckles under political pressure and determins following best practices and established standards would be 'too anal.' The business areas could care less about support and maintenance costs or continuing to throw hardware at a bad design or multiple programming issues as long as the presentation layer looks good and they are able to get it in front of whatever senior executive they're looking to impress -- that is until slow performance or down time hits, then it is an IT issue.

It's exasperating to try to do the right thing for your project, department and company only to be shot-down by the very people who should understand the value of not using bubble gum and duck tape as building materials. This becomes an even greater sticking point when what brought you to the company to begin with was the company's public repetuation for being world class and the repetition of mission statement during the multiple interviews which included phrases like "standards of excellence, best practices, etc.

Well put...

T Mr Connelly.

To do it properly will take three weeks or I can bodge it in two days.

I don't know why I bother asking management this question, probably so I can say 'told you so', when 'you' start wringing your hands at maintenance and enhancement costs.

IT is like a hockey goalie who plays a full season and does not let a single goal get by until the last second of the last game. Then, all the writers and fans can remember is the "one that got through."

IT should be like the utility companies, unnoticed until something happens, and then working like a dog to fix the problem and then no gratitude because we "did our job."

That summer intern who I taught how to fix a pc that the entire company could not fix told the manager SHE fixed the pc when in fact it was me who showed her how to fix it.

So at the comapny meeting in which nobody could fix the computer but only me and I was just teaching her the summer intern got teh praise as I did not know she went behind my back saying she fixed.

If I ever see her again I will slash her tires.

IT's biggest problem is y'all don't know how to communicate with the rest of the business. Learn to market your achievments, and get in early to explain the screwups.

Everyone looks at IT as "dial-tone" if its there no-one cares until they want to make a phonecall and its not.

Communication is the key....

oh and in closing, i'd happily work myself out of a job it would show that i'm able to deliver projects that actually do improve the business.

Do you need to make things work correctly the first time... or do you just need to have your users think you make things work correctly the first time.... I was a sr. network engineer (crossed over from software development) for an oil industry company (formerly CEO'd by the current VP of the USA). Couldn't make cables to save my soul, but every time the systems 'froze' it was ME the factory guys / programmers called. Why? Because I could fix the problem faster than any other network engineer. Since I couldn't make cables well, I'd just send the guys out of the room, wait til they were gone, then jiggle the cable. Presto Chango! No more freeze... til someone nudged the cable again. I got the (undeserved) reputation of being the 'best' network engr around. I never admitted the reason, cause my momma dint raise no stoopid gurrls. heh heh heh... even got me a couple of raises too. (Hey Burnaby isn't in Ontario, it's in BC so if you are gonna lie about your location, at least know how and when to 'jiggle the cable'.)

I am sure you are living in a perfect world or you are damn too inexperienced to talk about this. Oh....you could be a manager who does not know what he is talking about. Do not worry.... a lot of your colleagues do the same as well.

I have executed roles as developer, tester and support. I can tell you this: if you ever deliver a single delivery without a bug, then it often means (to the management) that the work was either too easy or you have got a lot of time to complete the jobs. The measure of efficiency and productivity is a damn joke in IT.

I can't tell you how many times I've seen it. I know of one director, a couple of senior managers, and one "chief of staff." Go ahead, laugh, it's really his title. And each of them got the jobs that they have because "something" would be left out of an implementation on golive, then they would "find" the error, permission change, version mismatch, etc. etc. and they would be the hero.

In one case, I was project lead over system integration for a merger that went without a hiccup, while I was on vacation, with validations done by my backup from the documentation I wrote up. What did I get? An email saying, "Lucky that nothing happened while you were out."

Said Director however did a "nothing" upgrade to the Point of Sale systems causing a nationwide outage for a little over an hour, and when he "found" the max number of threads to the database was too low, he was given a "key contributor" bonus and his promotion to his current level of Director.

Your collegues might know the difference, but the people on the business side will definitely see you as their "hero" and guess who signs the checks?