Skip to main content

5 Tips for Developers Working with a Client Directly

Dec 04 '15
developer working with a client

Every now and then as a developer you are faced with a situation: you need to communicate and work directly with a client. This can be stressful for any developer – especially those who feel like their social skills are subpar compared to their code skills.

Developers working with clients directly can happen for various reasons. Maybe the project budget doesn’t have enough overhead for a project manager, or maybe it’s easier for the client to address the developer directly because the technical requirements might get lost in the “phone tag” game between the client-PM-developer communication chain. It’s not ideal – there are reasons that project managers exist – but sometimes it can be necessary.

Whatever the reason, there are some basic guidelines and strategies you can follow to make it easier on yourself.

1. Remember that you represent your company.

This one should be pretty obvious, but bears repeating. From the client’s perspective when they talk to you, you are the face of the company. Be professional, be courteous, and dress accordingly – even if the client, themselves, are not any of these things. You should be focused on getting the project or task completed the right way and making sure the client is happy. Try to keep your emotions out of any conversation – they’ll usually just cause issues and friction (unless it’s being happy!).

2. Make assurances, but not promises.

This mostly applies when talking with the client over phone, video, or in person. If the client asks for a “rough” estimate and you aren’t comfortable or are hesitant to giving one, tell them this and explain your reasoning. This could mean you need to do more research first, or you can’t give an estimate until the requirements for the task are more defined. If you need to do more research, can you give them an estimate for how long the research will take? Usually clients are looking for next steps or a way of getting to their next goal. Help them find it. If you do give estimates, make sure the client is aware that the estimate is indeed a very rough one and may change. Make them aware that the rough estimate may not include time for non-developer related time: QA, for example. Even if you are fairly certain of your estimate, always give yourself some time to think it over after the meeting before making any promises.

3. Don’t be afraid to get technical, but understand your target audience.

Project managers can sometimes be a “translator” between the client and the developer. They are able to take the technical jargon that the developer will spew and say it to the client in a way they can understand. When working directly with the client, you don’t have this luxury. Depending on the technical knowledge of your client, you should try to adapt what you are trying to say into something the client will understand. Feel free to use analogies or visual aids. If what you are trying to communicate can’t be translated, then help the client understand the underlying technical information in broad strokes. They will appreciate the effort.

4. Overcommunicate.

Unless the client tells you to stop, you should be overcommunicating with them about every part of the project. Whatever you can do to give the client confidence that the project is moving forward will make them happy, and a happy client is a happy developer.

5. Be prepared for meetings.

This has a double meaning. You should prepare notes for meetings and you should be prepared to have more meetings than expected. For your notes, you should spend 10-15 minutes or more before a meeting to give yourself a list of talking points to cover and review any documentation that was given. If there are multiple people on the meeting, give yourself some time to research who they are, and what role they play at their company. The more context you can have going in, the smoother (and faster!) the meeting will go. You will most likely be a part of more meetings than you would typically get invited to on other projects. Some of these meetings may not seem like they require a technical person, but since you are working directly with the client you need to be a part of these to make sure you are understanding and setting expectations with the client.

Hopefully these tips will make working with a client easier and less stressful for a developer. If you’ve been in this situation before and would like to share your tips or stories, please comment below.

Read more about: