'Hello IT, have you tried turning it off and on again?'

January 12, 2011 12:21 PM

How can I make it clear to users what pieces of a database I've changed so that they don't assume everything going forward that is wrong with it is because I've 'done something'?

I've been put in charge of some preexisting databases at work. Every time something happens to the databases, even if they tell me it happened before, there's an overtone of 'this is your fault' in the way it is reported to me.

I know that I should not take this personally, but spending all day every day having people think I'm an idiot who is breaking the tools they need to do their job is very draining. I've started to dread opening my email.

Worse still, I've been asked to add a new feature that is essentially the same as an existing process, but with a different set of data. All I'll be doing will be adding code to allow users to upload data with a different set of criteria, and it will not have any effect on other parts of the application. I am already dreading, however, the inevitable way that slow response and user error will result in emails to me saying URGENT DATABASE DOWN that are cc'd to everyone from the reporter's director on down that make it sound like I'm just wandering about in the code screwing things up.

I also have to deal with the fact that, as a younger (for my company) woman in a deep southern US state, it is unusual for me to be a technical authority. I've had to use male coworkers as 'authorities' for things that I know perfectly well how to do, in order to back up things I tell them.

I need a coping mechanism to deal with the fact that my users immediately jump to assuming it is my fault, and I need a way to make sure that their suspicions stop being so painful.

posted by anonymous to Work & Money (16 answers total)

Your manager needs to deal with this, perhaps by replying-to-all something like "The database is not down. The response you are receiving from the system is correct. You were informed of these changes on X, Y and Z. Please take the time to read the documentation before misusing our bug reporting system."

If your manager trusts you they need to go to bat for you, if they don't trust you than you need to find a better manager.
posted by ChrisHartley at 12:29 PM on January 12, 2011 [3 favorites]

not sure if its possible, but if there is an error message popping up, see if you can configure things in your new sections to have different messages, or different error numbers...

depends how things in the application are coded, but if there is an error code generated, customize the errors from stuff you work on...

Also, you can keep a document up to date with any changes you make... no matter how small... then you at least have something to point to, when it breaks....
posted by fozzie33 at 12:30 PM on January 12, 2011

Not sure how possible it is for the tech you're working with, but the best thing I ever did to get over feelings of things being out of control or little gremlins in the machine was to set up as much logging and debugging as I possibly could. It might slow things down in the short run, but it will make life easier as it will help you remove the fundamental causes of issues. In my case, I found the 80/ 20 Rule definitely applied, and that the majority of the bugs were caused by a few errors.
posted by yerfatma at 12:35 PM on January 12, 2011

It sounds like you have a "blame culture" going on there. Do you see this attitude taken about other things around the office, or is just your area?

I do software development in a small company and I've seen a little bit of this. The best thing you can do is create useful error states for the application. The end users are over reacting and they should be more professional about it, but consider for a moment that you look at errors entirely different than they do. You work on the leading edge of the system where it breaks often and you work out bugs -- you are used to seeing and dealing with errors. Their world view is that software should work right every time and they don't have the experience or information necessary to resolve software errors. This raises their blood pressure.

It isn't your fault, but understanding where they come from a little may help to craft the message in the system.
posted by dgran at 12:39 PM on January 12, 2011

If somebody cc's the whole company with a bug report, I think technically you'd be within your rights to reply-all when you explain why their issue is a user error and not something broken. But that's probably a little petty. Still, respond to the original complainer and cc your boss each time. Explain (a) that the user was doing it wrong, or (b) that there was a pre-existing bug, not due to any recent changes, that you have now fixed. After a few of these, talk to your boss face to face and say something like, "I don't mean to clutter your inbox, but I want you to know how much time I'm having to spend dealing with these requests from people instead of on the priorities you've given me. I'd hate for you to think I was causing these problems, when that is not the case."

Also: is there any way to change the interface so the users have better, clearer, more in-your-face instructions? Perhaps even some trouble-shooting tips? If you add that kind of thing, you can make a policy of "Do to the volume of requests, IT person will not respond to requests for help if you have not first tried X, Y, and Z to fix your own problem" and then stick to it.
posted by vytae at 12:40 PM on January 12, 2011

GAH -- "Due to the volume" -- There's nothing worse than a typo in an error message!
posted by vytae at 12:42 PM on January 12, 2011

Um, Sounds like a pretty crappy work environment. Perhaps create a webpage, or if posable an announcement section on your app, that lists changes and helps set user expectations? Probably most of your users would not look at it, but when they complain, you can just say, "as mentioned in the announcements, this is not a bug but a minor change in how the system works.
posted by d4nj450n at 12:51 PM on January 12, 2011

