Sunday, 12 February 2012

Last week I went to get my hair cut (yes, sorry, this is a story about hair). I had thought long and hard about what I wanted. I researched, checked styles online, and bought a magazine so I could show my hairdresser exactly what I was after and there would be no confusion. I was determined I would not be spending that ridiculous amount of money on something I was not going to be happy with. I was even bold enough to ask for some changes to it at the end, which I have never ever had the courage to do before.

He did an excellent job. It was almost exactly what I had asked for, with some variations to account for my particular hair type. It was a very cute hair style that suited me. But I had a niggling doubt.

A few days later, that niggle was a certainty. It wasn't what I wanted.

However, it was what I had asked for.

Being English, the thought of going back and telling him I wasn't happy with it was horrifying. Especially since he had done a really good job of it. It wasn't his fault that what I'd asked for wasn't what I had actually wanted. But I knew what I wanted now, and I was prepared to pay for it (again).

This time I didn't show him a picture. I didn't point to anything specific. I said I wanted it much shorter after all and outlined the look I was going for. We had a conversation about it and I left it to him to apply his skills to actually implement it.

This time, I was much happier with the results. In fact, it was exactly what I wanted.

So what?

Of course this got me thinking about work. It's not just a lame excuse to write about girl stuff on a supposedly technical blog. It got me thinking about our customers.

Whoever our customers are, whether they're end users, internal business owners, external clients, or we work in a bank and have fifteen thousand layers of Business Analysts between us and Real People, whoever they are they want something from us. And in many places, we, the techies, have trained them to ask for more and more specific things, so they can be sure they're going to get what they really want. Remember that time Bob asked for that extra field on that report because it would make his job easier? Remember when Sandra wanted the workflow to be altered in a specific way? It's because they know that if they ask for something specific, the chances are better that it will make its way to the front of the work queue at some point, and when it comes out the other end it is more likely to be what they wanted.

Only it isn't, is it?

There's always another field to add, or another change to make. And your customer isn't quite satisfied, even though you did exactly what they asked for. And sometimes they don't tell you that they're not getting what they need from your system, because it's expensive or time consuming to get changes made.

The key to delivering something they really want, instead of something else that's merely adding to the weight of your code, is finding out what they're actually trying to achieve.

So Bob wants that extra field. That's easy enough. But when you ask him why he wants that extra field, turns out it's because the numbers in the reports he's getting at the moment aren't the ones he needs, or aren't quite correct. He's probably created a monstrous Excel spreadsheet into which he manually types half of the numbers from the reports it took you ages to develop, which munges them into something quite different, in order to get the real thing he wants. He's just missing this one small piece of information to get the final figure correct. It would save your company a lot of time/money/mis-typing errors if you completely re-wrote the reports Bob uses to give him exactly what he needs. Or if you gave him a tool to download CSV formatted raw data from the database.

It's not Bob's fault he can't ask for this, he doesn't know what we're capable of providing him. It's not our fault for not delivering it the first time round, we don't know what he does day-to-day. But having a conversation where we recognise where the knowledge lies (Bob knows what the output of his day job is presumably, and we know what's available and how we can provide it), and collaborating to come up with the least rubbish solution for everyone, is a step to providing that overused term, "business value".

We're not on different sides here, we all play for the same team - we want our jobs to be as painless as possible, which (should) ultimately provide better efficiency for our company. After all, we want the company to make money so they can pay us, right?

Caveat: Mileage may vary. Sometimes, with some customers, you really do need to tell them what they want.

Wednesday, 1 February 2012

In theory, I am busy writing material for my upcoming speaking events, rather than writing terribly illuminating posts on my blog (see what I did there?). In actuality I am being lazy and have pretty much taken January off for a recharge.

In the spirit of doing something which ticks both the event-speaking and blogging boxes, this is a quick update on the conferences I'm confirmed for so far. Put the following dates in your diary - these are my first international solo speaking events:

The presentation will be more of a user's guide to the Disruptor than anything we've done before. An hour isn't a lot of time to cover all the functionality everyone might want to see, so I'm still trying to work out the balance between giving an introduction/overview for those who haven't seen it before, and going into some of the cool features that have been added since I first started blogging about it. If there's anything you would particularly like to see covered, let me know - I'll put the most frequently requested things in there.

Ideally I'd run a workshop session at some point, but that will require quite a lot more preparation, so I'll only do that if there is interest in it (if someone wants to fly me somewhere interesting to do that so much the better!!).