Your project is slipping, and your boss is panicking. You and your team need a few weeks to grind on the code, free from twice-daily meetings with a befuddled business driver constantly asking why you’re behind schedule. Unfortunately, your manager has a different idea. Instead of breathing space, you get that new developer you asked for months ago at the start of the project.
Your goal is to pull this new person into the development process while losing as little time as possible. If you’re early enough in the project, it might make sense to take the two weeks or more needed to train your new team member so he or she can be genuinely productive for the duration of the project. If, however, you’re nearing the end of the development effort, you may be better off finding a way to make the new hire marginally productive while you and the rest of your team drive for completion.
Place them in stasis
One option is to let the new developer sit in stasis for a while. This is by far the least disruptive solution from your team’s point of view, but it can easily backfire. A sufficiently industrious new hire will be pestering the boss for something to do in no time at all. Your boss will be annoyed, and you’ll look ungrateful. Just as your manager blows the remaining quarterly training budget at the end of each quarter to avoid appearing overfunded, you need to make it clear that every resource you’re given is a resource you need—even if you don’t need it just yet.
Here’s where your internal documentation policies and practices get put to the test. Are the project documents sufficient to keep the new hire busy for a while? If you’ve been doing a good job detailing your decisions and the reasons behind them, you’ve got a good first step. New hires expect to be given a lot of chaff to sift through, and that pile of text will buy you a few weeks’ solace.
With a little advance planning, you can do even better than that. Maintain a team-wide to-do file in your documentation repository for a ready supply of small, nonvital tasks to foist off on the new team member. Any task, from documentation polishing to source tree cleanup to simple refactoring, makes a nice fit, as long as it requires minimal instruction and isn’t necessary for project completion. If the task is sufficiently difficult, you can even use it to evaluate the new person’s skills.
Follow up on fixes and regression tests
If your internal documentation is sufficient to give a general idea of the nature of the project, your new hire should be able clean up the problems that linger around projects. It may be the case that the new team member hasn’t written an interface layer between your company’s legacy accounting system and your new CRM package, but that doesn’t mean he or she can’t identify duplicated code that can be consolidated and generalized into a library that’s more easily debugged.
Which brings us to yet another task your new coworker can do without a lot of training: unit test cases. If your team uses unit test cases for regression testing, you’ll always need more of them. If you’re not using them already, your new hire can be tasked with identifying a system that fits your language and methodology. He or she can then start your team off with tests of some of the simpler system components, expanding the tests’ scope and complexity as his or her familiarity with the project increases.
Don’t feel guilty
If you feel guilty about stalling a new hire until you have the time to fully integrate him or her into the team—don’t. If your new team member is at all experienced in software development, he or she has been in the same position and likely understands your frustration with an eleventh-hour transfusion of new blood. Besides, up until a week ago, this person was probably unemployed in a tight job market and is happy just to be working again.
Whatever you find for your new hire to do, remember that your goals, in increasing order of importance, are:
- Appear appreciative of the resources your boss saw fit to throw your way.
- Keep your development process on time and on track.
- Squeeze whatever small bits of productive work you can from the new hire.
You’ll have more time later to merge this new hire with the team. As long as you’re all personable, your new team member will understand and overcome an uninspiring first month’s work.
How do you incorporate new team members during crunch time? Drop us an e-mail or post a comment below.