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?

Most of what Shawn says sounds like something out of a text book, not real world. If you give "value added" that needs no training, sure you're a hero. For maybe half a day, until the next time somebody can't print, or has a problem with email. If your "value added" requires training, you're not considered hero, just a nuisance. You can document until your hands fall off and it isn't going to get you ahead. Documentation only works for CYA.

In the real world, Chewd is 100% correct. Management does not notice clean implementations, they notice the extra work to make it happen..

Where does this guy get the contents for this article? And his generalizations on veteran IT Professionals... he obviously doesn't actually get out into the real IT world.

I thought like you until a very wise old project manager pointed me in the direction of business risk. It goes like this:

Business "we want the project yesterday."

IT Project Manager "We can give it to you yesterday but it will be made out of string and duct tape and these are the business risks:

Business process A will fail as the expected uptime is only 65%.
Service and Maintenance costs will increase on the system by 4000% over its life.
It will compromise the security of our mission critical systems.

But if you'd like to sign off accepting responsibility for those business risks we'll deliver tomorrow."

I haven't found a business sponsor who would yet!!!

So how much do you want us to cut our estimates by so they go for your idea?

As an IT department manager the business might listen to you. The point is are you listening to your people. If so, you are very valuable. Rarity alone guarntees that.

It's not you used to think like him, it's now you don't have to.....

19) There is often a non-IT person at the top of the Administrative chain who it still trying to find the "any" key. And he has to approve your budget.

20) At most companies the only way to climb the corporate ladder is to leave IT. And the more technical the needs of the department are, the more likely the manager has never even heard of them.

Today companies insist on ALL managers having business knowledge, and the assumption is that no one can get that while working in IT.

I started my IT career as a mainframe systems programmer (before PCs) at some very large companies. They claimed to have career progression because several application programmers had left IT to work in their client departments, and had been promoted into management. Yet they had NEVER promoted any systems programmer into management. Even the systems programming departments managers were from other roles.

Everything that goes wrong after a project is completed is your fault - because the operations person taking over doesn't understand the system, won't read the documentation and wasn't paying attention during training

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

I was working as "grunt" laborer at manufacturing company to pay my way through college. I hurt my back on the job so they gave me a light duty job. The company had an automated inspection system storing all the inspection data to a huge SQL DB. When I showed them how they could take the data to produce reports for QA/QC they changed my job to IT. Three months later, I had effectively reduced the time the QA/QC staff spent on compiling their reports from 24 man hours a week down to about 1 man hour. My reward? A pink slip.

I'm loving it now because they called me begging me to come back and fix it because someone broke it about a month ago and none of their "experts" can fix it. They wanted to bring me back at my old laborer wage. I damn near fell out of my chair laughing at them. I told them I'd fix it but at my price, not theirs. I'm still waiting for their response to my offer.

Am I wrong to be "blackmailing" them? Probably. Do I care? Not really.

You have a skill that they need.

It's the old joke about the consultant walking into a room, looking around for 15 minutes then taking a piece of chalk and marking an X on a piece of equipment then charging 50,000 for his services.

Management went ballistic and demanded an itemized bill.

He complied.

15 minutes work at 400/hr = 100.00
1 piece of chalk = 0.05
Knowledge of where to plac "x" = 49,899.05

Your knowledge of the systems is worth the amount of money they are losing every minute it is down plus the cost to replace it.

Asking for that in compensation is NOT blackmail, it is business...

good luck

Your loyalty (what in hell is that anymore!!) to that company ENDED when they gave you the PINK slip. Now it is time to pay the piper. Get every cent you can. That will make the cost cutter PAY.

From minimum wage burger flippers to 6- and
7-figure consultants, we're all paid the
value of our labor to our employers.
It always comes down to putting 'x' in the
right place. In some jobs, that's more
challenging than others.

Shame on them, that happens because as the joke said, no one like to pay you for what you know but for the time you take in solving a problem, and in IT, the less time it takes, the better you are as a pro, the better you should get paid.

and amem

