Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update 03-How to Manage Consultants.md #104

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
22 changes: 18 additions & 4 deletions en/2-Intermediate/Team-Skills/03-How to Manage Consultants.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,23 @@
# How to Manage Consultants

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.
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 pretend 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.

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. Some will be good, some will be average, and some will be bad, but hopefully your selection of consultants will not be as careful as your selection of employees, so you will get more bad ones.
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.

If consultants are going to write code, you must review it carefully as you go along. You cannot get to the end of the a 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.

Next [How to Communicate the Right Amount](04-How to Communicate the Right Amount.md)
This is why you shall explicitly ask consultant to write good code, more than reviewing every single LOC – let pass the message 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)