Onboarding and the Cost of Team Debt

When the new Senior VP of Engineering took over at a major Silicon Valley tech company a few years back, the first thing he had to do was freeze hiring. The company had been growing rapidly and their engineering team had hired aggressively, but they had reached a point where each new engineer they added to the team decreased overall productivity. The issue was not their hiring process. Problems began when the (very qualified) engineers arrived and were haphazardly onboarded. Without clear training on organizational processes or integration into the team, new employees were unprepared and ineffective. As a result, the company had to stop expanding and put in place processes so that hiring new employees served its purpose of increasing productivity. It took them several months to design an onboarding program that effectively brought engineers up to speed, and the added expense of solving this retroactively was huge.

We talk a lot in engineering about technical debt, but few people talk about what I call "team debt". Technical debt refers to the "eventual consequences of poor system design" [1]. The idea is that when a feature is built it requires a certain amount of work to be thoroughly completed, and, if it is shipped before all the work is finished, anything leftover accrues as debt. If left unaddressed, a team's technical debt can reach a point where forward production must be halted in order to fix the technical issues and overall system design.

Team debt is similar. It's the idea that when employees aren't properly trained, integrated, or managed, they are operating at less than optimal efficiency and "team debt" is accrued. Each new employee that is added without being sufficiently trained and integrated increases that debt. If unchecked, team debt can reach a point where expansion must be halted in order to address the deficiencies of the existing system, similar to what happened in the above story about the growing tech company that had to freeze hiring. An important part of reducing "team debt" at a company is structured onboarding and training for new employees.

At a very high-level, onboarding is the process of taking someone from outside the company and making them an independent, productive, and confident member of the team. Onboarding involves training new employees on the technologies, organizational processes, and team dynamics they need to know to complete their job. Good onboarding will help new employees get up to speed in these areas quickly and efficiently. Onboarding is finished when the nebulous idea of "reliable independence" is achieved, where an employee requires no more resources from coworkers and managers than the average work collaboration. This concept is intentionally vague and meant to be interpreted by each team and adapted to their own needs.

So how does onboarding reduce team debt? A coach once told me that every time someone joins a team, the team fundamentally changes and becomes a new version of itself. Re-iterating processes and values when a new person joins won't just benefit the new hire; it will also benefit existing team members. It will serve to get everyone on the same page, and act as an opportunity to re-evaluate how work is done and re-align the team's goals. Training new employees reduces team debt by integrating the new employee and re-aligning the existing employees.

Teamwork is extremely valuable in engineering (and pretty much anything that involves groups of people). Many of the biggest products in tech were originally developed by teams of less than 10. Small numbers of people can do big things, especially if they work together [2]. I used to tell the water polo teams I coached that their ability to win was the sum of their talent multiplied by how well they work together as a team. If they worked really well together, then they could beat teams that were considered more "talented". When I started working as a software engineer, I found the same thing to be true of an engineering team's productivity. In other words:

Productivity = Σ of talent * teamwork

At its best, onboarding helps increase the teamwork multiple so that it's greater than one. However, when onboarding is neglected and new employees aren't aligned with the team's goals and values, the teamwork factor can drop below one. Paying back team debt involves improving company processes so that the teamwork factor is at least one, and adding new employees maintains or increases the productivity of the team.

Team debt can hurt more than just productivity at companies. Employees who are not fully integrated with their team can feel unproductive and dissatisfied. This can compound, and unhappy employees are easier to steal away from the company. Losing an employee is very expensive. Depending on the skill level, it can range from tens of thousands of dollars to 1.5 - 2 times their annual salary. For a very highly skilled employee, replacing them can cost up to 4 times their annual salary [3]. That's terrifying.

Hiring employees in the first place is also expensive. Recruiting fees for engineers are usually about 20-25% of the person's salary for the first year. That's on top of the less quantifiable cost of interviewing and evaluating all the candidates [4]. Onboarding is critical for maximizing the value of new employees and increasing employee satisfaction. In short, a good onboarding program can save you huge amounts of money in the long run by increasing employee efficiency and retention.

So what happens at companies that don't have structured onboarding? When a company has no structured onboarding, it is replaced by haphazard, ad-hoc, social onboarding. New employees have to rely on existing social structures to learn about their job, their role, their teammates, and the company—as if by osmosis. If, as a new hire, you have a lot in common with the existing team, from preferred communication methods to hobbies and interests, this will be easier. If you don't, no matter how quality of an engineer you are, you might experience friction or difficulty getting integrated with your new team.

A lack of onboarding is bad for pretty much all new employees, but it’s worse for people who are different from the existing group. A parent joining a team of all young people might have trouble attending after-hours social events because they have more responsibilities at home. An introvert joining a team of extroverts could feel uncomfortable with the communication style and have a difficult time expressing themselves. A woman joining a team of all men might have different hobbies and, therefore, less in common with the existing team. Without explicit onboarding, new employees have to disproportionately rely on existing social structures to learn about their job.

Engineering teams and tech companies are currently almost entirely male and almost entirely white. While a white man joining a team that is either non-white or non-male might experience similar issues assimilating, the reality is that currently women, racial minorities, transgender people, and even parents are the groups struggling more to integrate in the current tech culture. By not investing in onboarding, companies are tacitly perpetuating an environment that is systematically better for people from the existing group. Explicit onboarding should remove reliance on social norms for training new employees, and systematize job training so that people who are different from the existing team have a fair shot at being socially connected and successful at their job.

Onboarding has a high return on investment; the more effort you put in, the better the results. While there's no definitive research on the effects of onboarding, largely because there are so many factors, companies that have done longitudinal studies of their onboarding programs have seen positive results. First Horizon National saw an increase in efficiency and consistency, and their turnover rate went from 19.5% to 10.96% between 2008-2009 when they put their program in place [5]. Here's a brief overview of some of the things you can think about doing when creating an onboarding program. I will leave a more in-depth plan for a later blog post, otherwise we'll be here all day.

First, distribute the load of onboarding. The idea that the only people capable of mentoring are senior members of the team is false. Often, the best person to teach someone is the last person who did it. This is because the farther away you get from material you've learned, the more it becomes intuitive and the harder it is to teach. A brilliant physics professor on the cutting edge of research in his field has a hard time explaining introductory physics concepts because they have become so ingrained in his understanding that they are intuitive. In fact, the pathways in expert versus novice brains are actually different [6]. Distributing the load also has the added benefit of preventing mentor burnout by not putting the burden of onboarding on the same few senior team members over and over again.

Second, to streamline onboarding focus on the following three categories: technical skills, knowledge of company processes, and personal development. Each category is about 1/3 of getting someone fully integrated and up to speed.

Technical Skills

Technical skills include things like knowing a programming language and understanding tools the company uses for development. This category is pretty straightforward and there are a lot of online tutorials and documentation that can help people learn new languages, APIs and tools. While this category is heavily emphasized during the interview process, it's only a fraction of what someone needs to know to be a productive member of their engineering team.

Knowledge of Company Processes

Understanding organizational processes is more difficult for new employees to learn. This is because organizational​ processes are unique to each company and often poorly documented. It includes things like the values of the company, the explicit and implicit management hierarchy, and how to get your job done day to day within that system. The biggest thing a company can do for a new engineer in this category is to outline the life-cycle of shipping a feature. How do features get selected for development? How do you develop and test day-to-day? How do you open pull requests and solicit feedback? How do you merge and deploy? And how do you troubleshoot and bug fix once that feature is live?

Personal Development

Personal development is often the most neglected category in onboarding and engineering management. It involves the development and personal trajectory of the engineer. What roles are they aiming for in the future? How is their confidence? How do they feel about their connection with teammates? Helping employees learn new things and achieve their goals is just as important as paying them a good salary, and definitely more important than snacks or a ping-pong table. People often mistakenly think that confidence follows the acquisition of skills when it's often the other way around; skills follow confidence. You can bolster confidence by giving people constructive feedback on their work, helping them to achieve short-term goals, and checking in regularly to make sure they feel productive and satisfied with their job.

I'll end with some fun ideas of things you can do to improve onboarding for new employees. First, find ways to get different people to work together and learn from each other. You can have people shadow others for a day a week, pair program with different team members, or do an apprenticeship on a project with a more senior coworker.

Make sure that you have appropriate feedback channels for new employees, like weekly one-on-ones or code labs where people can ask any questions about the company or the technologies you use. Understanding where people are at and what they need more information on is an important part of making sure they get fully up to speed as quickly as possible.

Find ways to help people connect with their team and the larger community outside the company. You can have brown-bag sessions where engineers present on technical topics at the company. Encourage employees to attend local meetups and conferences so they can learn about new topics and meet people in the same field who don't work at the company. Encourage people to mentor and present at community events, as well. Speaking and teaching are great ways to solidify skills and understanding, and feel a sense of pride in your work. Finally, my favorite fun idea—have a "Harrowing Adventures of the Week" session where people tell stories about their most harrowing computer misadventures and crises. These kinds of stories can help people connect over the trials and tribulations we face in our day to day work.

Onboarding is critical for the productivity and growth of engineering teams. While onboarding is important for all individuals, a lack of onboarding disproportionately hurts those who are different from the existing team. Onboarding doesn't have to be a cumbersome process filled with boring seminars and paperwork; onboarding can be creative, fun, and flexible. Putting in the effort to create structured onboarding will pay off hugely, and is way more efficient than flying by the seat of your pants with each new employee. Onboarding will help integrate new employees, making them as successful as possible, which will improve employee retention, satisfaction, and diversity.

This post is based on a talk I've given several times. The original talk was co-written and presented with Nicole Zuckerman at PyCon 2014.

• Wikipedia. Technical Debt.
• Armel, Kate. Top Performing Projects Use Small Teams. QSM, 2012.
• Borysenko, Karlyn. The Cost of Employee Turnover. LinkedIn, 2014.
• Mickiewicz, Matt. What is the average cost of recruiting an engineer in Silicon Valley?. Quora, 2013.
• Schooley, Claire. Case Study: First Horizon National’s 90-Day Onboarding Program Benefits The Company. 2010.
• Wieman, Carl. The “Curse of Knowledge,” or Why Intuition About Teaching Often Fails. APS, 2007.

• How Our Engineering Environments are Killing Diversity: Introduction
• Argument Cultures and Unregulated Aggression
• Criticism and Ineffective Feedback
• (this post) Onboarding and the Cost of Team Debt
• Social Norms and Gendered Expectations