Home Home

Quality and practice: convincing as a consultant

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
July 27, 2012

When you act as a consultant in a company, the first thing you must remember is that you're not the person who takes the decisions. While you might be the source of infinite wisdom, people will listen to you, or they will not.

When your voice is not taken into account several times, it's difficult to stay motivated: you're feeling worthless or at least not very useful in this company in your actual role, and it's very tempting to stop trying to convince anyone, or even stop giving your opinion.

In order to stay professional in a context where people don't listen too much, you need to ask yourself a few questions.

Who takes the decisions?

When it comes to the quality, it is convenient to be the only or the most influential stakeholder of a project. This is the case of any personal project, but also projects done by a company where you're the CEO or a lead developer with an ability to influence the CEO. It is so convenient because when you want the project to be pair-reviewed or when you want the source code to match the style defined in code conventions, even if your decision may be subject to discussion, you're the only one who will decide at the end.

Those cases are not too frequent. Most of the time, either you work on a project where all the decisions are taken by a committee or your superiors or somebody who will never listen to you, or you act as a consultant for a project made by other people, with no much influence on the stakeholders.

Always know who is taking the decisions. You may have an impression to be the most important stakeholder of a project, while the decisions are actually taken by the majority. You may have an impression to be particularly convincing, while the boss doesn't care at all about what you're saying, or nobody cares about what the boss says.

What is your role?

As a consultant, your most basic role is to share knowledge (1) while adapting it to both the project and the audience (2).

  1. Sharing knowledge. For example, you may have a deep knowledge of version control systems, how they help companies mitigating the risks and lowering the costs of a project, and how desperate it is to work on a project with no version control. This knowledge covers both the theory (for example, why and how version control helps a team of one or several developers to organize their source code) and the practice (for example, the last DailyWTF story you may share about a company you consulted and which had no version control).

  2. Adapting it to the project and the audience. When you're in a company which doesn't have version control, your role is not just to tell everything you've learned about version control systems. Instead, you should surface what are the actual issues this company has because of the lack of version control, how version control would solve those issues, what, in practice, this company must do in order to migrate to a version control, and how much will it cost.

The way you tell all this will depend on your audience: when talking to the lead developers, you will put an accent on their workflow; when talking to the system administrators, you will explain how version control has to be maintained and what is the impact of a version control server on the network and the servers; when talking to the management, you will explain the short-term investments and long-term savings for the company. You will also use technical terms when speaking to sysadmins or developers, and less technical ones when talking with the management.

This basic role is purely objective and neutral. You inform the company of the issues or the consequences and what to do in order to solve those issues or mitigate the risk of having the consequences the company would have if nobody will listen to you.

There is also a more subjective role: influence and convince. It's also a difficult one, for two reasons.

The first reason is that the fact that you should have this role as a consultant is counter-intuitive, and more about your personal investment. Actually, most consultants don't bother trying to convince you, showing that they don't care, but there is a slight difference between not carrying and not being persuasive. You don't have to care, because you're neither the shareholder, nor the CEO of the company, but it is your work to convince the people you consult that they should do the right thing.

How persuasive you should be?

Not trying to convince the people you consult is both unprofessional and unfriendly. Imagine a following dialog with a salesperson in a PC store:

I would like to buy a new laptop…
We have lots of them all around.
Thanks but… I would like to have some advice. I want to buy an Apple computer, but I have several apps I need to use, and I want to be sure that they are compatible.
Contact the retailer of those software products.
OK… Could you help me compare Apple laptops to Windows-based ones?
You have the specs and the price in front of every laptop.

The salesperson gives you precise and exact info. He still looks unprofessional and unfriendly, because he's not trying to convince you and stays extremely neutral and distant.

While you should try to influence and convince, you should still remember that you're not the person who takes the decisions. Learn how to stop. Some people don't care at all about what you're telling. Some other people might care, but they have their reason to not follow your advice. Some others might care and be totally convinced, but they don't want to admit that they don't have any influence on the project.


A long time ago, I was asked by a small company to consult them about their potential security issues. Since the company was a perfect DailyWTF candidate, there were lots of things to change: people shared the same accounts, audits were nonexistent, even the firewall was deactivated because nobody cared about configuring it properly, and activating it would block several services.

In my report, I isolated in the first part the most critical things to fix, then, in the second part, summarized all the fixes to make. Since the company was not caring too much about the security, it was pretty obvious that they would skip all the second part. Still, there was hope that they would at least fix things from the first part, and I particularly insisted on those issues.

Later, a few ones were fixed, a few others were not. Every person had her own account and the firewall was up and running, but the website, for example, presented a well-known security holes, and the backups were at risk. I explained repeatedly the importance of fixing those holes to the CEO, insisting that the risk is to lose everything they have in terms of data, but the company decided to spend the money on something else, considering that fixing the website is too expensive compared to the risks of having security holes in it.

When the website were exploited, destroying a good part of the company data, including a part of the backups, I were sad for them, but at least, I knew that I insisted enough to convince them to change their backup strategy and to fix their website.