- Determining What Kind of Programmer to Hire
- Writing the Job Description
- Selling the Hire
- Recruiting Full-Time Employees (FTEs)
- Recruiting Contractors
- Reviewing Resumes
- Narrowing the Field
- Preparing to Interview
- Interviewing
- Making the Decision to Hire a Programmer
- Making the Right Offer to a Programmer
- Follow Up until the Programmer Accepts
- Summary
- Tools
This chapter is from the book
This chapter is from the book
This chapter is from the book
Selling the Hire
Are you budgeted for another programmer? No? Then you’re going to have to sell your management on why you need to hire. In most cases, that means making a business case.
Think through your need thoroughly first. Do you need the new person because the team is missing a specific expertise? Can you change technologies to mitigate the need or to make the resource easier to find? With the hybridization of applications—programs have not only become systems made up of multiple objects, components, and services, but of multiple languages—you don’t have to convert your entire application. Some years ago, one of our colleagues stopped battling Ruby’s scalability constraints by sectioning off the critical area and recoding it in Scala. Another got around a display-layer bottleneck of scarce XSLT gurus by layering PHP Drupal on top.
When the expertise seems truly needed, you can make your case visually by taking a census of your team members and an inventory of their skills and presenting compelling visuals of your existing expertise against the expertise required by your customers, your products, or your marketplace.
On the other hand, perhaps there simply seems to be too much work. Be wary if that’s a short-term need: Remember the Mythical Man-Month rule of thumb that adding resources to a late project will make it later. Your management may remember it if you don’t, even if they’re not reluctant to fund a hire.
Prepare to show that you have thought through every alternative to hiring. Instead of hiring, can you carve off a piece of functionality and have it programmed out of house/offshore to the lowest bidder? Can you convert your process to agile and your product managers to Software by Numbers9 to focus on limiting development to a smaller but earlier initial release of just the highest-return features using the team you already have? Can you improve productivity and throughput by improving your team’s processes?
Often enough, even with those analyses, you come up short and need to pitch resources. When Ron was faced at one firm with having a team of 30 programmers—a fifth of the firm’s heads—and yet short what he needed to deliver customers’ work, he helped make his case by drawing a new organization chart based on customers. The chart was, for the first time, visual evidence that once each of the most influential customers had been assigned the dedicated programmers its work deserved; the remaining customers were left without any. In another case, he gathered statistics of incoming requests for work and projects completed and graphed the rapidly growing backlog of work requests.
Regardless of the analysis, you may run up against the hard fact that your budget (or the department’s budget or the company’s budget) will not let you add headcount. To get the resource you need, you’ll have to lay off someone or terminate a poor performer. If you’re doing the right thing for your team and your project and your company, you’ll likely sooner or later be faced with making tough decisions like this one to get the resource(s) you need.