Quality and practice: convincing as a consultant

When you act as a con­sul­tant in a com­pa­ny, the first thing you must re­mem­ber is that you're not the per­son who takes the de­ci­sions. While you might be the source of in­fi­nite wis­dom, peo­ple will lis­ten to you, or they will not.

When your voice is not tak­en into ac­count sev­er­al times, it's dif­fi­cult to stay mo­ti­vat­ed: you're feel­ing worth­less or at least not very use­ful in this com­pa­ny in your ac­tu­al role, and it's very tempt­ing to stop try­ing to con­vince any­one, or even stop giv­ing your opin­ion.

In or­der to stay pro­fes­sion­al in a con­text where peo­ple don't lis­ten too much, you need to ask your­self a few ques­tions.

Who takes the de­ci­sions?

When it comes to the qual­i­ty, it is con­ve­nient to be the only or the most in­flu­en­tial stake­hold­er of a pro­ject. This is the case of any per­son­al pro­ject, but also pro­jects done by a com­pa­ny where you're the CEO or a lead de­vel­op­er with an abil­i­ty to in­flu­ence the CEO. It is so con­ve­nient be­cause when you want the pro­ject to be pair-re­viewed or when you want the source code to match the style de­fined in code con­ven­tions, even if your de­ci­sion may be sub­ject to dis­cus­sion, you're the only one who will de­cide at the end.

Those cas­es are not too fre­quent. Most of the time, ei­ther you work on a pro­ject where all the de­ci­sions are tak­en by a com­mit­tee or your su­pe­ri­ors or some­body who will nev­er lis­ten to you, or you act as a con­sul­tant for a pro­ject made by oth­er peo­ple, with no much in­flu­ence on the stake­hold­ers.

Al­ways know who is tak­ing the de­ci­sions. You may have an im­pres­sion to be the most im­por­tant stake­hold­er of a pro­ject, while the de­ci­sions are ac­tu­al­ly tak­en by the ma­jor­i­ty. You may have an im­pres­sion to be par­tic­u­lar­ly con­vinc­ing, while the boss doesn't care at all about what you're say­ing, or no­body cares about what the boss says.

What is your role?

As a con­sul­tant, your most ba­sic role is to share knowl­edge (1) while adapt­ing it to both the pro­ject and the au­di­ence (2).

1. Shar­ing knowl­edge. For ex­am­ple, you may have a deep knowl­edge of ver­sion con­trol sys­tems, how they help com­pa­nies mit­i­gat­ing the risks and low­er­ing the costs of a pro­ject, and how des­per­ate it is to work on a pro­ject with no ver­sion con­trol. This knowl­edge cov­ers both the the­o­ry (for ex­am­ple, why and how ver­sion con­trol helps a team of one or sev­er­al de­vel­op­ers to or­ga­nize their source code) and the prac­tice (for ex­am­ple, the last Dai­lyWTF sto­ry you may share about a com­pa­ny you con­sult­ed and which had no ver­sion con­trol).

2. Adapt­ing it to the pro­ject and the au­di­ence. When you're in a com­pa­ny which doesn't have ver­sion con­trol, your role is not just to tell every­thing you've learned about ver­sion con­trol sys­tems. In­stead, you should sur­face what are the ac­tu­al is­sues this com­pa­ny has be­cause of the lack of ver­sion con­trol, how ver­sion con­trol would solve those is­sues, what, in prac­tice, this com­pa­ny must do in or­der to mi­grate to a ver­sion con­trol, and how much will it cost.

The way you tell all this will de­pend on your au­di­ence: when talk­ing to the lead de­vel­op­ers, you will put an ac­cent on their work­flow; when talk­ing to the sys­tem ad­min­is­tra­tors, you will ex­plain how ver­sion con­trol has to be main­tained and what is the im­pact of a ver­sion con­trol serv­er on the net­work and the servers; when talk­ing to the man­age­ment, you will ex­plain the short-term in­vest­ments and long-term sav­ings for the com­pa­ny. You will also use tech­ni­cal terms when speak­ing to sysad­mins or de­vel­op­ers, and less tech­ni­cal ones when talk­ing with the man­age­ment.

