Resources
- Details
- Written by: Kim
- Category: IvyBay Papers and Publications
- Hits: 6308
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
- Details
- Written by: Kim
- Category: IvyBay Papers and Publications
- Hits: 6015
What
People are the most important success factor in any size technical company. Even start-ups need solid management to support their people and solid tools to support their managers. It’s important to build in some amount management structure and focus to ensure that the company retains its valuable employees. Although the information in this paper is specific to technical employees – and most specific to software development and other software professionals - the concepts are applicable to all employees regardless of skill set or background. Good management is critical in any company.
Why
In a software development company, workers are the only real assets. The loss of any key engineer is a blow to the company. In a small company – and especially a start-up - every worker is a key worker. Retaining employees requires excellent management, even in the post-dotcom era. Stellar engineers will often follow trusted managers from company to company. Of course there’s no way to put a management treatise into a short subject paper, but the basics are consistent and straightforward. Each person must be treated and evaluated fairly and consistently. Identifying and correcting performance problems is essential to the morale of all employees – no one wants to be picking up after others when there’s already more than enough work to go around. Professional development, including career path and education, must be addressed for each employee. Finally, from a practical perspective a solid base must be created in order to avoid any legal problems.
How
Define job levels and pay grades The first step in developing good management practices is to hire and pay consistently. In order to do this well, the company will need job titles and/or levels, and descriptions for each level. The description should describe the expectations of the job at the specific level – assignment types, skills and skill levels, education, and experience. There should be a pay range for each level to (public or not) to ensure that employees of similar skills are paid at a comparable level. (No matter what management thinks or directs, employees almost always discuss pay levels and stock options with peers.)
Communication
Regular communication with each employee is crucial. Employees have differing communication needs – some will need weekly meetings with their manager or team lead, others like drive-bys, still others just prefer to find and talk to their manager when they feel the need. The key is to determine each person’s preference and try to accommodate it. Some people will simply want to use the manager as a sounding board; others will want regular performance feedback and direction. Still others want to know that things are going well. If managers in the company are too busy to keep up this kind of communication with each direct report, work should probably be re-allocated. In any case, reviews should be held no less frequently than yearly, and nothing in a performance review should ever be a surprise. People need to know when they’re performing well and when they need improvement, and should always receive sufficient opportunity to make improvements after receiving feedback.
Professional Development
All employees want (and deserve) professional development. Unfortunately for managers, professional development means different things for different people and a formal development program is often not practical for a small or rapidly growing company. There are, however, some fairly easy things that each manager can do to ensure that employees feel their development needs are recognized, even if the needs cannot be met immediately. It’s important for the manager to determine the needs of each employee and to be able to offer advice on how to proceed with development. For some employees, development simply means promotion to the next level. These people will need to be coached to perform at the next job level (one of the places the job descriptions are very useful) in order to be promoted. For others, development means expanding certain skills to a greater depth – more expertise in a particular technology, for example. Once these needs are understood the manager can use job assignments, technical mentoring, and outside classes to help the employee gain the expertise. For some employees, development means expanding to a greater breadth – gaining new skills in new (but associated) functional areas. Again, job assignment, mentoring, and classes can help the employee obtain this breadth. Finally, some employees will want to develop skills to move into another job area entirely. This is a much slower process and needs to align with company goals and needs, but should involve identifying the skills necessary to move to the job area and providing assignments and classes to help gain those skills. For all of these development needs, the manager and employee should come up with some sort of plan. Such a plan is not a contract with the company, just a loose direction to help keep moving in the right direction. Review the plan and needs regularly – quarterly is good – because people and circumstances change.
Career Progression
To prepare the company for growth as well as to aid in employee development, it’s very useful to establish a career progression for each technical function. For example, development engineering typically has either 4 or 5 levels, from junior to very senior and ending at architect. Using job descriptions, it’s fairly simple to plot out the skills progression from level to level. This helps employees to determine what’s needed to reach the next level (and to decide whether the next level is something for which they’d like to aim – often job responsibilities include more staff/administrative skills and activities at higher levels, and not everyone is interested in the change). It also helps management determine whether more employees are needed at different job levels and whether current employees will be able to fill the needs.
Reviews and Assessments
Each employee should receive a written assessment at least yearly. Usually, these assessments are tied to pay raises, stock grants, and promotions. The job descriptions should be the basis for the reviews so that all employees are confident that they are being assessed against the same baseline as their peers. Unless performance is unsatisfactory, reviews should focus on positive gains as well as areas for growth. The reviews should be given to the employee verbally as well as in written form, and each person should have the chance to respond to their own review. Self-reviews can be extremely useful as well – people are usually much harder on themselves than managers will be, and the self-review is an excellent vehicle for discussion. The bottom line, though, is that nothing in a review should be a surprise. As noted earlier, regular communication is key.
Any serious performance problems should be addressed when they occur and should be documented in writing (email is fine) after discussion with the employee. Serious performance problems should be followed up on at least weekly until they are resolved, or further action needs to be taken. A performance plan policy will help ensure that this happens in a consistent manner. Delaying discussions with the employee will cause morale problems both for the employee with the performance problem and with the employee’s peers; it is very important to deal with the problems as quickly as possible.
Rewards and Recognition
Rewards and recognition are an important part of employee morale. Here again, everyone is different in their needs and preferences for rewards and recognition. Some people thoroughly enjoy being recognized in a group setting, in front of their peers. For others this type of recognition is excruciatingly embarrassing. Be sure to understand each person’s preference before recognizing them in public. For others stock and monetary rewards are motivating factors rather than recognition before their peers. In any case, look for reasons to reward employees. Everyone thinks of public praise and monetary awards when considering recognition; however, there is a host of other ways to reward good work. The accomplishment doesn’t need to be huge to gain a pat on the back. Think about parking places, spa trips, coffee house gift certificates, and other small rewards for accomplishments. For engineers, a reward involving toys is often worth far more than the cost of the toy (either electronic gadgetry or actual toys). Sometimes an unexpected afternoon off is worth more than any amount of money. Be creative, and match the rewards to the person and to the effort involved.
- Details
- Written by: Kim
- Category: IvyBay Papers and Publications
- Hits: 5979
What
All companies must use some variety of process to run their businesses. In early-stage start-ups, processes are usually lightweight and are often ad-hoc – which means that, while flexible, they are not repeatable. For a business to run efficiently, processes should be at least minimally defined. A balance is needed between the flexibility required to maneuver and the predictability required to produce a product on schedule, at cost, and at the right level of quality.
Why
Poor or incorrect process definition will eventually sacrifice quality, flexibility, growth, and employee morale. To operate efficiently, a software development organization must identify the key processes and institute these processes at the right level, providing enough definition without too much weight or rigidity and ensuring that the processes can grow and develop with the business.
Lack of Consideration and Definition
Key processes must first be identified. If the identified processes are not clearly defined they are not repeatable. (Clear definition does not mean rigidity or complexity, just a clear understanding of the steps and boundaries.) Even if a given process appears to work and to be well-understood in very early stages of the company, new people and continued growth will quickly dilute this understanding to the point that no one really knows exactly how the process should work. If key processes are not defined and broadly understood, at some point these processes will probably require retooling – an expensive proposition during rapid and/or sustained growth.
Process Too Flexible or Lightweight
If a process is too loosely defined it will be open to interpretation by each person involved. The key is to provide structure at the points where this type of interpretation will cause errors and confusion, while allowing more flexibility in the areas that will enable the company to maneuver easily as conditions change. Solid definition at critical points in the key processes will ensure a common understanding, traceable actions, and the predictability needed to produce a quality product on schedule. Such definition will also make it easy to grow and change the process as the company changes – the key areas will already be understood, and the less critical areas can be further defined as necessary.
Process Too Structured or Heavyweight
If key processes are defined in too much detail too early in the company’s history, the company will find course changes and corrections very difficult. Teams will get bogged down in unnecessary detail, and the most creative members of the team – those especially critical to start-ups – will become frustrated quickly. Additionally, extremely detailed processes can be very difficult to change as the company changes.
It is important to note that some processes must have structured definition. Processes ensuring quality for some types of software (financial or health, for example) must be very well-defined, understood, and followed in order to ensure a very low rate of errors in the field and/or to ensure compliance in certain industries. These same processes would require considerably more flexibility for other types of software, especially those with quick release cycles and adoption rates.
How
- Articulate the corporate culture – processes must conform to and support the culture. For example, if many engineers work offsite regularly, requiring in-person walkthroughs of all code would make either the culture of offsite work or the process of walkthroughs difficult to maintain.
- Define the product lines and other corporate drivers for the foreseeable future.
- Determine the key business processes. For software development companies, these typically include the development methodology (waterfall, spiral, agile, XP, etc.), configuration management, architecture and design, code, build, review and unit test, quality engineering/quality assurance/quality control, release, and maintenance.
- For each key process:
- Gauge the level of structure required based on the corporate culture, product lines, and other corporate drivers.
- Define the basic process flow – the basic, generic steps required to complete the process.
- Determine the critical points of the process flow. These are the activities that must be performed in the same way consistently by everyone involved in the process.
- Clearly define the required actions for each critical step in the process, preferably working with a team consisting of representatives from each group involved in the process.
- Working with the same team, define the required outcomes of each non-critical step in the process. This allows flexibility in methodology while ensuring that the goals of the process and its components are well-understood by the team.
- Chart a growth path for the process based on the projected evolution of the company. At a minimum, determine checkpoints for re-examining the process to determine whether adjustments are needed.
- Document each key process in an easily accessible format and location.
- Don’t over-document, or the documentation will be out of date almost as soon as it is written
- Depend heavily on pictures – charts are available in many different tools. Add text where it is critical for understanding, but do this with the knowledge that most engineers will probably not read the text, especially under schedule constraints. Start-ups are volatile environments; any process documentation requiring substantial time to read and understand will largely be ignored. Provide clear, step-by-step instructions wherever possible.
- The best place to post process documentation is on the company intranet. Everyone can access the intranet easily even over VPN, and it’s an easy medium to update.
- Consider use of a Wiki for people to post hints on how they’ve implemented the more flexible process areas in different situations. This often evolves to the next stage of the process through common use, with very little upheaval.
- Review each key process regularly, updating as necessary. Because the environment is changing, the key processes will require regular adjustment. A good time for process review is immediately after a product release, especially during the project post-mortem. With a cross-functional team, note what worked well with each process and what requires adjustment, then determine the appropriate adjustments. Be sure to update the documentation with the changes, and communicate the changes broadly across the company.