Staffing Technical Functions in Software Development

What

Staffing is the most time-consuming and critical function of any company, and is especially crucial for start-ups and small companies.  Staffing of technical functions in software development companies requires careful planning encompassing skill sets, ratios between functions, transferable skills and other fit factors, and speed of hiring.

Why

Every person is critical in a small company.  The cost of a bad hire is high; hiring errors must be found and corrected very quickly to avoid lasting damage to the company.  The most effective solution, of course, is avoidance – the ability to consistently hire the right person at the right time.

Hiring the wrong person wastes significant time and money on the hiring process and resulting exit activities alone.  Technical errors made by a person with the wrong skill set and not discovered until significantly late in the development cycle (or even after release) can be costly.  Hiring a person who is overall a bad fit with the company – its culture and its people as well as its technical needs – can cause serious morale problems across the company, both during the person’s tenure and following departure.  Considerable management time, always in short supply in a small company, must be spent to correct hiring errors, either by counseling the person to productivity or by managing him out of the company.

The wrong mix or proportion of people amongst technical functions can keep the business from operating at peak efficiency.  This mix is important to ensure flexibility and to meet schedule and quality goals.

How

One of the first (and most often skipped) steps to successful staffing is to define the desired ratios between technical functions.  This will allow determination of the need for expansion in each area.  For example, establish the ratio of development engineers to quality engineers  (start-ups often use 4:1 for this); the ratio between support engineers to development engineers; and the ratio between technical writers and development engineers.  Next, create a general staffing plan including hire order and timing with respect to funding, release schedules, and ramp-up of development.  Following are some general guidelines for consideration:

1.        The key architect is frequently the first hire.  In a start-up environment, this person should also be able to code effectively until critical mass of engineers is reached.

2.        At least one, probably several, more key developers will be needed.

3.        Engineers are rarely good UI designers, particularly layout and flow, and correcting UI errors after the initial release can be very costly; however it’s rarely cost-effective to hire a UI designer early in the staffing cycle.  For a UI-intense application, consider using a UI consultant in early stages.

4.        Hire quality engineers no later than hiring of the last developer for the predetermined ratio.  (It is generally a good idea to hire the first quality engineer when the first developer is hired, then work into the desired ratio.)  If you’re unsure whether a quality engineer is needed, consider starting immediately with a contractor.  Because software quality engineering is very different from development engineering, development engineers rarely have the skill set and orientation to test effectively.

5.        The first Support engineer is typically hired prior to the first product launch unless subsequent schedules take support by implementers into consideration (note that having development engineers work directly with customers other than developers can be problematic).  Support engineers can often double as educators and sometimes as professional support – for small, early-stage start-ups, try to get someone who can wear several hats.  Take into account number of support shifts.  If the Support function is a planned outsource, at least one internal support engineer will still be needed as a liaison and center of competence.

6.        Don’t have engineers write documentation.  Use a professional contract technical writer until enough work exists for a full-time writer.  Don’t try to use marketing writers as tech writers or vice-versa – it’s a different skill set.  Look for tech writers to go contract to hire, and who understand online as well as hardcopy documentation.  Many tech writers are good UI designers as well.

7.        Monitor the amount of time engineers are spend filling I/T and configuration management (CM) functions.  I/T functions can often be outsourced effectively; CM functions generally cannot.  CM requires a certain orientation and attention to detail – if a development engineer is handling CM on a part-time basis because she has no other choice, she is unlikely to pay the attention to detail required long-term.  One good way around this is to make much of the CM simple and automated – the same talented development engineer who doesn’t have the patience to be a full-time build engineer might be an excellent choice to automate many of the CM functions.

It’s a good idea to determine acquisition and interviewing strategies before beginning the hiring process. There are many options, some of them expensive, and it’s good to take stock of your requirements before contracting for services.  Some considerations for the hiring process:

 

  • Personal referrals are always the best.  Offer a reward if possible for successful referrals.  (No one wants to refer a friend who can’t do the job, so the company gets high-quality, known candidates who are typically a good fit for the environment.)
  • Recruiters can be very useful resources; however, they can rarely screen resumes effectively because they don’t have the requisite detailed technical knowledge and knowledge of the company culture.  Don’t rely on them to screen at any detailed level
  • Be as specific (at least internally) as possible about the kind of person you want to hire for each position.  Take the following into consideration:
    • Corporate culture
    • Specific skills for the current environment and role
    • Transferable skills (‘soft skills’) – communication, flexibility, planning, etc.
    • Experience – not only regarding specific skills, but company size and culture and rate of speed of learning (critical in a start-up). Generally it’s best to avoid hiring extremely deep skills in a start-up.  If very deep skills are required in a particular area that is not the long-term product core, consultants are a better option (with appropriate documentation).  The enables a growing company to avoid having only one person knowing each piece of the codeset, and the resultant difficulties of having that person leave (or even take vacation).
    • Education (and acceptable trade-offs with experience)
    • Pay range
  • Pre-screen the candidates, even if a recruiter is employed
    • Check the resumes carefully.
    • Consider electronic screening – have a 20-30 minute questionnaire specific to the position for someone to answer.  This can be much more effective than a phone screen. 
    • Phone screen if an adept technical screener is available.
  • Prepare for the interview
    • Divide up the topics amongst the interviewers before  the interview.  There’s nothing more annoying (or a bigger waste of time) than having 6 people ask a candidate why she’s leaving her current position.  If the same people can interview all the candidates on the same topic(s), it is possible to accomplish an excellent comparison of candidates.
    • Be sure to include interviewing for fit.  Bad cultural and team fits cause many more departures than bad skill fits.  Most people know how to interview for skills – it takes more thought and preparation to interview for fit, but it’s well worth the effort.
  • Debrief after the interview