Contact with client from developers' perspective in modern IT
Find out the good practices on how to improve your contact with clients.
Right now, an IT industry experiences vast changes. A few years ago, a developer wasn’t that concerned about contacting clients or any non-technical persons - Project Managers or CTOs took care of this. These days, we more often see the increasing trend of allowing or even encouraging developers to take more active part in the relation. For many, that’s just an inconvenience; something that drags you away from development.
Yet I find this trend an amazing opportunity. Combining developers’ technical knowledge and creativity with clients’ potential vision and knowledge in the field of business, we are able to achieve something truly amazing. Ultimately, isn’t it something that defines a true senior developer? The ability to deliver a highest quality product that meets the expectations perfectly or even exceeds them?
That said, please stay awhile and listen.
First of all, a client-labourer approach - diminishing a developers’ role, and ridiculously simplifying the complexity of the relation. The goal is to aim for a partnership, and it’s always desired to work with the client, not specifically for him. Given the odds, it’s often difficult, requires a lot of work, and professionalism combined with engagement.
For starters, it’s good to understand what client expects from the product. Approach “I code, you talk” is a big no-no. If the main goal of application is to make people’s lives easier, and you immediately see that there is something horribly wrong with the design, say it! Talk about your concerns. Show you really care about what you deliver - the product you work with. Come on, you do. If you can engage the client, and say:
This wizard - with tons of inputs and popups - won’t be convenient at all. We should aim for something far more user-friendly, like canvas based, drag&drop feature.
it could be a win-win situation. Client will get a far better product, and come on - it will be dozen times better to code something that complex - than a bunch of forms.
The real deal
Of course, coming up with an idea is barely the first step. Convincing someone to go your way - and often paying a lot more than he/she planned - is a hard cake here. Firstly, describe what you’re willing to achieve. Why that would make such a difference? Honesty is vital here. I’ve been in situations when saying it’s the modern way, or even that the wow factor of my idea is great cut the deal. A given client wants a certain outcome - understanding this will give you a good way to go with.
When you’ve got the curiosity, aim for attention. Be professional and provide decent estimates. Try to estimate what amount of work really has to be done and how much time it will consume. Nothing fancy - plain and simple. Client liked and approved it? Fantastic - everyone is happy. You can create something better, and client gets something better.
Now, let’s say that it didn’t work out. Client either couldn’t afford this solution or he/she simply knew that the target audience is far more familiar with a simpler solution. That’s still good for you. You not only show the initiative to improve the product, but also that you care. That builds a sort of bond between you and the business side, like:
Yeah, this guy wants to improve the product!
While it doesn’t sound that ecstatic, it’s a milestone in relations.
When the client understands that you want to work with him/her on something - rather than for him/her - and how beneficial it could be, you will be defined utterly different. Your word will have much more meaning, and the next time you can achieve much more. And let’s be honest, who you’d be willing to give a raise? A guy who sits silently, codes his part or a guy who wants to do better on many layers?
At last, when working in a project designed to be used for years, we want it to be great. We want to be proud of our job! Showing this openly is a damn good thing.
Turning the tables
Let’s assume that the situation is quite different this time, and something went horribly wrong. Estimate was way too optimistic, proposed solution eventually turned out to be incorrect - whatever. The issue is that development will take more time than necessary and someone will have to pay for this. It can be quite a tense and stressful situation, especially when the budget is not infinite.
This case could be handled by a Tech Leader or a Project Manager, yet it’s very professional when the developer takes responsibility for that. It’s always better to speak for yourself, than through advocates.
First, there has to be good, well described reasoning for such occurrence. There is no need to dive into technical details, because business side will rarely find any meaning in that. It’s always decent to prepare an estimate of how much more time the functionality will consume. This way, both you and client know where you stand.
It’s good to avoid being defensive. The issue is here and now, so bringing up the past is not a good way to go. Remember, extended time of development happen quite often, there is always something to do to work this out. Only peace can save us.
Relations with client are just the same as with your colleagues. There is nothing magical and the rules are similar:
- Remember that the person on the other side is just like you. You want to be treated with respect, listened to, so always do the same
- Avoid pointless arguments. Transferring from empty to empty only increases the tension and leads to frustration
- Don’t mistake friendship with partnership. Being friends with client doesn’t cut the deal in contacts and while being helpful, won’t solve the case
- At all cost, avoid brown-nosing
Contacts with clients can be tough as nails. It’s very difficult to establish a good partnership with someone who decides about your pay check. Yet, getting this done can lead you to a true seniority, and being a real deal on the market. It can also give you more impact on what you are doing.
Ultimately, good communication between technical and business side will lead to the creation of better, more user-oriented product. The atmosphere of the development itself will be much better as well. Remember:
Anyone who imagines they can work alone winds up surrounded by nothing but rivals, without companions. The fact is, no one ascends alone.