Negative client feedback and you

One of the things I’m very keen on is being open about the realities of freelancing. Even though I’m over a year and a half in, I’m always eager to read pieces that others have shared on the matter, whether they’re about the realities of business, how people work, or just general freelancer musings, because they really help me learn. I’m keen to share the details of my experiences with others for that reason.

The other day I read a great piece by Stephen Hay regarding getting negative feedback from clients (itself a response to an article by Laura Kalbag), in which he signed off with “I enjoyed reading Laura’s [post], and I’d certainly enjoy reading how more people approach client feedback. Hint, hint.”. After getting to hang out with him at Responsive Day Out 2 Stephen is a top chap in my book, so I thought I’d take up his call to arms.

Stephen and Laura’s posts (go away now and read them; I’ll wait) are around how to deal with client feedback. The thing that I found most interesting when I was processing the information, was how best I can make it relate to me. Both articles deal with design work, and Stephen at one point says: “What helps keep me from getting defensive—on good days—is a sort of detachment from the work. I mentally try and cut myself loose from it. Almost as if it’s someone else’s.”. For me, I am the product. My work isn’t a web form, or a set of designs that I can be objective and detach myself from. If someone comes out with “I don’t like it”, it’s hard not to take that extremely personally, because it’s almost equivalent to “I don’t like you”.

You won’t get on with everyone in this line of work. I try very hard to be a nice, patient, helpful person, but despite this you won’t like everyone, they won’t like you, and you certainly won’t get agreement on everything you propose. What you do won’t be for everyone. What you cost won’t be for everyone. These are my thoughts on how best to deal with negative client feedback when that feedback is about you and your services.

My experiences

For those who don’t know, I’m a technical consultant – or at least that’s the current tagline. There does not appear to be an entirely accurate descriptor for what I do, and I tend to switch every now and again. I help people with project discovery and research, putting together requirements, solutions and architecture, through to prototyping and oversight during development. I also help people put together their online strategies, and to run technical teams. I’ve been freelancing a year and a half now, both on long (4 or 5 month) and short (couple of days) projects, and everything in between.

In the course of this, some things that I’ve personally come up against are:

Rejection

I’m going to write about this properly a bit later on in the year, but I’ve done something different this year and have contacted a lot of people directly about working with them, because I want to be more in charge of my own destiny. You know what happens when you put yourself out there and contact a lot of people directly? You get a lot of rejection, and a lot of silence. You might start to feel a bit unwanted, or start to question the value that you offer. I know I do sometimes.

Keep a proper list of the good things that happen. For every 10, 20, 100 rejections you get, you may be given an amazing opportunity in return for your hard work. It’s tough to keep fighting, but you won’t achieve the thing you set out to do unless you keep at it.

Remember that opportunities are often incredibly time and need-centric. Say you email your dream collaborator this week – last week they may have just finished their new site, or hired someone, or maybe they’re absolutely snowed under with worrying about redundancies and the website is literally the last thing on their priority list. They don’t reply, or they say no. This isn’t a reflection on you – it doesn’t mean you’re rubbish at your job and should give up.

You will always, always be rejected at some point in your life. It’s a cold, hard truth to accept, but learning to be objective and see past the rejection itself can really help. As I wrote about recently – if you don’t get a positive response and you really care about something, then try a different approach. Find the right time, the right person, and the right way to engage with them.

Not seeing the value

Similar to being outright ignored or rejected is people not seeing your value. Perhaps someone likes you and becomes interested in what you do but doesn’t fully understand how it relates to their business. You try to explain, and you get waved away – “oh our developers can do that”, or “we don’t find clients pay for that kind of thing”. You have two choices at this point – to politely probe further and stress your point, or to leave it at that. For example: “That’s really interesting – I actually worked with someone recently who usually did the same, however we found that I was really useful because of X”. Do their developers want to do the kind of work you’re talking about? Have they got time? Do clients not pay because it’s not being offered? Could it bring benefits they don’t know about?

Certain clients won’t be a fit, and that’s ok. You don’t fit what they need (or think they need), and they probably don’t fit what you need. It can be immensely frustrating when you know you can be of benefit to someone and they can’t see it, but if you’re still bashing your head against a brick wall even after illustrating several of your ideas, you’d probably be even more frustrated with each other if you did work together.

If like me you do a range of work, if someone asks what you do, try to turn it around and ask about their situation instead. You can then tailor your response a bit better, and mention the most relevant aspects in a way that will resonate with them.

Inevitably, at some point someone will question your day rate. Some people will try to haggle for the sake of it, which isn’t really cool, but it happens quite a bit. Others will flat out tell you you’re too expensive for their budget, which is fine. Everyone has budgets, and maybe if it’s only a case of money then you can work something out together. Sometimes however, you’ll get people who will give you an opinion on your rates. “Really? You’re more expensive than me!”. “Good luck finding work at that price!” etc. Again, these are probably people who you don’t want to work with, and who don’t understand your true value. Your rate is hopefully based on some research and some prior experience, and unless you’ve gone in with something ridiculous, don’t have your confidence knocked. It can be tempting to retort with something braggy to justify yourself, but try to keep your response short and factual, simply explaining that you feel the initial outlay of X would be equivalent to Y for their business – e.g. a week putting together a company strategy and process for deployment may cost them X initially, but that based on what you’ve seen of their problems it would save them a week for every project going forward, at a saving of X. If you don’t want to proceed, say that you’re sorry they feel that way, and for them to get in touch if their situation ever changes. Don’t alienate people by being a dick, no matter how tempting it may be.

Questioning your choices

A lot of my job is around making decisions about technology – for example which CMS is most appropriate, or which language to go with. A lot of the time there isn’t one correct answer, and decisions can be highly subjective. When you’re in a difficult situation – for example if you’re fighting against an internal team determined to prove your outside influence isn’t needed – you can find your choices being scrutinised heavily.

As much as this is a large part of my job, it’s something that I’ve always found difficult under certain situations. I don’t like being asked for snap or blanket recommendations, such as the best CMS, or best server-side technology. As well as project and feature requirements, I prefer to base my recommendations on really understanding the client, as well as the situation of the team who will be working on the project. There will always be a level of subjectivity though, and others may disagree with you. If this happens, briefly explain why you suggested your approach and how it has worked before, but don’t use this as a “so I must be right”. Instead, follow up with “but I can see that you’re very different from X, so what do you feel will better fit your organisation?”.

An example

Recently, I was brought in on an extremely last minute job for a single day, to help a design/UX agency to put together some technical details for a pitch. I was unable to speak to the client directly, and had to base my (high-level, but multi-faceted) architecture on the few bits of information the agency had gathered to date. As a rule, I have a bit of a problem with this kind of pitching and planning. I see it as being akin to pitch creative, where you’re basically being asked to put together something which will only accurately reflect client needs if you get a lucky guess. Clients need confidence that you’re sensible and that you can deliver their project, however I much prefer to work with them to identify the best solution, and to make decisions based on an understanding of the project that goes beyond an initial vague brief.

In my example, the project was won, and I returned to start to fill in some greater detail around our approach. At this point it was mentioned that the agency were struggling to find quality resource for the project around the technologies that I’d specified, and they asked whether something else would be more appropriate. Whilst the question was posed politely, and was in no way critical of me, it’s natural to instantly feel a pang of doubt when you’re in this kind of situation. As I explained, we could absolutely use other options, however with this project there were certain trade-offs that would have made an important difference, and it was these that I’d based my initial recommendations on. As it turned out when later discussing the matter with the client, their IT team had a mandatory requirement that our originally proposed server-side language was used (I’d known that they’d used it before but not that this was the case), and that they were really positive about working with the proposed approach. Resource was found, and the project is progressing nicely. I could breathe a sigh of relief that I’d done The Right Thing. But it’s not always like that.

With this kind of situation, all you can do is to do as much investigation as possible to base your decisions on. Try to stress the importance of this with the client, and build in enough time for research. Make sure that you share this with the client to help them understand your decision making process, and the impact of any trade-offs. Certain decisions won’t require their input (whether to animate using CSS or JavaScript for instance), but as with the case above, some will need their buy-in. During your work, check in a lot with them and talk them through what you’re doing, just to make sure that you’re both still on the same wavelength.

Problems do happen

If there are problems later down the line, and your recommendations turn into “I don’t like it”s, remind yourself of the reasons you made your decision in the first place. If they still stand up, and you know that you’ve had decent conversations with the client to help them understand everything in advance, then know that you did the best job that you could at the time. Things sometimes change, and that’s not necessarily a bad thing. You won’t be able to pre-empt everything, so don’t see it as your failing if circumstances later end up being different. Sometimes, however, you will mess up. You’ll make a bad choice, or you’ll miss something important, or you may have been ill-informed. When this happens, don’t dwell too long on your mistakes. Apologise if necessary, explain if you can, and as rapidly as possibly try to move towards being rational and working towards new solutions. Try not to let emotions get in the way, and to re-assess the situation as you would with any other normal decision. All you can do is learn from it, and make sure you don’t make the same mistake again.

We’re all human (I think…)

It sounds obvious, but remembering that we’re all people is an important step towards dealing better with negative feedback. Your clients are people, and they have emotions. They probably care a lot about their projects, and can get worried, stressed, or upset if things don’t appear to be headed in the direction that they should be. They probably don’t want to upset you, and their comments most likely aren’t personal, so you shouldn’t treat them as such. It’s hard to detach ourselves when we put so much into our work, but finding a way to keep your confidence up is important if you’re to maintain your sanity!