There's another story of a mother who visits a concert pianist backstage after a fantastic performance. She asks how she can get her child to play like him and he replies the child needs to practice 8-hours a day. She cried that it would still take her child a lifetime to learn. The pianist replied that's is exactly what it took him.

I used to think what I did was easy and anyone could do it...

until I realized that I made it look easy because of training and experience and my abilty to apply my knowledge to formulate solutions.

Anyone else that had my history and work ethic could make it look easy too -- but many don't.

I bill accordingly.

Your expertise comes at one of two prices:

1) 40 hour work week and regular paycheck.
2) Exorbitant consultant fee equivalent to 3 months of 1).

They chose option 2.
If they regret it, maybe it's cheaper to churn out their reports in 23 more hours of grunt labor.

Here's 17a:

Knowledgebases are not valued by management until the primary editors leave.

I have yet to be fired because I made the company too efficient, but this fear is what makes MOST of my colleagues keep their knowledge to themselves. I'm just waiting for the day it happens.

When I was laid off due to budget cuts, my team was dismayed at how QUICKLY the knowledgebase became rife with obsolete articles and inaccuracies because I wasn't there tweaking the articles.

Technical writing may be the least valued IT profession yet the potentially the most valuable skill around. Every time I solve someone else's problem in 5 minutes, I cut my support costs in half for you. Good technical writing is never rewarded or recognized though. That's why developers write the manuals and they're so seldom useful. (The manuals, not the developers.)

In my last job at a support desk, technical writers were highly valued because they would set up our troubleshooting knowledgebase for the team to use. Since we supported a government agency, there was a crazy mix of VERY old software that was put together by their own programmers years ago - think some old DOS-based and old mainframe programs. Problem was, we were contractors and they wouldn't give us the specs on how many of those programs worked, so the technical writers would glean as much information as possible from the agency's support structure (very unkempt structure) and from us support folks.

as far as how tech skills are viewed by management. The fact is that management is blissfully unaware of who you are and what you do if you're doing your job correctly in any IT profession. It's one of the reasons IT pro's end up on the layoff list so frequently. In my career I've been laid off a large number of times and the resulting chaos down the road because the system isn't being maintained or worse the company replaced me with a hobbiest from marketing because they were cheaper and after all they knew how to turn on their Mac. It's been interesting when they come back asking me to fix the problem. It always costs them much more because my costs go up. One thing to consider if you had benefits and you get laid off well you're either paying for those benefits now or doing with out. In most tech jobs that's a rather sizable chunk of the compensation you're paid. So my calculation adds my current costs which being one human being costs much more than it cost the company who is buying those benefits for hundreds or thousands of people.

> Am I wrong to be "blackmailing" them?

You are not "blackmailing" them. You have a new marketable skill and you are asking for the "market rate". This is capitalism.

Why should they be allowed to get you at your previous rate, now at a significant discount, when they can't get ANYONE to fix it at that rate? If they don't pay your rate, someone else will make an acceptable offer if you look for more opportunities. This is how we IT professionals survive and thrive.

If you want to know how I survived, and thrived in IT, since the mid 90's, let me know. It's a bit long for a forum posting.

I would really appreciate any advice you have on surviving in
IT.
Thanks,
Roberto D. Olivares

I would like to know HOW you survived.

It's great when you build something well and a company thinks that they won't need you afterwards without taking into consideration the future of the product. They will always come running back to you when they do that kind of business. I don't think it's blackmail. I think it's just understanding what you're worth.

It may have been covered, I haven't read the numerous postings here.
Another dirty little secret is that IT fails to budget the required resources for future support on newly implmented systems. This eventually bogs the existing staff down to a matter of pure support rather than innovation and development. Then management wants to know why nothing new is being done.

LMAO!! Go for it dude! They deserve it....it's electronic karma.

Most software isn't priced according to the effort, it is priced according to how much money it saves. You can be comfortable in pricing support accordingly. If they sprung for the support contract initially (keeping you on staff, or having you document to app) this would be a non issue.