jump to navigation

Friday Philosophy – Identifying and Nullifying Fake Urgency April 20, 2012

Posted by mwidlake in Friday Philosophy, Management.
Tags: , ,
trackback

You know how it goes. You get a call/mail/text with something along the lines of “I need to know all the details of customer orders placed on Tuesday 7th by customers based in Botswana – and I need it ASAP, by end of play today at the latest”. So you skip lunch, drop that task you have been trying to get around to doing all week and work out how to resolve the issue that has just been dropped on you. It takes a lot of effort and you finally get it sorted out around an hour after you told your girlfriend/boyfriend/cat you would be leaving the office that day – and mail it off to the requestor. You might even call them to let them know it is done, but oddly they don’t answer.

Next day, you see the guy who wanted this urgent request and ask if it was what they wanted “Oh, I have not looked at it yet – but thanks for doing it.”

NO! “Thanks” does not work in this situation. I’d have more respect for this guy if he laughed at me and said “got you again, sucker”. Many of you know what I mean don’t you – if you are in a support-type-role, this can be a big part of your life.

I had a job years back that seemed to consist 90% of such tasks. I was the development DBA team leader responsible for testing, validating and promoting code to production. Everyone’s changes were Urgency Level 1, to be done as an emergency release and many could not be put in place until after 5pm. I’d be sat there at 18:30 in a massive but virtually empty office, applying changes along with one or two of my guys. Everyone else had gone home. This was not once or twice a month, it was 4 or 5 times a week. What are you to do?

Well, I came up with one tactic that seemed to work pretty well.

Anyone who asked for an emergency change had to be there, on site, available when the change was done.
There were of course cries of protest and people stated it was ridiculous that they had to be there, they were not needed, the change had been tested thoroughly {oh how I laughed at that – a thoroughly tested “emergency” change huh?}. No, I replied, you had to be there in case it went wrong as it’s your system, your data and, frankly, your emergency. If it is not urgent enough for you – the guy wanting it to be done – to be inconvenienced, well it sure as hell is not urgent enough to inconvenience me. “You can call if there are problems” – What, after you have escaped the locality? Maybe turned off your phone? And if I get you , I have to wait for you to come back in? No no no. Urgent emergency now equates to presence in office. After all, I’ll be there.

I stuck to my rule. If the requester could not be bothered to stay, I downgraded the request to “Planned” and put it through the CAB process. If the requester dumped on one of their team and made them stay, I mentally marked them half a point down and factored it in next emergency.

The change was remarkable. I was no longer in the office on my own every evening. I was not there with someone else either. I was simply not there as, when you made the emergency a little bit inconvenient to the requester, it magically stopped being an emergency.

There was another change. Less cock-ups. Seeing as these changes now went through the CAB process and slightly more testing {like, some testing} the duff changes were more likely to be detected before they caused damage. My bosses went from regarding me as “not a team player” to “Not a team player – but we kind of get your point now”.

So my advice is, if someone wants to try and make something your emergency, find some way of making sure it remains inconvenient to them. If they are willing to put up with the inconvenience, then it is a real emergency and you need to crack on with it.

About these ads

Comments»

1. jgarry - April 20, 2012

I’ve seen the tactic fail at a large site. It wound up being a power one-upmanship, with each damager making more of all the other’s people required to be onsite.

The more common downside is the perception of obstinance by or obsolescence of the IT department, leading to extracirricular deployments (“we can just do it ourselves on our PC/ in the cloud with the owner’s 3rd cousin twice removed genius kid”).

mwidlake - April 20, 2012

Thanks for the word of warning Joel, I suppose you could end up in a pointless power struggle in some situations and making a stand does upset people.

But my opinion is these people deserved to be upset – they were acting in an unreasonable manner and had not responded to discussions on proper classification of priority and emergency changes – they were all being abusive {the ones who had responded to the chats about what really classed as an emergency were the one who did not object to being on site and were the ones who, strangely enough, I’d do the change for after letting them go home}.

In my situation above I had absolute power over what went live and I could see if anything changed that I did not implement. I also had the backing of a very good (and also very frustrated) DB manager.

Since then it is a tactic I’ve used often, though often implemented in different ways.

2. twoknightsthenight - April 20, 2012

Not sure if you’ve run across this but some use the “emergency” tag to evade doing standard documentation and testing. Yes, I know it should be even more required but that’s how some see it. But if they want out of hours support, they have to get approval from each of the groups needed to implement it. We don’t go quite as far as requiring someone to be onsite but they are expected to be available right away, if for nothing else than immediate testing. If I can’t contact them, it doesn’t get done.

mwidlake - April 20, 2012

Absolutely Kevin, “yes” to having seen the use of the Emergency Change being abused to circumvent the testing and documentation route. I think that comes into what Joel was talking about in his first comment – if you make the standard process too hard, people try and work around it. I’ve even been on the side of working around the CAB process – when it has become broken. The odd thing is, I’ve been in the situation where I sidestep the CAB process but insist on my own rules and governances that actually replicate what the CAB should be doing.

It sounds like you are doing what I suggest – If the requester is not online, the change is not happening. They have to put in some effort to justify the “emergency”.

3. Neil Chandler - April 21, 2012

Are you spying on me at work? How do you know what I did last week (sort-of)?

4. bigdaveroberts - April 22, 2012

I was even more nieve. A manager (not mine) asked me for a weekly report, I obliged. Six weeks later the manager approached me and stated that I looked overworked and would this report make my life easier?

He handed me the report that I’d been doing for him for the last 6 weeks.

Well following an unprofessional response from me, that was one task off my to-do list!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 158 other followers

%d bloggers like this: