What steps can I take to ensure my company gets maximum productivity out of a software consultant?

Question

I am the lead developer on a software project for which we are temporarily bringing on an additional developer hired through a recruiting agency. He will be working for us for about 6 months, and I will be in charge of his day-to-day activities and tasks. He will be primarily working on the user interface (web front-end) for a web application which has an established back-end (database and data access objects). I should also mention that he is familiar with most of the technologies/languages we are using, but not all.

This software consultant is VERY expensive, and I need advice on how to get the most bang for our buck while he is here while at the same time providing an enjoyable working experience for him. I need to know how to get him up to speed quickly and keep him busy and efficient without making him feel micromanaged or overwhelmed.

In the spirit of keeping with a question/answer format and not a discussion, please provide your best all-in-one solution to the problem at hand. Thanks!

Answer 1

I have been a consultant for a fairly long time, and hopefully I can offer some insights from the other 'side' of the situation.

Don't treat the consultant (too) differently

There are a few things that companies tend to do in this regard that negatively impact consultant's productivity. First, they share knowledge on a need-to-know basis. Implicitly this creates two tiers of employees: the full-timers and the contractors. The full-timers have more pleasant working conditions through less bureacuracy (they use informal channels to get things done because they 'know' people), more visibility into processes and easier access to tools (sometimes even better computer hardware); but at the same time the contracts get paid more. This dichotomy creates a certain degree of bitterness from both sides and instills a feeling of "I'm only here for the hours and the money". Do everything you can to mitigate that feeling.

Don't treat them as a temp, even if they are

When you're writing code there's two ways to go about it. There's the "I'm building something that people will use and reuse for a long time" and "Hack some throw-away crap to get it out the door". At first glance, consultants have more of an incentive to go for the latter because it won't be them who are re-using it 2 years down the road. But the fallacy with that logic is that consultants need to build a reputation and open the door to potentially work together again - the world is getting smaller and people in IT frequently corss paths. Make sure that your consultant understand this latter point, do everything you can to instill that feeling.

Trust their expertise

Presumably you hired them to fill a skill gap. A frustrating situation that I've sometimes encountered is having my hands tied by full-time employees. The typical scenario goes something like this: I'm brought in to do something that the company is unable to do on its own, but a full-time always needs to be in the loop and "OK" my major changes. The said employee is less qualified and effectively becomes an obstruction to get things done; the management trusts full-time employees more than consultants. As a consultant you end up having to balance the mitigation of conflicts and fulfilling your real obligations to deliver - this hurts productivity.

Make an effort for knowledge transfer

This seems obvious but it's frequently skipped. If the consultant has done something, make sure that it's either well documented or that others on the team know how the system works by the time they are gone.

Finally, understand that there are different 'grades' of consultants. The good ones don't need to be micro-managed and they're not lazy or incompetent. They have a sense of 'duty' when hired, and will do everything they can to do the right thing. They understand that they are not an employee, but a business that needs to treat it's customers (you) right.

On the other hand, if you've worked with lazy and sub-par contractors before, do not try to apply the lessons you have learned from them to the really good people. Trying to mico-manage someone who doesn't need it will only demotivate them.

If you do have a sub-par consultant, just get rid of them. You don't owe them anything, they're not an employee, they're a business that has over-promised and is under-delivering.

Answer 2

Before this person even starts, you need to get organized and be prepared to take up more of your's and orther people's time than you think.

1. Determing projects, tasks to be completed. You've probably done this which is why you discovered a need for another programmer. Mind the "Mythical Man Month"
2. Make sure you set aside your time or someone else's who is going to explain to the developer what to do and provide necessary documentation
3. Have a follow-up strategy and make sure the person doing the follow-up sets aside time to do this. Early in the project you'll want the time frame to be more frequent than with current devs. You can always ease up if things go well, but you can't always reschedule for more time nor do you want to discover at the end of 6 months that this person didn't work-out. You should know this the first week. The recruiting agency should have a person on deck just in case this person is not capable of showing up and doing the work (The reason doesn't really matter; you need to get the project completed.).
4. Designate a go to person for the dev to ask questions. You don't want him/her waiting for feedback from someone else.

