How to Manage Consultants

If you get appointed as technical leader of some project in a medium/big company, most likely you’ll have to deal with consultants. This is a really delicate matter, because your company is going to pay for those additional resources but the results will mostly depend on how you manage them. “Your professional reputation depends on consultants’ performance more than consultants’ careers depend on your feedback.” Use consultants, but don't rely on them. They are wonderful people and deserve a great deal of respect. Since they get to see a lot of different projects, they often know more about specific technologies and even programming techniques than you will. The best way to use them is as educators in-house that can teach by example. After all, they are here to do something that regular employees cannot do, either because there is a big workload or because employees actually don't know how to do it. However, they usually cannot become part of the team in the same sense that regular employees are, if only because you may not have enough time to learn their strengths and weaknesses. Their financial commitment is much lower. They can move more easily. They may have less to gain if the company does well. Formally you are the “customer”, so you have the right to expect what you payed for – results – but this cannot be achieved just by scheduling deadlines. To get the most from consultants, you’ll have to leverage on your social skills more than rely on project management or scrum tools:

• start building a seamless team; ask consultants to join for coffee break or lunch with you and the other regular employee team members.

• show consideration; start from remember consultants’ names correctly. It’s always unpleasant when someone doesn’t remember your name or spells it wrong, but if this is perceived not as simple mistake but driven by poor consideration by the customer personnel towards the consultant it becomes very annoying.

• create empathy; include consultants when you say "we" while talking about the project your team is working on, let them feel that they will be really part of the success you want to achieve.

Remember that an annoyed consultant will perform very poorly, resulting in an economic damage for your company and a misstep for you as a leader. If consultants are going to write code, you must review it carefully as you go along. You cannot get to the end of the project with the risk of a large block of code that has not been reviewed. This is true of all team members, really, but you will usually have more knowledge of the team members closer to you.

You should always take into account that writing readable and maintainable code is not the main priority of a consultant - its goal is to meet client expectation which are mostly expressed in terms of deadlines and functionalities that shall be implemented. When deadlines are approaching, consultant are masters in rapidly patching software to make it work quickly – even if that means to embed into source code something like configuration parameters or fake data.

This is why you should explicitly ask consultant to write good code, more than reviewing every single LOC – establish the expectation that the extra effort spent for writing elegant and reusable code will be appreciated.

Another good practice is to make every team member accountable in the same way for the work they produce – e.g. make mandatory for everyone to provide header comment blocks into programming code or editor/reviewers tables into delivered documents so that any file can be attributed to its author. Given the current emphasis about online professional reputation and personal branding, accountability will be a lever for consultants to avoid delivering something that they wouldn’t be proud of, encouraged by the fact that they could be already gone somewhere else when poor quality of their job is revealed.

Next [How to Communicate the Right Amount](04-How to Communicate the Right Amount.md)