How fast can you hire?
Five years ago, when Amazon started its hyper-growth employee count, I wonder how fast a company could hire new employees without causing more harm than good. No matter what kind of business you have, hiring too fast can hinder growth.
The risk is even more prominent in technology companies because of team members’ synergy and communication.
And that doesn’t even account for a technology company that is also a startup. Hiring too fast for a tech startup can be devastating because of the lack of synergy and communication and because a startup is still trying to define its process, tools, and culture.
The Franchise Method
Imagine you are opening a new McDonald’s franchise. You sign the deal, get a building, prepare, and thirty days before the opening, you go out to hire the entire team to run the place. You might need a store manager, several cooks, cashiers, cleaners, security personnel, etc. You might need to hire 30 or 40 people in a short period. There is a playbook. It works.
Now, imagine you are opening a new advertising agency, and you need to hire 20 people in a month to jump-start that business. Would that work? Likely not!
406 Not Acceptable
nginx
That’s not a valid comparison, you might say. One requires low-paying, low-skill workers; the other is a skilled trade.
What if, instead of opening a McDonald’s franchise, you open a Medical Urgent Care franchise (if there is such a thing). You need to hire 100 people before opening: doctors, nurses, receptionists, technicians, cleaners, managers, etc. Assuming that you can find the talent, the day this Urgent Care opens, it can start operating and delivering value because everyone knows their role and the playbook. A Creative Agency or a Tech Startup are different animals.
Here are the factors that we must consider:
- Recruiting and market demand for the talent.
- Roles, responsibilities, and boundaries.
- Processes and tools.
- Training.
- Facilities and supporting functions.
For this post, I’ll ignore all of the complexities of recruiting and onboarding new employees and focus on training only.
What it takes for a person to start adding value to the company.
Value from day one?
For a person to be fully productive on day one at any work, she must do the same work that she was doing before. She must draw from the same knowledge base. Using the same tools, processes, and methods, and producing the same output.
If you were a barista at a Starbucks down the street and became a barista at the Starbucks two blocks over, by the end of your first day, you’ll be at full speed. If instead, you move to a different coffee chain, it might take a few extra days to get used to the new machines, processes, and even the language they use to describe the coffee.
In tech, a new developer, designer, product manager, user researcher, or the many other roles of R&D must learn:
- The technologies and tools
- The processes and methods (explicit and implicit)
- The current state of the Product
- The vision, direction, backlog, and upcoming milestones
- The people you’ll be working with, their skills, responsibilities, and communication styles.
- The “kludge” (HR tools & policies, facilities, expenses reporting, IT, etc.)
A CTO of a public company told me they don’t consider new developers as productive resources in their quarterly planning for their first six months. It doesn’t mean the developer isn’t working on anything and just being trained, but they don’t believe they can count on them with any level of certainty to add to the plan.
Facebook has a six-week boot camp for new software engineers, in which the individuals learn a myriad of technologies, tools, processes, cultural values, etc.
On many tech startups, we have an unreasonable expectation of developer productivity. We expect a new front-end developer to start delivering value by the end of their first week. And, they do! However, if you look under the hood at the code they produced, how they did it, and the tools they used, you might be quite disappointed.
Often, all that work needs to be thrown out, and not only will the new developer have to do it again, but it also consumed cycles from many other people on the team to investigate and decide how to do it right this time.
It’s like the sarcastic saying: Months of coding can save you days of training (original: “Weeks of coding can save you hours of planning”)
The (not so) Hidden Cost of a New Employee
So what? Hire a new employee, wait a few weeks for them to be up-to-speed, and they are productive and delivering value to the organization. What’s the big deal?
What about the cost of a new employee has on the productivity of existing employees?
Imagine you have a tech startup with two developers: a back-end and a mobile developer. They’ve been working for a few months and making good progress. The estimate is that they could get the MVP product to the market in another three months.
On a Monday morning, five new back-end engineers and five new mobile engineers start at the company. The team goes from two to twelve.
What do you think the cost of productivity for the initial two developers will be? In practical terms, they will need to give all these new employees access to all the tools and services they use: Github, Jenkins, AWS, NewRelic, credentials and tokens, Jira, etc.
They will need to explain to the new developers the existing processes and methodologies they’ve been using. Where they keep files on Dropbox, how they use JIRA, how they use containers, architect the APIs, and the recurring meetings they have through the week (which at this point might be none).
The new developers will need to learn about the vision, the mission, and values, the milestones and goals, the backlog of work items that is probably not so well defined because until that point, with only two developers, they only needed to have clarity in the next three or four work items. That means the entire team will need to stop to work on that. They will also go from almost no need to have meetings or structured communication to realizing they need standups, sprint planning, design discussions, planning sessions, etc.
You get the gist. The first week these ten new developers join is completely gone. Probably the second week is gone too. It will take another six to eight weeks for the new developers to reach a reasonable contribution level. It’ll put the project behind schedule!
How fast is too fast
The easiest way to think about this is to assume that it’ll cost existing employees who work with the new one X% of their productivity for each new employee in the organization for the first few months of this new employee. Let’s call this the on-boarding cost rate (OCR).
OCR = (% of avg. productivity lost) X (# of existing employees involved)
A startup with two co-founders might spend 30% of the co-founders’ time onboarding a single employee in the first three months of their employment. That means if three new employees start in the same quarter, the productivity of those co-founders might drop to zero. They won’t be doing anything but helping the new employees reach full productivity.
From my experience, that rate is never lower than 10% in a team. That means a new person will cost each person in their immediate team 4h per week to help them learn the ways. This time is spent on chats, meetings, tools & processes assistance, social aspects, and even mundane questions about the building facilities or IT.
Imagine that each developer has a velocity of 20 points per quarter, and your company has five developers that have been working together for more than three months.
5 dev / quarter = 5 * 20 = 100 points
You add another developer to the team. This developer’s productivity will be minimal during the first quarter, but let’s assume it is 5 points.
New employee productivity = 5 points.
New employee onboarding cost = 5 (existing employees) * 20 (points per quarter) * 10% (loss of productivity per existing employee) = 10
The quarter’s overall team productivity dropped from 100 points to 95 points (100 original points - 10 points of onboarding cost + 5 points for the new employee), even though the team went from 5 to 6 developers!
Assume that instead of hiring one employee this quarter, the company doubles in size and hires five new employees.
5 new employees productivity = 25 points.
5 new employees on-boarding cost =
5 (existing employees)
x 20 (productivity points)
x 10% (on-boarding cost rate)
x 5 (new employees)
= 50 productivity units spent on new employees.
Now, the productivity from that quarter went from 100 points with 5 employees to 75 points with 10 employees!
But wait! It gets worse!
A team of one developer means the full day of that person can be spent coding. The 20 points per quarter of productivity actually mean 20 points per quarter delivered. When you have two or more developers on the team working on the same thing, they need to express their thoughts and communicate to coordinate and collaborate. So instead of 20 points delivered by each, they likely will have only 18 to write code, while 2 points of each are used for communication.
Add a third developer to the mix, and productivity drops even more. It’s not a linear drop (10 developers in a team won’t make the team productivity drop to zero). From my experience and data gathered on tools that track productivity, a typical developer in a team will only be productive from 50–60% of their time.
A team that goes from 2 developers (18 points average each) to 5 might get a drop in productivity per person to 15 points per quarter. And once they double again, they’ll go to 12 points of productivity per quarter.
In other words, this is your team productivity:
Previous quarter: 90 (5 developers)
Current quarter: 65 (10 developers)
Next quarter: 120 (10 developers at full speed)
Notice you *doubled* your team size, and for two full quarters, you do not realize any additional value!
But wait! There’s more! First, it’s unlikely the new developers will reach full productivity in the quarter (all things being equal). Usually, it takes 6–9 months for that to happen. Second, the cost of onboarding a new developer is rarely a flat 10%. Unless significant planning has been done in preparation for the new person, there will be a lot of hand-holding between existing and new employees for several months. Third, recruiting new developers usually consumes time from existing employees to interview candidates.
As a CTO once told me:
“We were hiring so much we didn’t have time to write software”.
All that gets compounded if the company is going from a few employees to a few dozen employees, in which the processes and tools being used start to show their inadequacies.
In Conclusion
- Consider the productivity loss to existing employees when hiring new developers.
- Consider the tools and processes as the company grows. You want to be on the edge of not having enough.
- Keep teams small to avoid the communication overhead.
- Don’t add people to a team because you want to make an existing project “launch sooner”!
- Remember that 9 women cannot have a baby in one month!
- Read “The Mythical Man-Month.”
Follow me on Twitter: @calbucci
You might also like:
