When an organization is understaffed and the work is flowing in, you have a couple of alternatives available to you:
- Hire like mad and fight the battle to train those people up into the organization.
- Choose portions of the project to outsource to a body shop.
- Try and throw "productivity enhancement tools" at the problem.
Let's talk about the risks associated with each of these approaches.
Hire like mad and fight the battle to train those people up into the organization
When is this a good idea? I think it's appropriate when you have strong technical leadership but not enough junior staff to try this approach. If you have leaders, you can teach and you can monitor. Each current staffer can probably train and mentor 4 other programmers IF THEY'RE NOT DOING ANYTHING ELSE. You do the math. If you have enough managers and leaders, maybe this is a possible play for you. Otherwise, all the wishing in the world is probably not going to make this work.
Choose portions of the project to outsource to a body shop.
I think this is my favored technique for organizations that don't have enough managers to decently oversee the influx of new staff. It can be dangerous because you're buying yourself a future maintenance burden on code you didn't write or control, but at least some of the dangers of this can be circumvented. As long as you demand that the 3rd party organization work only with frameworks and technologies you have a solid grasp of, you have some hope of escaping without a maintenance issue you don't understand. Reading between the lines, this does imply that you will take on some serious technical managerial overhead in outsourcing, but all you've done in this case is set the requirements for functionality and tool set. Your burden then becomes one of monitoring compliance with your requirements, not teaching programmers a way of doing things.
Try and throw "productivity enhancement tools" at the problem.
Then there's trying to throw productivity tools at the problem. Now the programmers reading this will all groan and act like they already know this is a bad idea. I actually disagree. Tools are certainly PART of every shop's answer to making their employees more effective. The problem is that when your shop is short staffed, the odds that you will do a decent job of evaluating, selecting and implementing the usage of a new tool drop dramatically. Senior management is quite capable of coming back to the staff with all sorts of promises of a tool's potential, but without some evaluation time from the staff, that's just marketing. And even if you find a tool you think could help you in general, that doesn't mean it's appropriate for your specific crisis.
I think in most cases, the most potentially successful play is probably to oursource pieces of the project to a body shop that is specifically governed about what architecture and tools it can use to manage the code for your project. I'd certainly prefer to hire where I can, but a massive influx of staff can be very hard to absorb and you're likely to let in a couple of less than stellar people in the push to hire. Tools are super, but I don't think they're ever likely to be the silver bullet solution to a short term problem.
Posted by karen at November 12, 2004 09:56 AM