A few weeks back, I had the unique opportunity to visit my old employer, this time however as a customer. It was good to hear some old terms which I last heard when I worked there. It also got me thinking that, throughout my career I worked as a software developer who developed software for other clients and now here I was looking at a bunch of inquisitive developers asking me questions.
The tables had turned, from a service provider + developer, I had now turned into a customer + developer. This unique experience also made me think, what can I learn from it. If I am the customer, what do I look for in my consultants. Or conversely how could I have be a better consultant + developer based on my new found position.
So here goes, these are the qualities I believe every customer would appreciate -
Have no fear -
No customer would appreciate that the developer on the other side never expresses his opinion or always agrees to what he says. This makes the customer feel that the team is not thinking on its own and his decisions can make or break the project. I myself have been guilty of this, I just sat through a whole lot of meetings just listening and never expressing my opinion as I thought "Who would care about what I say, I'll just do it the way they tell me to". Or "I am way too junior to express my opinions, better shut up and listen". However, when you are on the other side of the table you want all sorts of inputs / validations / questions to see if you are going in the right direction.
Express your opinion -
Kind of extension to the point above. Any customer would want to hear to how a developer plans to achieve a solution. There may be a obvious solution but if some alternate ways exist it is best to discuss them. If your opinion is not in line with the customer, still go ahead and express it. It would be a huge relief instead of anything else to the customer as he/she will understand that this team is thinking about this project and wants to do it in a best possible manner as per their knowledge. If differences exist between the two parties, they can be mutually resolved through discussion and analysis.
Communicate clearly and precisely -
This is a cliche and every developer is told to do this. Yet, it is surprising that so few of us actually practice it. When I was over the phone and the customer asked a question, me and my team would sometimes nod as that's what Indians do but surprise surprise the customer could not see the vigorous shake of heads over the phone. Another example is when a customer asks a question, we the developers first tried to whisper a solution among ourselves and before speaking it over the phone but when you are on the other side of the phone you wonder if anyone even listened to your question. Personally I am trying to implement an idea to speak over the phone whatever I am doing like - I am clicking on the link right now" or "I am thinking about a possible solution". Remember keep the customer engaged and informed.
Build trust -
This is one of the most important things. In fact, most people will say that this is the most important thing between a customer and a consultant. But how do you build trust specially in a new engagement. The only way to do this according to me is to showcase progress regularly, give and get frequent feedback and share your status at the start of the day and at its end. This is where Agile can help, with sprints, daily standups and sprint review you have all the necessary tools available with you. Feel free to talk more and more in the first few weeks of an engagement just to let the customer know that you are working and the project is constantly on your mind.
Well here I am with all the points I could think of. Developing software in India is unique in its own way, the customer is usually in US or Europe, you only meet the customer once or twice a year and then everyday there is this huge time difference. We also have a lot more service providers than product development companies. So if you are working in a service provider setup then apart from developing great software you will also have to take a lot of other things into consideration and sometimes these small things can be a difference between a sad project and a great project.