Nick Nichols

Clojure Developer and Dungeon Master

All Aboard

So, you finally got that new developer you’ve been looking for! This is fantastic! You’ll be able to chip away at your backlog (which has been growing out of control lately), get a flood of new ideas, and bring your product forward by leaps and bounds!

Well, maybe not right away. After all, they haven’t gotten a hang of the ropes yet. Your new developer needs to meet their team, learn about your business, watch those pesky compliance training videos, and figure out how the coffee pot works. That’s a breeze, and they should be up and running by the end of the week. Or should it be a month? Longer?

In truth, there is no universal measure for how long your new employees will spend training; however, most of that “dead” time, which I mean as “time not spent coding,” tends to show up as a dip in that individual’s productive time. It makes sense, and is good to adjust for. That being said, you also need to drop the velocity/WIP limit/etc. for your entire team.

Wait, what?

You heard me right, your team, as a whole unit, will probably suffer a 10-20% drop in efficiency when a new team member joins. This drop can last anywhere from 2-7 weeks or 2-7 months, even though the long-term velocity will trend up. Assuming the burden of on-boarding falls squarely on your HR department, the hiring manager, or a mentor is a very common fallacy. The impacts are far more distributed than you may realize.

The Organization

Employee acquisition costs real dollars, about 4,000 of them, give or take. This is the cost to even start talking about the money you’re paying them as an employee. Before they’ve even walked through the doors for the interview you’ve spent a sizable amount of money on recruiting and attracting applicants.

Why do I bring this up? To underscore the concept of a front-end load investment. I’ll be bringing up further, often unseen costs in a second, which, like all other financial investments, is something you need to plan on before pulling the trigger on your decision. You can’t onboard 1, 2, or 40 new developers and expect your productivity to explode out of the gate. If you think you can hire or contract out multiple employees or entire teams to make a deadline, you’re lying to yourself. If you’re hiring to meet long-term goals and trends, you’re in the right place.

Once your employees walk through the door, you’ll continue to have costs. Here are a few quick examples that, while mostly focused on developers, span most functions and job duties:

  1. Industry Education - What does your company do? How does it accomplish that? What data matters?
  2. Mandated Training - HIPAA, RESPA, or anything else the government generally requires of your industry
  3. Team Training - How do we contribute to the company? What software/platforms/etc do we use? How are responsibilities shared?
  4. Individual Training - What frameworks/tools do I need to learn? What skills do I need to sharpen? What habits do I need to break?
  5. Day-to-Day Adjustments - Where do I get coffee? Who runs the retirement plan? How often do I meet with my boss?

All of these involve people spending time explaining things. Sure, you can (and should) write a lot of this down, but manual documentation is only as good as the people writing and updating it. It’s one of the first things to fall by the wayside, and one-on-one explanations and walkthroughs are a great way to start relationships. Either way, you’re spending the time of multiple people, which you are paying for. This is a good and healthy investment. Throwing a new employee in the corner with a pile of documentation is a quick way to build resentment, and that’s it. If your organization is willing to commit to hiring a new employee, you must also be ready to commit to making them a good employee.

The Team

The team will also need a significant amount of time to adjust and rebound their velocity. If the team carries on with their work at the same pace as before, there’s a neglected newbie. There are a finite number of hours in the work day, and time spent building a new relationship, explaining team and business objectives, and anything referred to as “showing them the ropes” bites into that time. Productivity will drop. This is a fact of life, and it’s okay. The important thing is to realistically commit to work and plan ahead with this knowledge.

If you track story points, allocate some to training at the team level. If you track WIP, throw an extra card or two up. If you track by stand-ups or share-outs, bring up the commitments you’re making to your new hires. Make sure it isn’t negatively framed either. Yes, spending time on training is as important as user stories. No, you shouldn’t feel bad about deliberately taking time and steps towards feeling comfortable and productive. Rushing this process will result in team-wide stress and mistakes- things nobody wants.

Once you’ve gotten over the first hump, your new teammate will start taking on work, and your velocity will still be out-of-whack. Your historic baseline was based on your team’s familiarity, skill, and size. Each of these variables just changed. Your team is larger, and the relative difficulty of each story has just jumped. Why? Because you’re still in ramp-up mode. You’ll find that stories take longer because developers are pairing on assignments, there will be some level-setting for handling work expectations, and there will be plenty of individual research to be done. Again, this consumes time in the short term. Eventually, your velocity will re-normalize, but not for a long time. This is vital work, and a vital investment, and is probably happening under the radar.

The Individual

I’ve said this before, but it bears repeating, Human Resources should focus on humans, not plug-and-play resources. If the human element didn’t matter, you would have automated this job. This is a period of massive adjustment in an individual’s life. Beyond the time spent training, or learning a new job, or shaking new hands, there is a lot happening behind-the-scenes. Even if they don’t mention it, there are major life factors that can carry on for a couple of months. The extra stress and distractions will cut into their time, energy, and focus. Allowances need to be made for the transition.

Just by changing jobs, they may be running into some of the following problems:

  1. They have to roll their retirement accounts over
  2. They have to figure out which doctors, dentists, optometrists, etc. are in their new benefits package
  3. They need to figure out a new commute, daily schedule, lunch group, etc.
  4. They need to follow-up on hiring documentation
  5. They have to learn a new framework, language, tool, etc.

If there’s a relocation, this can telescope out into bigger and longer questions:

  1. What am I going to do with my old house?
  2. Which schools should my kids go to?
  3. When am I going to find new friends, new restaurants, etc?
  4. Where is the closest DMV that isn’t always busy?

In either case, there’s a very large stressor underlining all of these decisions and questions:

  1. Having to internalize and adapt to all of this, and feeling pressure to do it as quickly as possible

Even if you perfect your on-boarding process, there will be some underlying stress and an adjustment phase. It’s all part of the investment you’ve made. Recognize that the organization, the team, and the individual need time to adjust and adapt. Even if it’s not a metric that shows up on your biggest and brightest dashboard, it’s a vital part of your organization’s health.