If you can't do this, you're taking a risk of not getting the production you expected for the price you pay. You're not paying for benefits, sick days, holidays, conferences, training or any other benefits, so you can't compare their salary to a full-time employee. You are expecting to have someone walk in the door who knows what they're doing and has no expectations of a raise, promotion or any other expections.

I want to congratulate you for being considerate of this person and hope you can make them feel like a welcome guest and not some over-priced hired gun.

Answer 3

First - I trust that when you say VERY expensive, you mean that the cost of the consultant is a significant factor higher than the cost of an employee, even accounting for training, benefits, etc. If this isn't information you know, it's worth figuring out about where the consultant's costs rank compared to various employee levels.

Hiring

First, I'll never hire a consultant that wants to work in a vaccum unless I know that I can reap the benefit of seriously awesome productivity and my team will never need to know the same skill set.

Once and a while that's true... but I'll say it's rare.

The rest of the time, I look not only for awesome competence, but also a tendancy to speak up and be able to both discuss and teach technical issues. I want the consultant to be able to diplomatically raise issues based on their wider experience and I want them to be willing and able to teach the rest of the team what they know. If the consultant can't do this, I won't hire them, they aren't worth the extra money.

Equipping

It'd be nice if any employee (consultant or permanent) got everything they need day 1. But it simply isn't true.

If this is the first time hiring a consultant, you'll want to plan in extra time to equipping them. Not only because every hour they spend struggling is an hour you pay (alot!) for, and you can't amortize it over time, since the contract will only be there 6 months. But, more importantly, there are security things to consider when hiring a contractor. Different companies have different concerns, but there are cases where you may NOT want the contractor to have access to certain key business areas employees do. This is more standard in bigger companies with more to loose and more contractors flowing through the system... but be prepared that temporary access rights aren't easy and you need a plan.

Tasking

Be sure of it and clear on it up front. Also, make sure your TEAM is clear on it and ready to support it. Chances are, you have a set area you already know of, the things that need to be ironed out usually are:

• How does he get what needs from others?
• Who will work most closely with them, and are there processes for sharing knowledge in place? if not, let's find a way.
• What does "done" mean? Who checks that it's done?

Realize that a short time employee doesn't have the opportunity that long term people have of learning slowly. Most contractors are eager and ready to pound out work, but you need to have a clear plan and way for them to demonstrate they have met your needs. Being clearer is always better, and if you manage to improve clarity across the team for this type of work - so much the better.

In particular, consider not only the tasking of the contractor, but of those around him. If he's working on a peice so isolated from others that no one can help or learn from him, you have wasted a great deal of his potential value. But also, the personalities of those on the team come into play. I like to stick the expensive contractor near a peice of work done by my most inquistive and collaborative team members. I know that type of person will absorb a lot and be able to retransmit it to the rest of the team. Sticking the contractor near the "quiet guy" is a real risk.

NOTE: When I say "near", I mostly mean in terms of assignment - an area of the work, not a physical location. That said, physically putting the contractor in a cardboard box in a corner is no good. Integrating them as tightly as any team member into the day to day flow is essential, and making sure they are not even physically in a corner, or back alley is a good idea.

Be a bit aware in the first weeks that you may need to make fast adjustements - if the inquisitive guy is bugging the life out of the contractor, you may need to make changes... the goal here is to make sure your team is learning, so that can be a real art, not a science.

Team Expectation Setting

Get clear with the team that this guy is here to be a team member and a teacher. If they aren't checking in with him, asking questions, asking for input and offering their own ideas, then they are wasting a great opportunity. Contractors serve a special need - a lifetime contractor has worked in MANY more companies than the average employee, and so has a vast real world expertise on good and bad ways to implement best practices. A single best practice may look obvious, but how your company does it vs. another company can have a significant impact on the outcome. Tap that insight and help your team leap ahead.

