I blogged last week about how Professionalism means telling the customer when they are wrong. Gonzales commented with a really important question – “What if the client is not just wrong, but stubborn too?”
This has happened to me and to you. You feel that there’s got to be a better end result than compromising your professionalism and delivering software that you know doesn’t help your client as much as it could. You want to take pride in your work.
There is a way to stick to your principles and still keep a positive relationship with your client. It’s all down to how you present your case and how you listen to their case. To make it easy to remember, there are 3 steps based on a technique called “Principled Negotiation” you can follow which really work – and when you pull this trick out people will know it was your professionalism and skilled negotiation that got everyone to a better result.
Suppose your project has already started and there is already financial commitment from both sides. The details are being worked out in an Agile fashion as the project progresses and so part way through your client contact, Jessica, sends you a friendly email that says
“This iteration, could you store passwords in the database as plain text so we can email them out to our users later. Looking forward to seeing it ASAP.”
It’s easy to feel like taking an absolute “no” stance would jeopardise the project – even though you are doing it to prevent your client from causing harm to herself and her users. You can’t risk those passwords going public.
To you, it’s a very clear cut case that you are right. You may even be liable if you agree to do as she asks and later somebody sues.
Positional Bargaining with your clients is a bad plan. You could waste a lot of time and create bad feeling by arguing “we know technology and you’re wrong – it should be like this,” while Jessica says “we know our users and you’re wrong – it should be like this.”
You need a different method. You need Principled Negotiation.
There’s a whole book on the idea, but stick with me, I’ll break it down for you.
1. Get both parties’ interests on the table
What do you want? Most likely your goals are not contradictory. In this example, you want users’ security protected in the case of email interception and in the case of database breach; Jessica wants the process to be easy – or maybe she is thinking ahead to another feature they haven’t mentioned, for example in some cases plain text passwords have been stored in order to allow users to authenticate with a customer services operator by phone.
Once your interests are clearer, you may be able to invent other solutions that satisfy both of you – e.g. there are documented solutions using multiple different types of secrets to enable telephone authentication without risking the users’ primary passwords.
You need to separate the people from the problem. Jessica isn’t stupid. She’s an expert on her business goals. But she might not understand or value your goals. Actively listen to her – this will help encourage her to listen to you too.
If your first response to an issue during development is to consult your contract and figure out what the minimum work you can contractually do is, then you may permanently damage your relationship with her. It should be a last resort, and one that you and she both know was needed because negotiation broke down.
So find the common ground first.
2. Insist on objective criteria for the negotiation
Some of your goals might still actually be in direct opposition. For example, when I interview for a new job, I want the highest possible salary; my employer wants to give me the lowest possible salary. If you can’t solve the issue just by talking through what else each party can bring to the table, then the next strategy is to appeal to an independent source.
This doesn’t necessarily mean you need to bring in a consultant. In the case of you hiring me as a software developer, we could agree that we will start from using market data on average salaries for developers with similar experience. And then we just need to work out the value of your company’s unique benefits and my specialist knowledge, and adjust accordingly.
In the case of the plain text password feature, we could all agree (preferably before the outset of the project) that if we reach a disagreement like this, that we will refer to an unbiased external authority. In this particular case, we could agree that external authority to be Troy Hunt’s blog.
You could also introduce your own custom external authority before the start of the project in the form of a code of ethics.
Your ethical policy might include something like “We believe in protecting users’ private details.”
I’m not a lawyer. But I believe that because there are no promises here, that means that this principle does not introduce additional liability on the company in the case of an accidental breach. You might want to talk to your legal team.
Your ethics are unbiased; they apply equally to all projects, and there is nothing personal – and therefore confrontational – about you appealing to your company’s ethical policy during a dispute.
3. Have a fall back position
It is most often in the interest of both parties to reach agreement. But sometimes it really isn’t. By having thought through the fall back plan, you can make it easier to stick to your principles. If your client attempts to strong-arm you into compliance with threats, you can make your fall back position known.
Having a code of pre-disclosed ethics or a contract with get-out clauses helps with this. For example, working in the veterinary profession, my wife has her clients sign an agreement before their animals undergo surgery – if there is an unforeseen complication and Fluffy’s owner cannot be contacted, then they contractually agree in advance to a fall back plan – that the vet will use their medical expertise to take whatever action is in Fluffy’s own best interests. The principled appeal here is to the idea of what the animal would want, and this is something that other independent vets can agree on.
You may have several fall back plans
- kill the project (extreme and costly, but always an option)
- do not develop (and do not charge for) the authenticated features of the project
– in some projects this may be viable.
- develop exactly what was in the initial contract (assuming the ethical violation wasn’t something you already agreed to)
Given these plans, you can now more confidently say to Jessica that if you cannot reach an agreement then you may not do the work.
In light of your fall back plan, alternative implementations may be more appealing to her – such as just going with your recommendation, or perhaps agreeing to use a 3rd party provider e.g. OpenID.
It isn’t always that hard
So what about less clear cut cases – maybe you want to encourage a client to use a different UI than then one they propose because you believe it will be more effective?
These negotiations should actually be easier, because less is at stake. Your fall back position may be “do what the client says”.
In terms of Principled Negotiation, the objective criteria you bring to the table might be in the form of referring to past projects or published articles on design. You and your client share the same goal – high user engagement. Perhaps you could invent a solution that works for both of you; for example using analytics and A-B testing to determine which UI users prefer.
Clients may not even be aware of the usage data you could capture – this could be a real value-added for them, helping them know that the application is the best it could possibly be.
I strongly believe that digital agencies regularly sell their own skills short by blindly following their clients’ plans rather than bringing all their expertise to projects and acting as technology experts for hire.
If you’ll indulge me while I make a sweeping generalisation, ALL of the conflicts I’ve seen around features that the client or developers strongly disagree with have stemmed from a lack of communication. All agile methods advocate having the customer as part of the team because constant contact massively improves shared understanding of their business goals and of your technological expertise.
I hear many developers say “my clients are stupid.”
I’ve heard many clients say “my software developers are incompetent.”
Did you ever take the time to listen to each other?
For more about Principled Negotiation, you should buy Getting to Yes by Roger Fisher and William Ury. If you read this book you’ll never think about negotiation the same way again.