What I try to do is to be as explicit as possible to the users about what you are doing: "Hi users, I defrobbed the widget futzification interface this afternoon, you might see fallout using features X, Y, and Z as a result." Even if you think that this is over your users' heads or that they would not be interested in this level of detail and even if they never use features X, Y, or Z, letting them know exactly what is going on is going to reassure them that you are not "wandering about in the code" but are working in a purposeful way. It's also going to give them some guidance as to what might reasonably be a consequence of your work and what probably isn't. And it tells them that you are aware that sometimes there might be fallout from your work and that you are open about it and when you say "it wasn't anything I did" it's because it wasn't anything you did and not because you are a habitual ass-coverer who never admits to mistakes.

Good doctors do the same thing, because they know it makes people feel better when they know what is going on even if they don't really care about how the CT images are interpreted or whatever. So does MetaFilter whenever a new feature is rolled out. The more you communicate with your users the more they will trust you.

Lastly, it sounds like your company would benefit from more clearly-defined procedures for reporting, and handling, problems. There is no reason people should be sending bug reports to the whole office. Can you ask that people use a trouble ticket system of some kind?
posted by enn at 1:05 PM on January 12, 2011 [1 favorite]

I understand your frustration. I get some of this, and here's how I handle it:

- First, always consult with the users before developing a new feature. I can write scheduling apps till I'm blue in the face, but I don't use them and have no idea what features people want. What I come up with will be what is easiest for me to code, not necessarily what's easiest for people to use. That doesn't mean users get all the features they want, but it gives me a good idea of where the whole thing should be going. And it also lets them know a change is coming and makes them feel like they had some say in the implementation (even if the actuality is they didn't).

- Always start with the premise that the bug is legitimate. There are times when I'm staring at an email and yelling, "THAT JUST ISN'T POSSIBLE!" Often it's a confusion of terminology and further emails will clear up what's really happening.

- Get the steps to make it reproducible. Often I have to actually go and watch the user. That clears up a lot of "You're doing it wrong" problems and I sometimes implement further checks in the software to make sure they're lead down the right path next time.

- Give feedback on fixing the bug and make the user part of testing the solution. Unless it's a simple problem that I'm sure is resolved, I don't declare a bug fixed. I might say, "I think I've implemented a fix, will you please test it and let me know." My experience is that most users like to be part of the solution, especially if this is a problem that frustrates them daily. And sometimes I don't fix the right thing and this gives them a chance to offer feedback. AND it offers me some cover; when they complain weeks later that the problem wasn't fixed I can show my/their boss the email and say it's their fault for not testing.

- And finally, if this is a long standing bug then try to find out why I haven't heard about it before. Nothing frustrates me more than users developing superstitious rituals to work around problems and then blaming me because it doesn't work right. I can only fix things I know about; sitting at your desk and hoping a solution will magically appear doesn't help.

These large email forwards you describe suggests to me that the employees have a troubled history with IT. My experience has been that people only do this when they're frustrated because they feel they're ignored when going through the normal channels. The sad part is that it probably isn't even you directly, but rather a history of being ignored that you inherited. Nothing you can do about that except hope time changes they're behavior.

If this comment seems to lay a lot of responsibility on you, well... that's because it does. You can't change users' behavior, you can only change your own and hope they adapt too. I don't think that setting up more walls between IT and users is long term good idea, even if it does make your life easier in the short run.
posted by sbutler at 1:12 PM on January 12, 2011 [5 favorites]

In general terms:

1. a change log is very useful
2. a process for change management would help, i.e. having a test system and/or development system depending on your available resources. Testing changes before deploying them to the production system insulates you against blame. You get to blame testers, and if you've done #1, you have precise data on what has changed and in what way.
3. Work out a way to log data and performance

I've been in this situation both with a poorly performing system and with a great performing system with an end user broadcasting completely inaccurate emails about it. You need to identify the underlying issues, so that you have a good explanation for what is happening, backed up by data.

In terms of communicating the changes, have planned release dates with documentation on what has changed.

sbutler has some good stuff in terms of bug tracking. There are free issue tracking packages out there that might help with this.
posted by idb at 1:21 PM on January 12, 2011

I dealt with this for five years. One thing that helped me deal with it was to understand that most users feel helpless when things don't work the way they expect them to work, and they don't understand that their expectations are wrong. All they know is that they've been stopped by the black box and are now dependent on you to unstop them.

This requires a two-pronged approach. Part of it is what ChrisHartley said about pushing back against them and letting them know that their expectations are wrong, not the database. This is better done diplomatically and with authority, so your manager is exactly the person to handle it.

The other side of it is educating the users on the underlying issues. It takes a bit of time to develop your ability to discuss technical issues with non-technical people, but if you take a bit of time to explain underlying issues in reasonably clear English, then over time the users get the feeling that you're not bullshitting them, and the black box isn't so scary anymore.

In other words, it's all a training exercise in inter-departmental relations. Your manager should be the stick, punishing users with public shame by CC when they refuse to learn; you're the carrot, the helpful and useful IT person who helps them out when they're having trouble doing their job. This takes a thick skin, but the relationships you build up by doing it are worth it in the long term.
posted by fatbird at 2:12 PM on January 12, 2011

As for your own sanity, you might think of things in terms of "these poor, ignorant users. They just don't have a clue about how technology works." This, of course, is an INTERNAL attitude that you use to keep you sane and not let their blaming get you down. Don't ever externalize it.

Then, look at your job in terms of being a customer service position and expert hand-holder. Treat the end users as if they are a customer in YOUR store, which means treating them as kindly and respectfully as you can, even if they're being jerks. Kill 'em with kindness, and walk them through everything if you have to. If you can do this, you'll soon have even the biggest assholes eating out of your hand and complimenting you to your boss. Ask me how I know :)

Good luck to you!
posted by wwartorff at 2:31 PM on January 12, 2011

These are pre existing issues in the database, or with the environment?

I would draw up a plan to fix these issues, get costings (probably ridiculously expensive), draw all the affected people together in a meeting and pitch it to them that since these issues are so critical, its best they get separated from your day to day BAU work and set up as a project to fix. Oh by the way the cost is $HUGENUMBERHERE. Include contractor pricing to assist with BAU while you and others work on the project, server cost, development cost, network optimisation devices etc.

They'll look at the numbers, look at the impact of running as they are now and probably decide to go down the route of leaving it as is. Get all that minuted, signed off by their managers and hopefully you can forward the same email in response to every query like this you get with their managers backing.

Hope that helps!
posted by Admira at 2:45 PM on January 12, 2011

I am already dreading, however, the inevitable way that slow response and user error will result in emails to me saying URGENT DATABASE DOWN that are cc'd to everyone

More questions than answers…

• Do the email alerts need to go out to everyone?
• Have you tried finding out what's causing these problems in the first place?
• Are databases going "down" (i.e., the software or hardware is crashing) or are there blocking locks? If there are blocks that's usually because of under-engineered stored procedures that need optimizing or need to be scheduled to run at a time when there aren't a lot of users on the system.
• Are any other processes using database connections (buggy software applications, for instance) that could be causing the problems?
• Are you using a database that supports explicit NOLOCK syntax that might avoid some of these problems in the future?

posted by Civil_Disobedient at 3:06 PM on January 12, 2011 [1 favorite]

Ugh, I know what you mean. This type of blame culture, as others have pointed out, is just awful to try and deal with.

And it's even worse if you're a female in a technical position in a deep-South company. I know, because I was one. I only stuck it out for a year before I fled back to the Pacific Northwest from whence I came.

There are a lot of technical groups geared towards women, which might make you feel less alone. The Geek Feminism Blog is one of my favorites, but there are loads of others.

I would work at demarcating "your tone seems reproachful" versus people actually blaming you for stuff.

If you are actually literally being blamed for stuff, then your best defense is to keep a log of everything you do in the course of a day. That way you can say "No, I changed X on the 5th, not Y as you seem to think. I have it written down here in my files." Standard CYA stuff.

If their tone is simply reproachful, first remember that since they can't yell at the database, they will do the next best thing. You are, in their minds, the database. If they are disappointed in the database's performance they will complain to its high priestess (i.e. you).

One of my tricks is to read emails in my head as if they had been written by one of my best friends. Then phrases like "I think this was fine until yesterday" are simply statements of fact, and not dripping with sarcasm the way we would hear it if it was sent by an enemy.

This allows me to treat people as if they were acting in a perfectly polite, grown-up fashion. And often if you treat people that way... they do.
posted by ErikaB at 5:14 PM on January 12, 2011

Do you have a test environment? Have your manager sign off on some some criteria for going live with your changes - say, it's run for a week and done a million transactions. That'll establish credibility.
posted by at at 6:18 PM on January 12, 2011