How does an angry analyst deal with difficult customers? Five tips that work for me

When I do these more serious posts about workplaces issues, not so much of my angry persona leaks out. A little does, to be sure, but not so much as, say, when I’m foolish enough to get into politics. Part of this is not wanting to completely obscure serious points with humour but part of it is my nature; when I’m dealing with situations that require more analysis I tend to get more clinical and I try to keep emotional responses to a minimum.

I’m sure this is true in business generally but I know for a fact it’s painfully true for IT workers: sometimes you have to deal with “customers” (whether internal people/departments that have a stake in IT development or actual paying customers) who are absolutely infuriating. The disconnect between customer thinking and what is possible, sensible or even a vaguely good idea is sometimes truly staggering. But then again, if we were honest, we’d have to admit that some of the thinking coming out of IT departments is not even a distant relation to common sense or reality.

As a Business Analyst, I tend to be put between these two (often conflicting) worlds. When I’m in a good mood I feel like I’m the bridge between two worlds, clarifying and translating when IT doesn’t understand business needs and the business side doesn’t understand IT needs. On bad days I feel like the meat in the sandwich. My starting point is that I’m in IT and I’m usually representing IT interests – so how do I do this without losing my cool in the face of what seems to be insurmountable ignorance?

I should probably start by giving an example of a fairly dramatic failure on my part to do this well. A little while ago I was contracting with a little start-up who were doing some interesting work, very web 2.0 stuff. They are probably the best at executing this type of web based services I have seen in Australia. But, inevitably, the day came when something really dumb was proposed. A web application aimed at the advertising industry was under development but progress had stalled and I was working on resolving some of the issues. It soon became clear that the biggest issue was the manager of the internal business unit that was selling the product to advertising agencies (selling a product that didn’t actually exist – is this sounding familiar to anyone?)

The concept itself was extremely strong – an online communication tool that let everyone involved in the very complex of shooting an ad stay in touch and book each other’s time. The development was well-advanced, we had a prototype that showed how to turn what had been a manual process that could take weeks to resolve into an online process that could be set up in one or two days. But then the product manager saw some over-designed Flash-based website with animation out the wazoo that he decided was “sexy”. Everyone wants to be sexy. People in the advertising industry definitely want to be sexy. So when he showed this example to potential client and promoted how sexy it was, of course they all said that was exactly what they wanted.

Nobody wants to say “no thanks, I’d rather not be sexy.”

The problem is, this was a product designed to be used all day every day for people’s core work. No matter what someone tells you they want, what they need is something that is functional and doesn’t get in their way when they’re working. The primary problem with this over-designed monstrosity is that it would slow down every single task for the sake of animated menus, rounded edges and general “sexiness”. I needed a way to convince the product manager that his central idea that he was so excited about simply couldn’t work. No matter how much people said ahead of time they loved the idea (nobody will say they don’t want to be sexy) they will hate you five minutes after they start using it and it becomes clear this application will make their life a misery. So I sat him down and calmly said:

“This is a really dumb idea. You have to go with the simpler interface the programmers have already developed. I know everyone at the advertising agencies told you they loved the concept but trust me, they’ll find it impossible to use. If you insist on following this, the developers will hate you for making them do it and the customers will hate you for making them use it.”

Did I mention that the product manager was a senior boss’s brother? All in all, not the best career move I’ve ever made. On the plus side, after saying this the development team really, really wanted my contract to be extended. On the negative side, nobody on the business side seemed particularly impressed that I’d held up one of their own to ridicule and started to argue that “I wasn’t a good cultural fit” for the company. I probably could have stayed there if I had really wanted to (the CEO was on my side) but it was a really good job market and I decided I didn’t need to put up with that sort of crap.

So there’s a prime example of how not to do it. Here’s a few examples of how to handle difficult customers in a way that’s more likely to generate a positive outcome for everyone concerned:

1. Don’t tell someone their idea is stupid. Instead of what I did in the above example, try to steer the discussion towards a positive outcome rather than highlighting how stupid the proposed idea is. The best way to do this is to ask questions rather than make statements. People can argue with statements but they have to answer questions. I learned while researching something else that this is essentially Socratic Irony – you play dumb and treat the person you disagree with as an expert. Eventually, they’ll talk themselves into a corner.

2. Start the analysis at the highest level possible. Any discussion with a customer that starts with “I want this type of system that uses this framework and looks like that” is destined to have a lot of problems. It’s surprising how often people who dive straight into “solution mode” can’t clearly articulate the central problem they’re trying to solve when you put them on the spot. How can you arrive at a solution when you can’t even say what the problem is? Discussions should start at cloud level (to borrow a term from use case methodology) and ask in the broadest possible terms: what are we trying to achieve? Ideally, the first people to talk about an actual IT solution should be programmers.

3. Know when to stop analysing. I’m not an advocate of Agile methodology per se but you definitely need to avoid analysis paralysis. If a customer is driving you crazy with over analysis of requirements, know when to move from thinking to action. There are too many variables in any IT project to know without doubt how things are going to turn out. I’m in favour of having clearly defined goals and a plan on how to reach said goals but at a certain point you need to stop planning and start delivering. Sadly, this is more art than science and it’s impossible to define exactly how much analysis will be required in all cases (anyone who says otherwise is trying to sell you books and/or seminars). The right amount is however much it takes to execute the project successfully – don’t stop too soon and don’t go on too long.

4. Define what you’re going to deliver. It’s an irony of IT that the customer who wants something is often very bad at defining what they actually want. One of the most important roles of a BA is to articulate what is actually going to be delivered in a way that’s clear enough for the business side to understand yet precise enough for the development side to deliver on. It’s easier to avoid getting angry with a difficult customer if there’s an objective source to refer back to, that way you don’t have to argue over points in isolation because there’s always a way to bring focus back to the conversation.

And my number one tip for avoiding getting angry with a difficult customer:

5. Know when to walk away from a discussion. There will come a time when it feels like you have two choices with a particularly insane customer who is placing unreasonable demands on you: strangle them or walk away. Walking away is always the right response no matter how satisfying you think it might be to strangle them. End the discussion in a dignified way, not with a screaming hissy fit. Say: “I think we’ve reached a point where further discussion isn’t getting us anywhere, let’s leave this for a while so we can all think about it and get back together later,” and set a time for another discussion. This is infinitely more useful than screaming “I hate you! I’m not putting up with this crap any more!” and storming out.

The sad fact is that in most organisations, IT people are lower on the food chain than sales people and we simply have to deal with that. Mastering the anger that threatens to well up when dealing with people that we quite frankly consider to be idiots is a skill everyone should master. I’ve seen too many people who were completely in the right lose all credibility because they shouted, swore or stormed out of a difficult meeting. Find you own way of dealing with customer-inspired anger if none of these work for you but for your own sake, don’t let the bastards get to you.

About these ads

11 Comments

Filed under Work