This ba­sic role is pure­ly ob­jec­tive and neu­tral. You in­form the com­pa­ny of the is­sues or the con­se­quences and what to do in or­der to solve those is­sues or mit­i­gate the risk of hav­ing the con­se­quences the com­pa­ny would have if no­body will lis­ten to you.

There is also a more sub­jec­tive role: in­flu­ence and con­vince. It's also a dif­fi­cult one, for two rea­sons.

The first rea­son is that the fact that you should have this role as a con­sul­tant is counter-in­tu­itive, and more about your per­son­al in­vest­ment. Ac­tu­al­ly, most con­sul­tants don't both­er try­ing to con­vince you, show­ing that they don't care, but there is a slight dif­fer­ence be­tween not car­ry­ing and not be­ing per­sua­sive. You don't have to care, be­cause you're nei­ther the share­hold­er, nor the CEO of the com­pa­ny, but it is your work to con­vince the peo­ple you con­sult that they should do the right thing.

How per­sua­sive you should be?

Not try­ing to con­vince the peo­ple you con­sult is both un­pro­fes­sion­al and un­friend­ly. Imag­ine a fol­low­ing di­a­log with a sales­per­son in a PC store:

Consumer

I would like to buy a new laptop…

Salesperson

We have lots of them all around.

Consumer

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.

Salesperson

Contact the retailer of those software products.

Consumer

OK… Could you help me compare Apple laptops to Windows-based ones?

Salesperson

You have the specs and the price in front of every laptop.

The sales­per­son gives you pre­cise and ex­act info. He still looks un­pro­fes­sion­al and un­friend­ly, be­cause he's not try­ing to con­vince you and stays ex­treme­ly neu­tral and dis­tant.

While you should try to in­flu­ence and con­vince, you should still re­mem­ber that you're not the per­son who takes the de­ci­sions. Learn how to stop. Some peo­ple don't care at all about what you're telling. Some oth­er peo­ple might care, but they have their rea­son to not fol­low your ad­vice. Some oth­ers might care and be to­tal­ly con­vinced, but they don't want to ad­mit that they don't have any in­flu­ence on the pro­ject.

Ex­am­ple

A long time ago, I was asked by a small com­pa­ny to con­sult them about their po­ten­tial se­cu­ri­ty is­sues. Since the com­pa­ny was a per­fect Dai­lyWTF can­di­date, there were lots of things to change: peo­ple shared the same ac­counts, au­dits were nonex­is­tent, even the fire­wall was de­ac­ti­vat­ed be­cause no­body cared about con­fig­ur­ing it prop­er­ly, and ac­ti­vat­ing it would block sev­er­al ser­vices.

In my re­port, I iso­lat­ed in the first part the most crit­i­cal things to fix, then, in the sec­ond part, sum­ma­rized all the fix­es to make. Since the com­pa­ny was not car­ing too much about the se­cu­ri­ty, it was pret­ty ob­vi­ous that they would skip all the sec­ond part. Still, there was hope that they would at least fix things from the first part, and I par­tic­u­lar­ly in­sist­ed on those is­sues.

Lat­er, a few ones were fixed, a few oth­ers were not. Every per­son had her own ac­count and the fire­wall was up and run­ning, but the web­site, for ex­am­ple, pre­sent­ed a well-known se­cu­ri­ty holes, and the back­ups were at risk. I ex­plained re­peat­ed­ly the im­por­tance of fix­ing those holes to the CEO, in­sist­ing that the risk is to lose every­thing they have in terms of data, but the com­pa­ny de­cid­ed to spend the mon­ey on some­thing else, con­sid­er­ing that fix­ing the web­site is too ex­pen­sive com­pared to the risks of hav­ing se­cu­ri­ty holes in it.

When the web­site were ex­ploit­ed, de­stroy­ing a good part of the com­pa­ny data, in­clud­ing a part of the back­ups, I were sad for them, but at least, I knew that I in­sist­ed enough to con­vince them to change their back­up strat­e­gy and to fix their web­site.