This usually requires quite a few chats in both group meetings and one on ones... you may have a naturally collaborating team who tackles this with no problem... but I'll say in my years as a development manager, I had 1 team ever who was "naturally" good at this, and many others for whom having a contractor on staff was the reason we had to push to become better sharers.

Check In Early and Often

Given that you only have 6 months, realize that you may need more check ins, not less. If you make it a point to meet with the guy one on one once a week, you'll manage around 25 sit down conversations. That's pretty good. Do it every other week, and you have only 13 occasions to share knowledge. If you told me I had only 13 chances to get someone to be efficient in a new group, and if I failed I'd loose a lot of money - I'd opt for the weekly meetups.

I find a one on one with the lead/manager to be particularly key for contractors - some of my best have had really great insights that were sometimes quite cynical. So having the opportunity to hear the insight (and the cynicism) privately, was a great blessing. Every organization has it's weirdness, and contractors often pick up on it faster and more clearly. Having that insight is both very helpful, but also slightly disheartening because it can strike at the root of organizational culture.

Personally, I like hearing that critique in private, so I can decide how best to try to make change without the rest of the team thinking "why are we so messed up??"

Also, it lets the contractor tell you honestly how things are going and where the points of impedance are so you can go back through equipping, tasking and team expecations as need be.

And... worse comes to worst, if you really can't get the contractor to work out well, go back to step one on hiring - at least if you do the steps above, you can feel relatively comfortable with having given this your best effort.

Answer 4

I need to know how to get him up to speed quickly and keep him busy and efficient without making him feel micromanaged or overwhelmed

Give the consultant proper documentation to your system, so they can get up to speed quickly. Ensure they have a go-to person to answer questions they have (and they will have). Make sure they have all the tools normally needed for working with your product (assuming they don't have their own).

Detail the required work you expect them to achieve and explain what their boundaries are - what they are allowed to change and what they are not (or at least, not without discussing with you or someone in the know).

Trust them to be professional - you can verify progress by having a weekly meeting with them to discuss the progress and expectations for the following week. You can also track their actual productiveness by looking at their outputs (with software you would be looking at checkins, features delivered etc...).

Modern project management approaches - kanban and scrum for example can be an effective way to gauge progress, in particular when using a task board. This allows the person self-manage their tasks and gives you control over the priority and actual tasks you need to tackle first.

Answer 5

While you may have an idea of the technical work being done in terms of the Web UI to be built, do you have a list of other pieces you'd want him to have done over the time of his contract? Do you have secondary objectives that may include passing on some of his technical expertise to the team so that they can maintain the code he writes as presumably this will have to be maintained somewhere?

I'd probably advise somewhere in the first couple of weeks to have a team lunch just to help build the bonds within the team of the new guy. This doesn't have to be fancy but the idea here is to help get those already on the team to help get to know the new guy. Similarly, towards the end of the contract, it may be worthwhile having a farewell lunch assuming you all work typical daytime hours.

Talk with the consultant to see how often in that first week does he want to touch base. Perhaps it'll be a few times a day in the beginning and at other times I could see it being once every few days for the other end depending on his social preference. This is something where you want his input to help figure out what works best as in the beginning there is that ramping up that can be tricky at times.

Answer 6

For the 6 months you have them, they should be an equal member of the team, treat them like it:

• Don't put unnecessary impediments just because he/she is a contractor
• Don't give them the old slow workstation
• Don't deny access to documentation
• Don't make it harder for them to access development and test environments

At various former (and current) employers, I have seen this happen. Even if they are just average cost, if you expect them to be as productive as your full time developers, they need all of the same resources. If documentation or access needs to be limited that much for some business reason, then maybe you shouldn't have a contractor, because you're throwing money out the window from day one.