11 responses to “How does an angry analyst deal with difficult customers? Five tips that work for me

  1. Oh how I wish I could say I’ve never shouted or swore at someone, or called them dumb. Usually developers or other IT people though on my part. I’ve never stormed out of a meeting though. It isn’t a good thing, I agree. Live and learn.

    I agree with everything you say here, and I think a lot of problems are caused by not properly analysing what it is that the customer wants and then letting peoples egos get tied up in a half-baked solution.

    I’ve actually worked on a few projects where everyone knew full well there was an ‘elephant in the front room’ yet carried on anyway, stepping around it, because no-one knew how to approach the person behind that problem. You could actually see new people walk onto the project, notice the ‘elephant issue’ and start to talk about it, only to be silenced by the looks of pure terror in the eyes of project veterans.

    And then at the end no one could work out why those projects didn’t deliver what people really wanted and why staff were total wrecks over what should have actually been a fairly routine job of work.

  2. the ‘sexiness’ reminds me of the most recent failed startup i worked at. they had developed a prototype cellphone app that combined ‘presence’ with ‘voice’ and ‘integrated conversation logging’ (your im’s, emails, phone calls, voice messages are all organized by person, not by time. big whoop). anyway, they went to a trade show and came back with the startling insight that the app did not have “a wow factor”. so they redesigned the entire UI from scratch. one year later, still no customers, running out of money, but at least they thought they had a friggin’ wow factor.

  3. Mr Angry – how about a book, “Sexy IT”?

    Actually your 5 points were very helpful – and can be used in any professional environment.
    Talking of Sales and IT – I know from personal and professional experience that this combintion can be infuriating at times. The mechanics and the money …

    This week I have been reading up a lot on effectiveness in communication and it does take a great deal of discipline and character. On Thursday i had an aggravating e-mail miscommincation that was then braodcast (inadvertently) by someone and … you can only imagine …

    Take good care :-)
    Nazli

  4. Pingback: Bringing the gap between business and technology « //engtech

  5. One thing I think is missing is the “bitching factor”. When you complain bitterly about the ignorance you have to put up with, it gets back to them, and you might as well have strangled them in the first place. :)

  6. Robert: Nicely put. At least where I’m working now, they’re willing to shoot “the elephant in the room” if it gets out of hand. An organisation that can’t kill bad projects is in a lot of trouble.

    Tom: I hate it when people get sucked in by that crap! Does your product work? Do people want it? The “wow” factor is a given if you have that but you can’t polish a turd.

    Nazli: If there was a book called “Sexy IT”, I wouldn’t be in it. And I can definitely identify with your out of control email situation- one must always be cautious what one commits to meail.

    engtech: I agree. Some people just need to be choked :)

  7. There’s another point: don’t play up the fact that the clients are idiots in front of the dev team. The last thing you need is to fester resentment among the developers for the clients. I’ve made that mistake, and it lead to the lead developer walking off the project because he just didn’t feel that he could work with such stupid clients. Admittedly, I full agreed with him and wished I could do the same… but you should never actually say that. The developers do need to be shielded from the bullshit to some extent in order to do their job to the best of their ability.

    Sympathise, yes. Empathise, certainly. But much like in the army, complain up the chain of command, never down.

  8. That’s a very good point. It’s hard to maintain this level of professionalism sometimes but it rarely helps if you don’t.

  9. I know the importance of controlling my temper in the face of utter stupidity, I really do. But when it hits, its still a monumental effort to not yell “what do you think you’re doing, you moron?” at the person involved.

    The next few weeks are going to see me getting a good workout on this particular skill as we’re just rolling out a new fault system. Now to be fair I’ve only seen about four bug trackers in my entire life and they were all free and open-source, so I’m not an industry expert. But ours requires IE7, opens all links in new windows, has no configurable menus or reports, and operates entirely by means of a context menu that appears when you hover with the mouse over different parts of the screen. Still, if I can keep my temper then hopefully it is good practice for the next time something like this comes along – and that’s a big contribution to my professional development!

  10. AAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHH! Oh my god that sounds horrible! I suggest drinking heavily.

  11. vaniviswanathan

    Dear Mr.Angry,

    Love your article and enjoyed the comments and your replies. You do have a great sense of humor and that definitely helps!

    I wish I had read your article a couple of years ago when I badly needed it. I did not yell, choke or call anyone dumb. I just quit my job since the stress levels broke the stress-meter at home and the child at home began feeling it.

    It was very similar to your selling the product before building it situation and also using flashy prototypes to lure customers. Added to the situation was a lunatic office manager who was also HR personnel, Project manager and kitchen manager.

    Anyway, loved your tips and thinking of using and implementing them in my next position. Thanks a bunch!

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