How did you get into the bottleneck?
A growing startup commonly underinvests in its onboarding process. The
need to scale up headcount rapidly can come about unexpectedly. An event
can trigger the team scaling – perhaps the product took off with
customers, or the startup acquired a company or pivoted in a new product
direction. Quickly, plans change to how many people the startup now needs
to achieve their new goals, the recruiting team starts interviewing and
making offers. With added pressure, you don’t take time to optimize the
onboarding process. If an effective onboarding system wasn’t already in place, the
new employees are dropped into teams, assigned some tasks, and left to
figure out how to become productive for themselves. It’s particularly
problematic if team members aren’t collaboratively helping the new
employee get up to speed, there’s no onboarding documentation, the code
is impossible to read, or the product goals and KPIs unclear. Then new
employees can become lost, dissatisfied and underproductive. In this
article we will explore signs that your company is bottlenecked by an
ineffective onboarding process, and the best practice solutions we have
seen work at Thoughtworks Scaleup Studio.
In addition to onboarding new hires, the process is utilized when
reorganizing teams. The studio believe the ability to learn, fail fast and
refocus is a important skill for successful scaling. A nimble startup will
pivot as it responds to learnings and landscape changes, this involves
changing product team goals and reassigning resources to best target the
new goals. To do this easily, we need the ability for the reassigned team
members to get up to speed quickly. Most of the capabilities in this
article, will also apply to reorganizing.
Onboarding is a key business process
Onboarding is often seen as merely granting access and doing a set of
administrative tasks before handing new employees to their manager and
team. It’s not thought of as an end-to-end business process. But a
well-run onboarding process addresses social and cultural integration
and facilitates collaboration among the different functions that a new
employee has to interact with. The onboarding process typically involves
human resources, engineering management, legal, IT Operation, security,
and product team members. Spanning so many groups means it can be very
disjointed. Optimizing the process is difficult because often no one
owns the whole process, and you must bring all the different players
together.
Software leaders put a lot of effort into shaping hiring plans and
supporting recruiting efforts, but often neglect to give much thought to
how new employees will become effective. We believe this to be a
mistake, as effective onboarding acts as a “multiplier effect” for new
hires.
From a clinical perspective, what is the value of a new employee?
Without proper onboarding, new hires will only exhibit a fraction of
their value and productivity, some as low as 50%. With an ROI at this
level, you are less likely to achieve your intended goals. Leaders are
forced to do additional hiring, which will increase organization
complexity and workload for managers. To avoid this, we recommend
putting the same amount of effort into optimizing onboarding as you
would hiring new employees.
In our opinion the onboarding process doesn’t end after a week or a
month – it keeps going until the person is fully productive. As soon as
someone accepts an offer, the onboarding process begins, followed by a
robust new hire orientation, receiving of laptops and access to
appropriate systems. It continues after they join their team, as they
carry out their duties for the first time, build relationships with
their team members and managers, and develop habits around their common
tasks. The last phase of onboarding enables an employee to reach full
productivity, where they can contribute to the team creatively, teach
others and contribute back into the onboarding process. This timeline is
dependent on role, domain and complexity.
Optimal onboarding timeline
To gauge how you are doing, this table represents what we observe to
be optimal timelines for a developer onboarding. We will explain the
concepts mentioned here further in the rest of the article:
| Milestone | Completed By |
|---|---|
| Access to all HR and administrative systems | Day one |
| Access to workstation and personal development environment is setup with necessary tools |
Day one |
| Company mission and business goals are explained and discussed |
Day two |
| Complete a push to production for a trivial change, assisted by peer |
Day three |
| Manager has set expectations with employee and given them an OKR |
Week one |
| Paired with colleague on developing a real feature all the way to production and performed defect resolution |
Week two |
| Understood key customer problems and internal operation processes |
Week two |
| Developer: Able to be an “Anchor” on a story | Week 3 – 5† |
| Developer: Able to lead support calls | Week 5 – 7† |
† depending on complexity and experience
Signs you are approaching a scaling bottleneck
New people cannot access tools and systems
Most new joinees usually come with a sense of excitement and
anticipation about their new assignment, eager to prove themselves in
their new environment. Having to wait for access to basic resources like
the work laptop, source control, team documentation portals, test
environments, software licenses, etc. can dampen the spirits of even the
most enthusiastic candidates. Not knowing which systems to get access to
and having to chase specific individuals to find out how can be very
frustrating.
To spot these delays you can monitor the steps new employees are
taking. Keep an eye on the number of tickets opened and the amount of
time it takes to resolve these tickets.
New developers cannot make a production deployment
A quantifiable metric to use is how long it takes a new employee
to write code, commit and deploy all the way to production. This
should happen in the first week– ideally the first couple of days. It
doesn’t have to be a complex task, it can be something very trivial.
This metric is an indicator that the developer has their computer and
development environment set up correctly and has everything they need to
push to production independently. We find situations where a new
developer has been in the company weeks or even months, and has not
deployed anything to production.
Newcomers feel orphaned
Especially at startups, most managers are laser-focused on new
initiatives, and they have more work than they can handle. It’s easy
to deprioritize integrating and bringing direct reports up to speed. New
employees are left to figure out things on their own; learning systems,
forming relationships, and how to get access to resources they need.
Worse if they haven’t been given a clear goal, they may end up working
on the wrong thing. The employee becomes an orphan, resulting in much
lower productivity or quick attrition. Cultural problems like this are
hard to spot. We recommend listening to your managers and feedback from
new employees. Exit interviews are also valuable data.
Too much focus on individual work
When a startup scales by adding new employees, this can trigger a
different mode of operation. It was a small team that built the initial
product and technology platform. Each engineer was focused on building
and supporting a part of the application, likely by themselves. With the
expansion into a larger team, a problem we often observe is the tenured
employees aren’t dedicating enough time to onboarding the new employees
– collaborating and pairing with new engineers, documenting how they
work and explaining the reasons for technical decisions, etc. This makes
onboarding very difficult.
With the expanded team size, objectives should not only focus on
individual contributions, but should include how the product team as a whole is
performing. When retrospecting the product team should ideally look for
opportunities to help new hires become more productive. An anti-pattern
we see is planning with individuals allocated to streams of work by
themselves, as this removes the opportunity to transfer knowledge.
Not enough openness to change
When you hire new employees, they likely come with different
experiences than the existing team (especially if you are hiring outside
of your personal network). They’ll have different opinions and
viewpoints. Too often we see companies not taking advantage of this. A
typical situation is that the startup likely has a team of “old hands”
that have found a way to work, have their own idiosyncrasies, and there
is a history to every decision. The team is dogmatic in its approaches
and shoots down the new ideas of the newcomer. This leaves the new hire
feeling unempowered, and not appreciated.
Again this is cultural and hard to spot, but some anti-patterns to
look out for are:
- Current employees hogging the meeting, talking quickly, or not
giving enough time for new employees to contribute or clarify. - Being overly protective of the status quo; shooting down ideas –
“we tried that”, “it could never work here…”. - Back-channeling through unofficial channels; tenured employees
might get work done through their established network doing them a
“favor”, rather than through a documented process.
Seemingly simple things take too long
The effectiveness of your development environment for common tasks
will be exposed when onboarding new employees. The friction may have
already been felt by existing employees, but adding more magnifies the
problem. Each new employee will have to learn how to solve common
problems and discover workarounds. Examples might be flaky automated
tests, inaccurate documentation, slow personal dev environment,
environments that are out of date, or a slow dogmatic code review
process. We can monitor some of these things by tracking low level
metrics (e.g. CI build time, PR review time, unit test run time) and
tech debt items that teams are highlighting as friction.
Fast turnover
Turnover rate of newcomers is a lagging indicator. There might be
many reasons for a high turnover rate. However it’s worth
investigating. It could be related to your onboarding process. It could
be that your new employees aren’t being properly trained, and welcomed
in the company. Your team should monitor the rate and how it’s
trending, supplement with surveys after 6 months and a year for new
employees. You can then use the learnings to improve the onboarding
process continually.
Documentation can’t answer questions from new hires
New hires, especially lateral hires, usually know what needs to be
done at a high level. However, idiosyncrasies of the new environment can
get in the way of completing even mundane tasks. For example, not
knowing the location of the source repositories or the base URL to the
integration test environment. Well-structured onboarding documentation
can help boost productivity, build confidence and generally provide a
pleasant working experience. To continuously improve and keep the
documentation up to date, new hires should be encouraged to find bugs in
it and fix them.
