“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw
The customer is always right. We learn this saying very early on, and expect it work every single time. The problem is that we usually learn the phrase when we are on the customer’s side of the counter.
As a developer, when you come across a difficult client, you realize that if you want to overcome this challenge, it will cost you some extra effort. The project may turn out alright in the end, but you will need to put your communication and problem solving skills to the top gear. Because that’s what you need to make up for the lack of proper communication from your customer’s side.
As a customer, when you turn to a software developer to build your website, you have the end result in mind. But you don’t necessarily have the understanding how information flow needs to work for smooth project implementation.
In this post I will name the common mistakes that customers make when they cooperate with developers that can put successful project implementation at risk. Generally, they fall into five categories: insufficient communication, excessive or ineffective communication, attitude issues, unrealistic expectations and cashflow problems.
So here are the tips to drive your developer nuts. I will allow exaggeration here and there, just to make it a fun read.
Lack of communication
1. Be vague
Talk about your business and the project in elusive terms, set tasks with no specifics and discuss them in bare outlines. When asked about specifics, give monosyllabic answers (“yes” or “no”). Or even let the developer take all the decisions on his own. At the same time, do not hesitate to demand precise revenue figures at the Inception stage.
2. Ignore enquiries
When you receive a message from your project manager with a list of 30 questions, only answer a couple of them. Be suspicious of this unhealthy interest to your business. Do not reply those message, never pick up the phone, stay offline. If they need the information, let them do the research.
3. Give no clarifications
When you receive a question or a request that requires internal coordination, don’t bother writing a status update or a comment. Simply send a correspondence string dating back a few weeks, in which 5 of your colleagues discuss the issue back and forth. Let the developer figure it out.
4. Don’t delegate
No matter how miniscule the problem, you want to take all the decisions. And if you are gone climbing Mount Everest for two months, don’t allow anyone to take any design and development decisions. Even if it is as small as the color of the footnote in the Contact form. You will get to that when you find a wi-fi connection. Eventually.
5. Avoid written communication
So what if the developer needs a 300-word text exactly as it should appear on your website including Greek cities or Lebanese dishes? You don’t like typing, so let them write it down while you dictate it!
6. Don’t test before launch
You have more important things on your plate. It is QAs on your developers’ team who must do the testing. If it works fine for them, go ahead and launch. If you have forgotten any features, you can always blame the developers for not asking.
Excessive and inefficient communication
1. Demand more frequent and more detailed reporting
The more frequent the better! Make sure they don’t just space out, make it clear you do care about the project and the money you spend on it.
2. Discuss. And then discuss again.
Don’t leave your Account Manager alone. Not for a single day. Ever. Make appointments, meet, discuss, request presentations, graphs and tables (and then the same information in a different format), micromanage, plan and postpone. Oh, and make sure every department in your company give their opinion about every single detail.
3. Appoint multiple coordinators
If there are two departments interested in the project, let both have a coordinator who will communicate their part of requirements. No matter if they are conflicting: the important thing is to get the ball to the developers’ side of the table.
4. Add new requirements late
Even if you have approved page design and have it done already, it does not mean you cannot demand the developers to go an extra mile and offer something new: an element or two here and there. Why should it be a problem?
1. Send angry messages
Even if you are not that upset. Do it just to keep them motivated. Even if the reports are fine and you get higher conversion rate. Go ahead and throw that negative feedback from a customer in their face.
2. Show your authority
Manipulate your team of developers, show your negativity and make them uncertain of their future in the project. Discourage discussions and make sure you always say the final word. And if they are not happy with your management style, you can always resort to threatening to leave a negative feedback to your developers’ work.
1. Set unrealistic demands
In your very first meeting with the project manager try to impress them with your rigid requirements. You want a website like Reebok’s but have no budget to hire a quality photographer? You wish your website to be clutter-free but want all that redundant information in the Home page? Remember, you are the client.
2. Ignore your customers’ needs
You are the client here, so the developers need to make you happy. No matter what your customers’ feedback suggests. Keep that director’s greeting in the front page, right next to the Corporate News section, the customers will get to the product catalog somehow, it is just a button away. Oh, and why does SEO matter?
1. Disappear on the eve of payment date
No need to stick to the payment schedule. If interruption in the cash flow means the team working on your project won’t get their salary on time, it is not your fault: you are not their only client. You can pay it later, when you are done with your priorities.
2. Start saving cash in the middle of the project
Maybe the developers could do a part of the job, say, just the design. And the rest could be divided between the developers and your employee who used to write bits of code for his previous employer. But the developers are still responsible for the outcome.
Based on the above it is not difficult to get a rough profile of a “good” client, who:
• has a clear vision of the business
• is willing to cooperate
• is an efficient communicator
• can be tough when necessary
• is able to delegate
• puts own customers first
• gives good information and feedback
• tests and checks
• appreciates counterpart’s efforts
Once again, I have written down all these mistakes in this grotesque exaggerated manner to show you that in extreme cases such behaviors from clients could pose a risk not just to the project, but to the developer’s business as such. Your project is worthwhile as long as it is possible for the developer to keep the balance between his own and his client’s interests. Should such balance be possible, the developer may actually benefit from a bit of stress. With such clients Account Manager, Project Manager and Developers can all learn to be more flexible and creative. But also it is far more difficult to predict the final result.