Problem in a nutshell: New employees aren’t immediately trained to do their work in your context independently. It takes time for them to ramp up towards independence. Until independence, they absorb other team members time and cause negative impact to team performance overall. Estimating when new team members will be a net positive on project delivery performance is an important part of planning team size and how fast progress will proceed after they acquire the necessary knowledge.

I often find that teams and organizations don’t understand how fast new hires will be absorbed into a team. Without a sense of time to productive, its hard to predict how team size relates to estimated delivery impact.

The only certainties in new hires are –

  1. Its unlikely (unless its really simple and common work) that new hires hit the ground immediately net positive impact to the team
  2. Its likely that during ramp up, the senior teacher level members of the team will be adversely impacted
  3. Its likely that the time to ramp up a new hire will be different for each skillset required

This post explains how to estimate and research the questions surrounding staff skill risk and on-boarding effort.

Skill Capability Surveys and Team Planning

The general process to determine risk and readiness for a team to deliver is –

  1. Capture a list of specific skills a team needs to perform
  2. Survey the current staff to determine what skill levels (see next section) they are for each skill
  3. Solve immediate risks where there are zero or just one person who can do a skill. Train or hire urgently.
  4. Balance the demand and supply of people who can do that skill
  5. Plan how teams can be split and grown into more teams to increase growth

Its important to know what skills are needed for a team or organization. A skill is any particular knowledge (or access) people need  to do their jobs. Coding is one skill, but this might have some particular sub-skills, Java, Angular.js, CSS for example. If people need a different set of tools and knowledge, this is a specific skill. Its also important to know how many people can mentor and teach others, and for this we need to look at the skill level of our current staff.

Staff Skill Levels – Not how good they are, how well they teach others!

I stay away from how good someone is at a particular job from a performance perspective. I want to know how good they are at teaching others. Some people seem concerned with productivity, and look for coders who are 10x productivity of others, but i’ve not seen this significant from a team throughput perspective. Even if one part of a development and delivery process gets done 10x “faster” its unlikely to yield a significant impact on total system throughput, as work hits a constraint and sits idle (rushing into a waiting room). Forecasting involves taking a wider systems view and looking for gaps in skillsets that will become system constraints. Its more important from a forecasting perspective to look for gaps and constraints rather than “excellence,” the constraints are where improvement opportunities are a plenty and its exponentially powerful (rather than 10x being linear improvement).

I capture three levels of skill ability that help plan teams and see risks. Capture how many people you have for every required skill –

  1. I can teach others (Teachers)
  2. I can do independently, and know when to ask questions (Do’ers)
  3. I’ve got the ability to do the work if taught (Learners)

Thinking of teams in this way helps ensure that you aren’t constrained by people who can do the work independently (Do’ers) or that you have an absence of people who can mentor, teach and help team members when that skill is used (Teachers). New hires enter the team at level 3, Learners. We need to understand that we have a teacher available to bring them up to Do’er level, and we need to make sure we never have just a single Do’er to avoid a single point of failure, bringing the system to no flow if that person leaves, goes on vacation, or is busy doing other work.

Time to Productive & Maximum Teach Load

Each skillset wanted in a new hire will take time to develop. Someone will be needed to mentor and teach the new employee on how to do that skill (or more commonly, how that skill is done “here”). During this training time, expect the teacher level employee to decline in productivity. This is a careful trade, and the subject of writing in the legendary “Mythical Man Month,” where Fred Brooks explains clearly why adding people late to a late project makes it later. Absorbing the current teams time to get new members up to an independent level takes effort.

What I do is keep two estimates up to date for each skillset hire for –

  1. Time to Productive: How long from hire to independent ability to work mostly alone. This isn’t time to replace the teacher level members, its time to know when to ask a question!
  2. Maximum Teach Load: How many new team members can be on-boarded at the same time. Going above this impacts the time to productive adversely. Most often this number is one. When growing a team, it is often faster to stagger the hiring so that the teachers are saturated. Ideally, teaching should take < 50% of their time.

I use these estimates when forecasting. I don’t assume any benefit from new team hires until “Date Hired + Time to Productive” and I might even degrade a teams throughput estimates or historical performance during these on-boarding periods if > Maximum Teach Load is exceeded. I try and get the teams to slow down hiring first though – ramp up hiring, not one shot. I sometime even loan the new hire to another team and get them to teach the new team member if its got available teacher level staff. This can accelerate the hiring plan.

Capability Matrix Tool

Capability Matrix: I want to analyze skillset risk of a team

Our capability matrix spreadsheet helps analyze and survey what skills are on hand, and how many independent level and teachers are available. Its a totally configurable survey form that lets current team members self assess their level of expertise on each skillset, and also documents who is willing to “also” learn another skill to a higher level of expertise. Its NOT the goal to have everyone at a “Teacher” level – its the goal to know that you have gaps in skillset coverage, and plan your options to solve these gaps.

The capability matrix works for me a multi-team organization level where i’m looking at what team does what. I first confirm that we don’t have a team constraint, where there is just one team who will do all one type of work, or no team doing one type of required skill/work. One i stabilize this, i move onto the team level skillsets and formulate a stabilization plan. This plan is what skills we need to develop internally or hire, and more importantly, a timeline that allows the organization and teams to absorb this ramp-up. Too fast and we depress delivery capability too deeply, too slow, and we suffer high risk of failure (to few people who can do one type of job or skill). Its a balancing act.

Get the spreadsheet here: Capability Matrix: I want to analyze skillset risk of a team

staff capability survey

Staff capability survey. Old school survey thats quick to capture the necessary details.

Staff capability analysis

The main capability survey data is captured in this worksheet. For each team member or external team, a level of current expertise is captured.

Staff capability guidance

A guidance worksheet shows our prioritization and tips for solving staff skillset risk.