Learning to Say No in the Workplace? 723
Ummagumma asks: "I'm trying to find out how those of you who work in the IT service industry, tell customers 'no', when the requests are unreasonable for whatever reason. There is a culture here of 'piling-on' work with regards to IT - and, unfortunately, I've never learned the proper way to tell people 'no'. It may sound simple, but in this economy, where jobs are tough to come by, I don't want to be seen as the impediment to getting things done Any suggestions on telling people that their work request can wait? Especially in a way that won't jeopardize my future here? I've searched the web, but most of the sites that supposedly have information of this type just want you to sign up for their seminars. I'm looking for actual, real-world experiences, and how the people of Slashdot deal with this issue on a day-to-day basis."
"Here is my dilemma: I'm a relatively new employee (~2 months) at a software engineering shop. I am the sole IT person for a 100+ person company, with 50+ remote VPN users, 40+ developers, 30+ servers, firewalls, etc. I do it all, from desktop and application support, to security, to servers. In the past, the IT department has been seriously under-funded, and there is an absolute ton of catch-up work that needs to get done. At this point, I could work 70+ hour work weeks for a year, and still not be caught up, between project work, upgrade, documentation and day-to-day stuff.
I've inquired about more IT budgeting (staff, equipment, etc.), and that just is not going to happen for quite a while."
What I would do... (Score:5, Interesting)
Re:Give estimates (Score:5, Interesting)
Clearly Define your job and tasks (Score:1, Interesting)
You are selling your work and job.
NEVER SAY NO (Score:5, Interesting)
The right way is to propose and alternative.
Scenario 2
PHB says - "I want X done asap".
overworked IT engineer - "No problem, which one of A,B,C,D, .... W would you like me to hold off on while I do X ?"
PHB ... goes away and does not come back until it's more important that A...W
Scenario 2
Customer - "I have this way out idea that will really be cool to do !"
Overworked engineer saya - "Fantastic, you know, we have a procedure for new projects, go fill in the form and we'll prioritize it".
Customer goes away and forgets the crazy idea.
Most of the ways to deal with anyone it to give them your problem. If you do this then you filter most of the nonsense. The golden rule is to never say no but to "Prioritize"! No-one will ever complain that you don't do your job if you are "prioritizing!".
modulate parent up (Score:1, Interesting)
With Apologies to Abbott and Costello (Score:3, Interesting)
'Why is that Lou?'
'I just heard an IT guy say he's not available for overtime.'
(Okay, to avoid downmodding, it was originally 'I think the war is over (wwii)' 'why' 'I just heard the woman next door talking back to her maid'. The idea was that if someone gave a maid a bunch of shit, she could go be a Rosy the Riveter. Sorry, google no help. Go find some old time radio mp3s. Or tapes. Or CDs.)
Saying no comes with saying yes at the wrong times (Score:5, Interesting)
I've recently become development manager for one of our company's products. As such, it has taken a while to find my feet, both when interacting with sales & consulting internally, and when interacting with customers. I certainly erred on the side of saying yes too often, because I wasn't sure about saying no.
Not anymore. For me, it took mistakes, stress, and all sorts of complaints directed at myself or the company, whether or not it was my responsibility. It is this realisation that sometimes, I need to say no. People do get pissed off at you when you say no. But your job isn't to please people, it's to get a product out the door (well, for me it is, anyway).
So, you learn to say no when from the experience of getting a yes thrown back in your face.
take the burden away from yourself (Score:5, Interesting)
If you are in the position of power, then you should have enough power to make a decision without fear. If you are shaking in your boots, then shift the burden to the client by letting the client prioritize things for you. Obviously this is complicated if you have more than one client. Then you'd have to get them all in a room and have them talk it out.
The rule of thumb for power is that power should match your responsibility. That means, if you are, say, responsible for cleaning the floor, then you must be empowered to move things off the floor, to access cleaning supplies and so on. If you are a manager and it is your job to prioritize items and yet you are not empowered to say "NO", then something is terribly wrong, and perhaps, your project is going down the tubes anyway, and you should look for another job. Alternatively, you can just shut up and sort of roll with the punches and hope that clients will drown in the endless bureaucracy (let the thing that's holding you down hold your clients down as well) and eventually run out of steam. It really depends on the environment you work in.
Don't say no (Score:5, Interesting)
Re:I see this kind of problem in general (Score:3, Interesting)
What I mean is my friends will ask me to fix their computer or install a new hard drive but they would never think of asking their lawyer friends to write them a contract. What's up with that?
I have a policy with all my friends:
Windows Work: Pay my consulting rate, with travel time.
FreeBSD Desktop Work: Free.
I can install FreeBSD, with openoffice in under 30 minutes, and I rarely have to visit the computer again, and if there is a problem, remote diagnosis is quite easy.
Windows has to be installed behind a firewall - otherwise you get owned before the first service pack has been downloaded.
Hell, OpenOffice installes faster on FreeBSD than it takes me to type in the security code and go through the activation process in Windoxs XP.
Obligatory sarcasm (Score:1, Interesting)
Seriously, though, it's tough. In the corporate IT world your best bet is to hide behind some clearly define procedures or policies (yes, those things are useful). In the situations I'm familiar with (as a user putting in requests to systems support), what happens is this: I submit a request for enhancement or a trouble report; support opens a ticket and gives me a ticket number which I can use to track progress; after a couple of hours or days; I get an email telling me that the ticket is closed with a certain status; often the status is `rejected' followed by an explanation, like what I asked for is difficult to do and would only benefit a small group of people. That's usually fair enough for me, since I can often work around the issue, and if my workarounds create problems for other users, then support will be more willing to help out. I've never felt anything resembling outrage or anger if a request got rejected, at most I felt irritated (more work for me). But the key is that my requests have been in the queue, have gone through the system in a standard fashion, have been reviewed by one or more people (if I requested escalation etc.), and typically get rejected because there's a policy on what requests are urgent, standard, minor, or ignorable. Similarly, I hope that the support people don't get outraged or angry at yet another request to install an interpreter for an obscure scripting language when they are busy with more urgent things, because it's just another ticket in the queue that will be dealt with according to standard procedures.
In sum: documented business processes. And communication.
don't "underestimate" this advice! (Score:5, Interesting)
Seriously, this is basically all there is to it. Use whatever calendaring software you have to break down what you're doing on a daily or weekly basis, if not hourly. Even a recurring to-do list is good. The idea is to show that your time is not an infinite resource.
If you can sit down and say something like "I can make time for this project this month, but it will require moving back those security updates for a week, and the database migration for a few days. Also, we're running low on shared drive space and there's no budget to augment the servers, so to add this in, I'll have to put everyone on a harsher quota for the next few days (and delete your mp3s off your shared drive)," and show how your time is mapped, they will see why they can't reasonably expect you to take on more work.
You'll also be able to get more actual work done, because the mere act of organizing your regular activities will let you see ways to cluster them for more efficiency ("oh, while this disk image is copying, I can hit that next item on the list, replace the video cable on that secretary's computer so she'll stop holding my mail hostage"), etc.
Also, at the end of six months or a year, maybe you can use the resulting log as evidence that you need an assistant or a pay raise or both. It's also good for remembering what to put on your resume, if your small company decides to lay you off and replace you with two kids who just graduated and also happen to be related to the VPs...
Re:Leave that job (Score:3, Interesting)
I won't lash out, I'll just assume you're ignorant. I've got 5 years of admin experience, and I've had a grand total of FOUR interviews in FIVE months. Still unemployed. If you know something I don't, please let me know, I'll be all over it.
Goddamned Management! (Score:1, Interesting)
When he says "don't worry, it's not urgent", he means "Drop everything now and do it." When he says "Do it now, it's urgent" he actually means "I want it done three weeks ago!". Inevitably, whatever he wants "must only be a five minute job" but actually takes us a couple of hours which delays other software projects.
Despite the fact he prides himself on being a straight-talker with everyone, he can't seem to do it with our department. Gee, we must be special....
Re:take the burden away from yourself (Score:5, Interesting)
I've made best experience with this technique. Whoever asks me to do anything (usually this is a small number (~5) of different people) I ask back for the priority of the job.
If there's 50 tasks I'm pesting them for 50 different priorities, not just 3. Everybody understands that I can't do more than one thing at a time, everybody seems thankful that they can set priorities and don't rely on my priorities.
From time to time (if I believe something doesn't fit or someone misuses this power) I check back with my boss, but usually this is not necessary.
Another hint would be: Don't keep backlogs. Accept work for a month, not more. Nobody (especially not you) is happy to see that a task will be performed in a year. (and when the year is over it will be another year, because so many new tasks came up). When the month is over, get more work. Some recommended reading on this topic comes from xprogramming.com: http://www.xprogramming.com/xpmag/PetitionTheKing. htm [xprogramming.com]
Good Luck.Olaf
Re:Keeping on task (Score:1, Interesting)
"I WANT IT NOW".
He simply replied...
"No sorry, i can't as this requires paperwork from this person
she replied with..
"THATS IT...NOW IM SPITTING SHIT HERE" (shouting in his face).
He simply and calmly replied without showing his anger, distaste and contempt...
"Listen, im sorry, the answer is still no, i cannot override official procedure."
the simple answer is basically, don't give in, be polite but to the point, if they go over the top with you, its their job they risk losing, not you with yours.
Status queue (Score:3, Interesting)
Somebody puts in a request? Great! Post it on your web-thingy, and notify your boss to assign priorities for the request(s).
Then, when user NNN sees their priority bumped to position #37 (ETA==never) they can take it up with your boss... while you just appear to be clean, professional, and attentive.
This is the kind of thing you could hack together with Linux/Apache/PHP/Perl in a matter of a few hours, if you really are any good.
Heck, put in a submission form so that you don't even need to type it in!
Say You'd Like to Help... (Score:3, Interesting)
Then you're sort of playing good cop/bad cop, using your boss as the bad guy
You can't do this on everything, or you'll really get on other employees' bad sides.
Very few things can't be done ... (Score:4, Interesting)
There are a number of things that are key
1) agree with senior management on broad priorities
2) draw up a list of what needs to be done
3) re-order the list in terms of the agreed priorities
4) present the prioritised list to management, and have them agree to the priority
5) Give an honest indication of how far down the list you'll be able to get
Go off and do stuff, and report progress on the list and re-prioritise the list say once a week, with their input.
IF they are half way decent as a manager, they will rapidly understand to either accept the level of capability they have, OR accept the need to increase that level of capability to meet their performance expectations. If they can't arrive at conclusions similar to these, in general you should be looking to work elsewhere.
If they want X to be done, explain what is really needed to achieve X. If some or all of the pre-requisites, give a honest estimate of how that will impact their timelines.
Oh - and plan on, and only commit to, 35-40 hours of real work per week per person, otherwise you'll burn people out, AND have no spare capacity to surge to meet the occasional urgent deadlines.
Another thing that can help, is to help filter the crap out, by getting agreement from management for allocation of resources to issues.
No system is perfect, but if you can demonstrate an understanding of the businesses needs and priorities, and be up front, but constructive, about the implications of meeting those, you can often say no without really saying no.
Re:Sexual Harrassment (Score:3, Interesting)
And he was right. I learned to say no long ago and I still say it without any fear of repercussions.
There is a caveat: "During the interview when asked what are my problems when working if any, I always answer that I have a problem that with people who do not understand the word NO". Basically, you have to stake your right to say no from day -1. If you cannot do that you will be in trouble later.
Re:Give estimates (Score:5, Interesting)
as others have said... (Score:2, Interesting)
it may help using project or, better IMHO, an issue-tracking system so that requests can come in via the web or email, and users can see the status of their request anytime and its level of importance related to other requests.
A very good issue tracking system is roundup http://roundup.sf.net it runs as a cgi or as a standalone app.
Once you have such a system in place, send out weekly status reports on everything accomplished during the week, pending issues, etc.
Visibility is one of the most important things in organizations.
Oh and when you have difficult situations, ask your boss showing him the pending issues in relative order of importance, their timeline etc.
Re:Give estimates (Score:4, Interesting)
MS Project rules in this environment! (Score:4, Interesting)
**Keep it maintained at all times** - it only takes a few minutes to maintain it once you've got it set up.
**Be realistic with your time estimates** - if you don't know how to build a firewall, then allow a lot of time to do it.
**Remember that you aren't productive 40 hours a week** - depending on your role, you'll probably only do productive work 30-80% of the time, and if you're the only techo guy in the shop I'm betting you'd be somewhere below 80% productive. Reading email, going to meetings, cigarette breaks - they all chew into your 40 hours per week. Once you decide how productive you truly are, factor it into the project plan by saying the resource (you!) is only e.g. 60% available.
Then, when someone comes up and asks you to manually install virus checkers on these 43 new PCs, put it in your project plan, show how every other task you've got blows out by 2 weeks and see if your boss is prepared to accept the delay.
If you're at a place where they pay for overtime, enter all your time estimates in hours and do a few "what if" scenarios on your resource allocation (i.e. you!) to show how long things will take if you work 30, 40, 50, 60,
Without a doubt, the best/only way to get out of a situation where you're overworked is to be extremely organised and able to show anyone at a moment's notice exactly how busy you are. Once your boss can see the true impact of giving you "just one more" task, in terms of the slippage that will impact other projects, you'll be amazed how that extra work will no longer be as important
PS If anyone knows an OSS MS Project replacement that can do all this stuff, please speak up. I've been dying to replace it for ages, but it's a really good fit for this particular problem space
simple (Score:2, Interesting)
They then usualy can not get approval and I work on A until it is completed or not a priority.
Re:Give estimates (Score:3, Interesting)
make it an application (Score:4, Interesting)
If my colleague wants something done I tell him to put it on the to-do list with a priority rating.
I then work top down. That way he knows what I have / haven't done and what he's going to delay by wanting new things.
Managers should manage. I let him choose which work I'm doing next.
And I can't stress enough how well that appraoch works in a bigger company. Bump requests up to your manager and let him choose which you do next. It reduces your stress because you aren't trying to juggle a bunch of peoples feelings and with luck, if you are overworked, they will do something about it because they can see the situation rather than people bitching about you never doing their tasks when they think that their tasks are the only ones you have outstanding.
Re:Give estimates (Score:5, Interesting)
How to refuse work...
Never say "no" to a client, since you will lose the client. To refuse work, raise the cost until the client decides it is not worthwhile. It is not a problem to appear "expensive" so long as this is always related to "quality" and "performance" in the mind of the client. Perception is everything.
For an employee, the pressures are different ("do this or I fire your ass") but the trick is the same: make your boss responsible for the tradeoffs that too much work implies. Give him a choice: "OK, I can do this or that, which do you prefer?"
Don't complain about getting too much work. It's really a much, much better situation to be in than to have too little work, and you will often find that many "urgent" issues get relegated and finally abandoned when the boss actually has to make a choice.
Lastly, always appear to make the best effort you can, since what counts at the end of the day is not how you actually performed, but how people perceived your performance. Smile, agree, react quickly and professionally, work well with your colleagues, never blame others but be quick to take blame on yourself, and you will find that your boss / clients respect you and value you.
Personally I have not found project management software any use at all, software projects being far too chaotic (in the mathematical sense of being unpredictable due to complex interactions) to be planned. But in more operational work, scheduling tools are indeed very useful.
Re:Cover your arse. (Score:4, Interesting)
Also, if you have multiple bosses asking for your time make them fight it out amongst themselfs (ie "Sorry Sam, but i'll be fully occupied with this project for John for the coming 2 weeks. Maybe you can talk to hime about it?"). It's majorly entertaining.
Additionaly i would like to address the Try to help them to get their task done themselves quicker than you doing it. thingie:
- Some people (for example, the "one specialist in a certain code base" or the "fireman of the company/department/group", or just anybody that's good at solving problems and is helpful) will be constantly interrupted and asked to "help me out with something for a moment" or "I can't get this to work, can you help me?" or "can you explain this to me?".
- Although this might at first make one feel good (you're "needed", you're "important"), it soon becomes to much and starts eating you your time like crazy - 15 minutes here, 10 minutes there, 20 minutes somewhere else soon adds up to a lot of time.
- Now, the problem with "helping others time" is that it's not in the budget. No mater how much usefull your helpfulnes is (and sometimes it's counter productive because it can breed a culture of dependency), you still have the same amount of project work to do (just less time to do it).
- That's were the "help others help themselfs" thing comes in. It's the single most efficient way i know of actually helping others while wasting the smallest possible amount of time.
The things to note with the "help others help themselfs" system:
- At first it will eat more of your time than just "doing it yourself". "Doing it yourself" will fix the problem faster but only this time around - the people you just helped don't actually learn anything from it and will come back again (and again and again) whenever the same or a similar problem pops-up (plus they won't be able to help others with that problem)
- Thus the gain in time for using the "help others help themselfs" system comes with recurring problems/questions/whatever.
- Also note that even when you teach people how to solve a problem, a lot of them still tend to come back to you to have you solve it for them. That's because for them it's easier and simpler to just get you to do it. To solve this, just make it harder to get your help for those you have already taught how to solve the problem (for example ask: "Have you tried what i told you last time?" "No" "Go and try it, if it doesn't work come back to me with it")
There is a lot more stuff about time management and avoiding overwork - however, this will help contain some of the "sneaky time wasting" stuff.
Priorities, get priorities (Score:5, Interesting)
Here's a little story you might find enlightening, the importance of priorities in keeping requests under control. This is relevant, very relevant.
I worked with a guy who was an air force loadmaster in Vietnam, early 60s. He had some scut job at the main Saigon airbase. They used to extract carriage fees from shipments of steak and whiskey going up to the officers club at Cam Ranh Bay. One day, some ensign showed up, fresh as a daisy, said there were pallets going up to the club, and he was in charge of making sure they arrived intact, and demanded they be sent up on the next available plane. My friend had been in too long to give a shit about some wet behind the ears ensign, and furthermore, had the distinct attitude of What Are You Going To Do, Send Me To Vietnam? So he slapped a bunch of clipboards up on the counter, said fine, you tell me what cargo you want to take off, sir, and we'll see that your steak and whiskey gets up there right away sir. Now what will it be
That's the end of the relevant part of the story. Remember, make the job assigner decide not TOP priority, but where exactly on the list, so when other people complain, you can point to new jobs added above theirs. The goal is to get the suits hassling each other, not you. Don't argue with them. If they berate you, just say you need to know whose jobs to bump down the list. Be quiet and form, you need to know the positional priority.
OK, the rest of the story is more fun, not as relevant, but may help you to remember this trick.
The ensign demanded that someone stand guard over the pallets of steak and whiskey. My friend just sneered at him, Sir, you have a sidearm, why don't you use it? And the ensign did, he stood gaurd over the precious pallets for some time, until some crusty old chief, who had spit more sea water than the ensign had ever seen, showed up with a case of whiskey under one arm and a case of steaks under the other, slapped them down on the counter, and the pallets went out on the next flight.
There's a moral to that story to, but it's probably not a good idea to start taking bribes to shuffle your boss's priorities
Re:MS Project rules in this environment! (Score:2, Interesting)
Re:Give estimates (Score:1, Interesting)
When you get a similar request you'll have a record of what the critical elements are to check (what is installed, settings, user expertise, etc).
With that maths/stats expertise you can do a linear regression and get good working estimates of time required to fix a given problem in a given situation.
THIS means you can calculate the forward workload of requests. it could be that there is a class of requests that can be satisfied by a lower-qualified techo working for only a few days. Maybe get in a student.
Management likes the numbers and may appreciate that you are managing the work and trying to delegate it to a lower cost resource to free you for more complex tasks.
Worked for me in a manufacturing environment where there was an infinite need for maintenance.
Your database can also help you to devise checklists for users to follow before calling you. As each areaa has its own propeller head, maybe give some problem logging "courses" to those people on a group basis so that there is someone in each area who can correctly specify what is needed. I find that a huge part of my tech staff time was spent trying to work out what the problem really WAS.
Good luck.
Re:Give estimates (Score:4, Interesting)
All requests go through him. Noone else. He should then get a clear picture of what they're asking, and then come to you to help you estimate the assignment.
If there is a "no", you should always give elaborate reason as to why (i.e. make the customer realize what a bad idea it is).
It's a good thing to do the estimate anyway, in case the customer just says, "I don't care, do it anyway!"...
The biggest mistake is to talk directly to the people that do the assignments. A lot of those people don't know how to say no, or have the customer realize that it isn't a great idea.
I've worked in such enviroments for at least 6 years. I was one of those who had a hard time saying no. After I got kids, it got a lot easier
A test of your management (Score:3, Interesting)
You should have a line manager to whom you report. Yes, of course you provide a service to a zillion different departments, but there should be one person to whome you report. Possibly the guy who hired you. Or the guy who says you can't have any more budget. This is his problem.
If that guy is totally pointy-haired, then there is nothing you can do. Start looking for another job. Because even if you solve this problem, another will come along, and another, and another... Better to jump early that to drop out from exhaustion.
But assuming your boss is not totally pointy haired, then all you need to do is to dump the stuff on his desk. When people come and make the excessive demands, package the whole lot up, take it to him and say "this represents 200% of what I can possibly do - please choose the half you want me to do, and prioritise it, the tell the other half they cannot have what they want", It is his job, not yours to palacate the enraged user. There may be a few iterations, as different users use their different powewrs to escalate their requests (or drop them because they weren't that important, or there is another way to do them).
Obviously, your boss will try to get a bit more out of you - ask for 110% of that 200%. Don't give in to this. Make that 100% honest, then stick to it. If your boss fires you for an honest statement of what you can do, then he is too pointy haired to work for. And don't let him squeeze your estimates - if you say four days for a job, it is four days, not three. You are the techy, it is your job to make those estimates - and to get them more or less right. He is the manager, it is his job to use those estimates to get the best value for the company from your skills. Respect his skills - do the things he prioritises, not the ones you would like to do. But demand that he respect your skills and doesn't override your technical judgement.
To summarise: you need to learn to say no to only one person: your manager. If you cannot set up a decent relationship with him/her, the job has no long term prospects: head for the lifeboats fast. If you can set up such a relationship (and it is a core function of technical management to have such relationships), then you can simply pass the buck upwards.
Re:don't "underestimate" this advice! (Score:5, Interesting)
Actually, most of what I related came from friends who worked in IT before all getting laid off. I decided that those would be a lot more relevant than my own anecdotes, which mostly have to do with juggling
In addition to all those, I also had my regular duties, which included supporting the customer routing infrastructure, then still taking weekly turns on 24-hour pager duty after I was too busy to do the daily support. Oh, and maybe a few escorted colo visits. And calls from the company president's office to fix other departments' problems. And that emergency customer premises visit...
I figured if I said anything about those, I'd get cranky, or you'd get bored, or think I'm desperate to show off so someone will hire me (I made it through 3 rounds of layoffs cleaning up the messes, but there were at least 4 rounds, so you'd be right about that), or I'd say too much and get sued by my former employer (I've just gone back and removed most of my text. But my former bosses can still reconize me immediately), and none of these really sound like system administration issues, which is what the root article is about, so I won't.
Too bad, too, because I could have mentioned how I got the decommission done with a month to spare. And how I did the last year of projects and support 90% from home, especially after the secretaries, then some fellow engineers, then my boss got laid off, and the office lost its soda budget! Oh, and that all the work at home was done over dialup, frequently at rates like 21.6K.
But who wants to hear about those things?
Re:Give estimates (Score:3, Interesting)
Which indicates, sorry to pick on you, that you don't have a defined process. This is part of the saying "yes" and meaning "no" art, having a process ensures that people know that A is followed by B. If your project is chaotic and not properly managed it is easier to place additional demands as the amount of information to say no with is low.
The rest of the advice here was good, but the later one isn't I'm afraid. Software projects can, and should, be planned. And a process should be in place to manage the changes that inevitably occur. If you do not have a process then change management becomes difficult or impossible and the project will lose money and you will be fired.
Also management LOVES the idea of a process, so if you define a process for your work and it proves effective it will be enforced on everyone else.... BUT (and this is the best bit) NOT MODIFIED, so you end up looking even better.
So the easy way to say no is to define how you do your job. If you are doing software development this means getting a requirement (on paper), doing a design, then doing the code, then testing it. If you have several requirements these will inter-relate.
And one final piece of advice, if you really want to say no, make sure you can claim that a seemingly trivial piece of work that could be dropped for this new task can be linked to another major piece of work that would bring the project down. And say the immortal words
"Sure no problem, you'll just need to tell Big Boss Dave that the well have a delay releasing phase 1 because I won't be able to complete X in time"
Its amazing how people don't want to slip phases.
Other great phrases for cases where the idea is plain dumb
"That is a great idea, just a couple of things that confuse me" then get them to explain the dumb bits and start using phrases like
"Ahh I see, but wouldn't that mean that...." and point out how you'd have to re-arrange the universe to get it to work.
The trick is to make the client feel you are working out the problem together, with them taking the lead.
BUT do plan, do have a process, because without that you're screwed.
Re:You know what they say (Score:2, Interesting)
And be a dick about it. I can't count the number of times I've said "no way, I refuse and if you don't like it fire me"
I've also done this one "No that's stupid. I'll only do it if you force me and when we get hacked don't blame me"
Of course, you have to mean it, and don't do it over something trivial. I'll move buttons around forms all day long, but when they say "we want to add 400 users and make their password be 'password' so we don't have to remember what it is" a good ol' "KMA" works wonders.
Re:don't "underestimate" this advice! (Score:3, Interesting)
At the dot-com I used to work for, the main fileserver and domain controller would lock up every Wednesday morning at approximately 6:30 AM.
(Yes, I know. . . .%$#^^@! Windows!!!)
The Only fix was a reboot, until we started checking logs, and found that the system locked, but didn't blue-screen, after a Full Virus Scan of the files in the Fileserver was underway.
It was a problem with Symantec Anti-Virus Corporate edition. And there WAS a fix from Symantec. The problem was, you had to re-apply the fix after each virus definition update, and it was linked to a certain (forgot which) flavor of Java files being scanned.
OF course, we used that particular flavor of JAVA for development, and the code repository was on the fileserver. . .
I finally REALLY fixed the problem when the Corporate AV subscription ran out: I switched the company over to SOPHOS. . . .
Three Words: (Score:3, Interesting)
The SLA should specify how and when things are done. It should also classify work request priorities.
Put an SLA in place and have management sign off on it. When a request comes in, prioritize according to this. When the users come back and start bugging you, point them to the SLA and tell them that things are done in order according to the SLA. If they don't like it and complain to their manager or yours, inform management that they signed off on the SLA and that you're simply following the official policies already in place.
This would also allow you to get the most important issues resolved first, without having to worry about Sally in Accounting beyotching about her screensaver while you're trying to fix a server.
Re:OT: WHAT A GREAT STORY (Score:3, Interesting)
They may not understand your time but they will when you put a dollar amount on it.
Don't assume everyone knows your situation (Score:3, Interesting)
Don't assume that your boss, or the people giving you the work, know your situation. Never say no; that's not what you're paid for. But point out technology and resource limitations that make requests unreasonable. Phrase it in terms of impact. If someone asks you to do something, "Ok, I can do that... but requests x, y, and z have priority over that, so it'll be n [days|weeks|months] before I can get to it" Or suggest an alternative like "Sure, I could take that word document from HR and convert it to HTML... but did you know that Office can automatically save to HTML format now?"
The short of it is, it's their money and their time; they can choose to do what they want with you while you're on the clock. Just make sure that the decision makers are aware of your situation, and how their decisions impact the work that you do.
Re:Priorities, get priorities (Score:3, Interesting)
Dead on the money. Your problem isn't solely an IT issue - it exists whenever someone gets independent work assignments.
My own example comes from construction. When I first joined my company, I was assigned some subcontracts to manage. Then some data input into the accounting side of the project. Then something else. Etc, Etc. Within 2 months, my boss was calling me to task because I wasn't "getting stuff done." So I went into my office, and wrote a list of my major assignments (all of which he gave me with "right away" as a schedule). I presented it to him and requested that he put them in rank order, 1-12, and I would devote all of my time to #1 until done or stopped, then #2, etc.
3 results:
1) My boss said "Wow - I had no idea you had this many assignments" (that he assigned, of course) and he took some off my plate.
2) He was forced to identify what was really important on the project. He just assumed I knew what the priorities were.
3) I got a tool by which to measure my progress and document to him that I actually WAS getting work done.
This worked OK for me, maybe not for others, but it might be worth a try.
Re:Tell them "all it takes is time and money..." (Score:3, Interesting)
Ticketing system. Let me say it again, ticketing system.
I've read Sys Admin bibles where it says, in the FOREWARD, "If you don't have a ticketing system, put down this book, and implement one. Then, come back and read some more."
Ticketing system. With time/date stamps, and use it RELIGIOUSLY.
Keep a webpage that has a 4 square table (Score:3, Interesting)
Keep an org chart on a portion of the same page, and tell them that they can put their task anywhere in front of anyone at their level in the heirarchy or lower, or in front of their own boss. If they need to get past someone's request, all they have to do is go to someone high enough in the organization and convince them to send you an email.
Then spend 6 hours a day on urgent important things, 1/2 hour on urgent unimportant things, 2 hours on non-urgent, important things, and 1/2 hour on unimportant, urgent things, or some other mix you find appropriate.
You will slowly see that you are told the important things far in advance, because people find out they get done quite early and very reliably if they give you notice (because you always make time for important things). People also see they shouldn't ask you to do things that aren't important, and by keeping things public, they won't ask the silliest of things that you get now. You'll also see your users start to use the proper terms for things as the list is public and they will otherwise appear unintelligent. Rather then seeing "My computer is broke. u fix it" you'll see "Configure Eudora on My Desktop to Send Email"
As you complete a task, move them off into a permanent record of tasks completed.
And keep an extra computer by the door in your lab/office. If someone walks in with a request, just have them file it appropriately right at that terminal.
I got fired (Score:5, Interesting)
and I got fired... for "breach of ethics". apparently "pandering to a customer's silly whims and tantrums" is an article of ethics in that crowd.
Re:Timeline estimate guidelines. (Score:3, Interesting)
Programmers working on large projects estimate large chunks of time. If these people estimate one year, I would at most epect not more than one year and a half.
You may have meant shorter term estimations, and while they are more prone to double, saying that a you should expect a newbie to take a week to get a one day assignment done is completely rediculous.
A much more resonable device to aid estimations is to compute average daily project time. Too many people assume you can work eight hours a day on something. For sysadmins, ADPT is less than it is for dedicated programmers. 4 hours ADPT is about right for someone to can have tasks spontaneously added. For those who have a more concrete schedule, it is still dangerous to assume more than 6 hours.
Of course, it will take a couple months of careful monitoring to compute a good ADPT, but then project estimations tend to be much more realistic when people actually realize how long they actually can work on one project in any given day.
Practical Applications (Score:4, Interesting)
Basically, no one has the right for any reason to violate your emotional and mental boundaries. Given this information, any employer who would expect you, the only IT employee, to work miracles on a budget with 70+ hour work weeks would either be insane, satan, or taking advantage of you.
In any of these cases in it not right. I assume you are salary which means you work whatever they tell you too. They can fire you because they feel like it. And basically, you owe them for giving you a job in such difficult financial and job market times.
Therefore, here is a practical solution. Explain to your customers, clients, employer and co-workers that you are one person doing the job of several. You are more than happy to get to their requests (which I can assume are typically easy user account resets, PC checks, LAN crawls) but to please be patient. And if you must tell them "No, I cannot do that." Be sure to add, "No, I cannot do that right now. I have too much work to do. Perhaps we can revisit this at a later date."
Keep in mind you do not want to upset them. So yelling "NO!!! GO AWAY!!!" as the BOFH would, while quite humurous, and honestly quite theraputic, would probably get you fired. You want them to be considerate of your time and your work so please be considerate of theirs (and it sounds like you are, otherwise you wouldn't be so willing to do the work and find it so hard to say "No.")
I hope this helps.
Rivendahl
Re:don't "underestimate" this advice! (Score:2, Interesting)
People would generally agree that you can only do so many haircuts in a day. But in the IT world, you're often dealing with people who have no idea how long something will take. And usually they will think everything is easy to do - you just need to push the magic buttons, and poof! - it's done.
Education is key. You need to explain to people what it will take to get the task done. The bigger trick may be explaining this to them without their eyes glazing over.
Create miracles (Score:2, Interesting)
I had a colleague at my previous workplace, an older female programmer(rare enough, but obviously the best programmer in the house). She always remembered to keep saying "work won't get finished by doing it". The point was that no matter how long days and weeks you work, there will ALWAYS be more work to be done in the IT field(probably elsewhere too?).
This leads to priorising and more than anything else, respecting what you do. You have to realize that in the long run, jobs come and go, but there's only one you.
Personally, I also find it important to being in good communications contact with the boss. Being able to just stop and talk, cell phones turned off, and discuss ideas as well as the current work situation.
Oh, and the old saying I mentioned above... it also means that no matter how many people there are, ALL work never gets done. Obviously, sometimes you need more staff, but there's usually a good way to compromise. Some things are priorities, some things aren't. Some things are worth spending a few days on, some things aren't.
As for the last tips, flexible work hours do miracles for work productivity. I've seen it myself and in my current staff. Good eating habits at work can also do wonders (don't worry, you can party at weekends
Priority is the Problem (Score:2, Interesting)
basically he was leaving it up to the management to be the bad guy for whose work wasnt accomplished. let the guys who are dumping the work onto you be the bad guy for the customer.
sTc
Re:make it an application (Score:2, Interesting)
Install and maintain a formal ticket system. Use this system to communicate with users/clients. Ticket systems allow you to document the entire process, allow the user a means of communication without having to hunt you down, and allow your manager to see all of your tickets and make or change priorities.
Secondly, have a Service Level Agreement. This needs to be hashed out by your manager and other key managers, but it needs to be written (mostly) by you and your colleagues. This gives you and the user community common ground to start from, and sets realistic expectations. All employees must be aware of this SLA, so it should be part of a new-hire package, etc.
Use the ticketing system to print out and/or track your jobs on a daily basis. Be sure and set your daily workloads, keeping in mind employee absences, etc. Don't schedule more jobs than can be completed in one day, and allow room for emergency calls to your helpdesk. If you do not have a formal helpdesk, create one. This can be as simple as setting up a voicemail box on your voicemail system that the users dial and leave a message on. This help line response time must be included in the SLA. Have the mailbox tied to a pager that someone carries, so emergency situations can be responded to quickly. We tell our users that all calls logged on the helpdesk will be responded to within 15 minutes, and tickets will be created so the user can then further communicate with the assigned tech.
In your free time (heh) read "The Practice of System and Network Administration" by Limoncelli and Hogan, ISBN 0-201-70271-1. They talk about all of these things, plus many other things that make our lives easier, and worth living.
Hope this helps...