There is a joke that says that software developers have a language of their own and you should be very cautious when speaking to them in English. Having a software development background and knowing and working with a lot of software developers, I must say this is true. But what differentiates software developers and software development companies from one another is the fact that some can arise above this issue and some cannot. We have found a recipe for communication that works for us.

Respect the client

This is the first and most important rule of all.

Developers are not smarter than their clients. Usually developers will think so because clients will often come up with ideas that are not technically sound, or don’t cover all edge cases and this will give developers a chance to show off. What is often ignored is the fact that clients are asking such stuff for a reason and they know their market, they know what their customers need and want, they know what could propel their business to the next level… which developers don’t.

This is why at Intellegens we developed a culture where the most important thing in every conversation with the client is to learn as much new information as possible so we can gain more knowledge about what they do and how and about what their pain points are. Combining this knowledge and our development expertise we can then go back with possible ideas and solutions.

Also – following this rule often earns respect from the client back!

Adapt to the client

In our office we often speak about really geeky stuff and convoluted edge cases that could happen and how they could be solved because it amuses us. However, we cannot expect any client to be able to get into such deep technical discussions with us.

We need to adapt to the client. We need to learn their business and learn about their domain. And, when speaking with them, we need to speak in a way that they understand, not in a way we would want them to understand.

Ubiquitous Common Language

I first heard about this term in the book “Domain Driven Design” by Eric Evans. Eric defines ubiquitous common language as practice of building up a common, rigorous language between developers and users. The Domain Model used in the software will later be designed based on this language so it needs to be rigorous, since software doesn’t cope well with ambiguity.

One of the first meetings we have with a client when doing a new feature is about naming things – how would you call this within the industry so it makes sense. This is a step worth taking as it does help for all future communication and makes it easier for the client to understand technical issues.

Keep the technical talk at the level the client can understand

Some people are more technical than others. And you don’t necessarily get to choose how technical your client is. And it should be a given that the software development company is more technical than the client (otherwise – why would they need you?).

But, in my opinion, it is the job of the software development company to understand who they are communicating with and what their level is. And then “lower” the communication to that level.

You can do this by providing analogies, giving examples, finding ways to explain abstract concepts in a more simple manor, black-boxing (is this a word?) some things that are irrelevant for client’s understanding etc.

The one small issue with this is that, in order to be able to do this, you need to know your technical stuff inside out!

Communicate as often as possible

I’ve never heard of anyone every complaining “This vendor of mine is giving me too much info! I can’t take it!”.

Communicate every step of progress – clients always love to hear about progress.

Communicate every possible and potential issue well in advance. I’ll address this in more detail later, but, once you’re working on a project with a client, they are your teammates. And the mutual goal is to get the project across the finish line. So, with any issues the client can help, if you notify them in time.

Communicate even if nothing special is happening. Because for you, as the software developer, debugging, iterations, PR requests and code review comments are a normal everyday thing and smooth sailing… But for the client (who is not necessarily technical) a lot of what you do is voodoo magic. And an email or a call every now and then just stating that everything is going as planned and that you’re currently in the middle of doing X so you have nothing to show is also a step forward.

Make the client a part of your development process as much as possible. They will feel safer, involved and will generally be more thrilled with the awesome service you provide.

Own up your mistakes… sooner!

There will be problems and issues on projects. Deadlines will be broken. Budgets will be exceeded. Unfortunately, this is an everyday thing.

However, the way it is dealt with can be very different and can cause more or less problems and friction between the software development company and the client.

But the basic concept is: as soon as you notice something not going according to plan, notify the client immediately. It doesn’t have to be a red alert, it can just be a quick notification that, for this and that reason, you have a feeling this issue might occur, but that you just want to keep them in the loop.

The client has their own reason why they are building the software. They also have people to report to. They also have their deadlines, their budgets, planned actions that follow the launch of the feature. If you’re honest and upfront about issues, they can know in time to take appropriate action and put their stuff in order.

And yes, these discussions are never easy, but the earlier you have them, the easier it will be to focus on solving the issue together with your client.

Mind the attitude

There will be issues. There will be disputes. There will be unpleasant conversations and meetings.

But always keep in mind that, even with all this happening, that the goal isn’t to assign blame. The goal is to find a way to fix the immediate problem and keep pushing to get the project across the finish line.

That being said – it is extremely important to always have this attitude that your goal is to get the project across the finish line and help your client. Because your client is also looking to get their project done and if you’re both aligned on that, then it is a good base to start finding constructive solutions.

Solving the problem in a constructive way >> assigning blame for current situation.

Conclusion

I just wrote a huge block of text I can easily summarize in just a few lines:

Respect your clients
Communicate as often as possible
Communicate clearly in a way that the client can understand
Communicate any issues in advance
Keep a positive attitude with the final goal of completing the project

That’s it. That’s the list.

How Software Development Companies Should Communicate With Clients