We just want to hire someone who can hit the ground running.

— Hiring Manager

It’s not going to happen. Ok, that’s hyperbolic, it will almost never happen. The conditions for a new knowledge worker “hitting the ground running” are exceedingly rare.

Joining a new company is a bit like an organ transplant, for both the new hire as well as the organization. And like an organ transplant, there are significant risks and adjustments that need to take place to avoid rejection. The impact is asymmetric and falls more on the new hire. The larger the organization, the larger the asymmetry becomes. A new hire in a 5 person organization has much more ability to help or hurt than a new hire in a 500 person organization.

Here are a few factors to consider.

• New organizations are distracting on a personal level.
  • Which healthcare plan should I choose?
  • Which 401K option do I invest in? Do I invest?
  • How will my commute be different?
  • Will anyone eat lunch with me? (Seriously, people think about this especially after leaving an environment where they are well established.)
  • Imposter syndrome as folks unfairly compare themselves to their established peers.
• New tech stacks require time to learn. Ruby to Python isn’t a huge leap but an engineer with deep muscle memory in one will need to retrain all their instincts and knowledge. Some modeling between the two helps speed things up. Regardless, languages have their nuances that become important to understand and help a developer to be effective. For example, a new Python developer may eventually find understanding the different outcomes here helpful:

  >>> foo = 1
  >>> 1 is foo
  True
  >>> bar = 10000000
  >>> bar is 10000000
  False
  

• Even if the tech stack is the same, the code base is foreign. First, there’s learning how the code base is structured and why. Then there’s making changes and building confidence that you’re doing things right. The more established the code base, the greater the chance of there being deep-seated pitfalls that may not be immediately obvious to an engineer.
• Domain knowledge is yet another dimension of knowledge to rebuild. We pay engineers (and product managers and designers) to build tools that people want to use. If they don’t understand why a user is doing something, even at a high level, then it’s difficult to be truly effective and build great things. Switching from security to genomics is a gigantic leap and potentially one of the least translatable facets of a new hire depending on their background.

Ultimately, we’re paying engineers for the internalization of the lessons that they have learned in their past experiences. For folks like Site Reliability Engineers, we refer to this as the “wisdom of production” or “scar tissue”.

All this to say, people don’t “hit the ground running” 99.9% of the time. The primary exception to this that I can think of is a re-hire, someone who left their current company for a tour of duty at another organization and returned. They’ll still have catch up to do as they say “What did I miss?”

Let’s stop talking about “hitting the ground running”. Maybe we say an experienced candidate who has translatable domain expertise in a similar tech stack “has some assembly required”.