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.
How do you get out of the bottleneck?
When you are thinking about designing your onboarding process it’s a
good first step to think holistically about employee effectiveness. In
the following solutions section we will describe how to create a path
to effectiveness, an example of onboarding optimization applied at
Checkr, and then some techniques we view as important.
Create a path to effectiveness
In maximizing developer effectiveness
Tim talked about the idea of focusing on outcomes rather than outputs,
and how engaged employees can create the most value for your business
and your customer. Empowered employees aren’t simply coding a
requirement, designing to a spec, or creating features based on requests
from a sales team. They’re thinking creatively about the problem space,
coming up with cost efficient, scalable and innovative solutions. Let’s
look at what an empowered employee needs, and how onboarding might enable
it:
Need
How onboarding enables it
Clear view of the company mission and business goals
Leaders
should build excitement for the mission, outlining what led to its
creation, what the future might hold, and how an employee can
contribute to that. This should include a view of the current product
strategy.
How does the company make money (or intend to)?
To instill a business sense and a focus on frugality, new employees
should know how the company currently charges for their services, its
profitability, and its level of investment.
Empathy for the customer’s experience
Set an expectation for all
employees to think about the customer. We can emphasize this by a
number of activities – observing the customer using the system, using
the system as a customer (if possible), and reading prior research
into customer problems.
An understanding for internal operations
Most software systems
have different users (beyond the target customer). It’s important to
understand all of those aspects, so that technologists can design
solutions that make those internal users efficient. This is
particularly important at scale
Business domain understanding
Many business domains are quite
complex. Understanding happens over time, but we can start with
overviews from an expert, and suggested readings
Working relationship with their team
In order to have open
conversations about concerns and ideas new hires need a level of
familiarity and vulnerability with their peers and manager. Onboarding
should include activities to enable this. It’s more difficult to do
remotely, so we recommend teams getting together in person within the
first few months of a new hire joining.
Clear understanding of their objectives
An empowered employee
needs a purpose, they need to know what their company would like them
to achieve, and how they’ll be assessed towards that
Current team topologies
The new hire should have a clear
understanding of the ownership of products and systems and whom they
can talk to get information. An up-to-date org chart with where they
sit in it’s essential. Intentionally setting up some 1:1s during the
first weeks is a good way to encourage communication across teams and
functions.
How technology is leveraged
Every startup uses technology to
innovate and scale, so all employees should have a base level of
understanding. We don’t believe it’s effective to divide roles into
‘technical’ and ‘non-technical’; some roles are just ‘more technical’
than others.
There will be role-specific needs. A developer needs know how to:
Need
How onboarding enables it
Write code and push to production
An environment that’s
fully setup and working, with access to deploy, they’re able to do it
independently. The environment gives them confidence that it will find
quality problems, and allow them to rollback safely.
Debug and fix production problems
Access to clear observability
that spans systems. This should include documentation, runbooks and
walkthrough videos of typical tasks.
Understand existing code, architecture, and
dependencies
Effective knowledge management system, access to all source code
repositories, access to dependent teams and knowledge transfer with
teammates and SMEs
.
Measure the progress of their solutions
Business and product
analytics, and also technical metrics (performance, availability,
cost, quality measures). It should include ability to experiment with
solutions (prototypes, A/B tests) and access to qualitative
feedback.
While this article is mostly aimed at developers, we can expand the
concepts into other roles. A product manager might need:
Need
How onboarding enables it
First-hand experience with customers
Start with an introduction
to key customers. Also, product managers need the space to build
relationships; we sometimes find that the founder wants to be the
conduit, which can make it difficult to get unfiltered
information.
Articulate current product strategy
A new product manager should
be able to quickly understand the current strategy, the relevant
signals, what the current product bets are, and if they’re
succeeding.
Find and access analytics
Ideally this is self-service and
exploratory, rather than having to request reports. This includes
product, behavioral, financial, marketing and sales metrics, and
system performance metrics.
Learn from previous bets and inflection points
The product is
currently designed a specific way for a number of specific reasons
(which may not be obvious). In order to successfully evolve the
product, it helps to know why it’s the way it is.
Build experiment prototypes and “play around” in the
system
Often product managers don’t have the access they need to use demo
environments or the resources to create prototypes
.
A designer might need to know how to:
Need
How onboarding enables it
Access tooling to create lo-fi and hi-fi assets
In addition to
the polished product, a designer should be able to easily create
clickable prototypes, and be able to conduct user testing with them
without much ceremony.
Find and use branding guidelines and design systems
To ensure
consistency and make designing and implementing UIs easier, these
should be accessible and well documented. The maturity of these
systems will depend on the maturity of the startup, evolving from a
shared design file to a living component library.
Discover previous user research
Recordings of previous user
testing, interview documentation, and synthesized research output
should be accessible and stored in a company knowledge base rather
than in personal silos.
Perform A/B tests and access behavioral analytics
The user
interface should be instrumented so that a designer can get as much
insight as possible in a self-service way. A number of A/B testing
frameworks allow for independent release and analysis without
developer support for certain types of changes.
This list is an example and not intended to be exhaustive; we suggest
you look at the objectives and the “jobs to be done” for your roles in
the context of your company.
To illustrate how this works in reality, we are going to use the
example of Checkr
Case Study: Checkr
Checkr, an HR technology company
powering the future of work, partnered with Thoughtworks on
scaling between 2018-2020. While working on their architecture, quality
and platform engineering, Thoughtworks consultants noticed the
effectiveness of Checkr’s onboarding process. When Checkr grew beyond
the initial team, they invested in creating a structured onboarding
process for all employees. The process was designed to build empathy for
their customers, understand the business, and bring employees to
productivity as quickly as possible. Regarded as a critical capability
by Checkr leadership, their onboarding process allowed them to grow from
30 to 300 engineering staff. Despite their success, Checkr continues to
evolve the process as they collect feedback, and try new ideas.
Cross-functional onboarding week to understand the mission, and
build empathy
Each month, Checkr ran a week-long onboarding “bootcamp” for all
new employees. The goal of the bootcamp was to provide employees a
holistic understanding of the company and product by hearing from
leadership and from other teams across Checkr. Members from other
functions such as customer success, finance, product and engineering
would review team processes and product use cases with the new
employees.
Along with the cross functional overviews, new employees were given
further opportunities to build customer empathy and understand the
problem space that Checkr aimed to solve. New employees would go to
the local courthouse to pull a record as part of a customer’s
background check and sit in on a customer support call as the customer
success representative used Checkr’s tools.
Initially, cohorts were around 20 people but grew over time. An
additional benefit of the bootcamp was that new employees quickly
built an internal network. Checkr’s Director of Engineering Krista
Moroder said: “I still use the initial network I made – one of my
onboarding buddies is still one of my first points of contact in the
Legal department.”
After the bootcamp, they conducted a role-specific 2-day workshop
followed by onboarding to their respective teams.
Path to productivity for a developer
The employee would have access to all the services and tools they
need from day one. Engineers can set up their personal development
environment with a script in a few hours. Checkr has a stated goal
that a new employee should deploy on day one, but in actuality it
changes team by team, on average it’s within the first week. They’re
currently moving from a laptop-based developer environment to a cloud
based approach, with the aim to speed up onboarding, because of the
added capacity and easier configuration management.
A lot of teams will use pair programming, which means a new
employee can jump straight into pairing on whatever task is the focus.
Krista talked about pair programming
“Thoughtworks was the catalyst for the pair programming on the team
I originally led. The primary motivation was to reduce quality
defects, reduce context switching, increase shared knowledge, improve
cycle time, and keep people connected and engaged when we went
full-remote during the pandemic. Teams use a model where engineers
choose pairs for the day when the daily standup ends.”
At Checkr they use a “you build you run it” approach, where each
developer is expected to support the systems their teams own. To learn
how to do this, after 1-2 months of joining, a new developer will
start by co-piloting the on-call support with a colleague. They can
typically resolve a problem independently after 2 months for an
internal product, or 3-6 months for a consumer product, depending on
seniority. For Krista “a productivity indicator is that their manager
or a tenured developer trusts the new developer to solve complex
issues end to end.”
Quality Awards and Learning Weeks
Onboarding is partly about the activities that happen when someone
joins, it’s also about the creating a culture that leads people to
effectiveness. Checkr wanted to encourage a continuous learning
culture, the company has run participant-led “Learning Weeks” 2-3
times a year, each time with the intention to focus on a different
capability, like infrastructure or quality, for a week. Surveys are
run before the camps, to understand current gaps in knowledge. These
weeks provide a chance to learn from peers. In an ideal world,
everyone would share expertise continually. But in a busy startup,
that doesn’t always happen. Learning Weeks set the intention, and
helps people become comfortable with asking for help and sharing
knowledge.
An important part of Checkr’s regular all hands is the Quality
Awards, where individuals are nominated by their peers and recognized
for their contributions. Instead of just celebrating typical
milestones like product launches, people are recognized for excellence
in documentation, testing, deprecation and refactoring. This
emphasizes a culture of building excitement around high technical
quality, and of peer support.
Beyond the initial onboarding period, the team sends surveys
regularly to assess the whole process. This helps them monitor whether
their processes are effective and have set a foundation for success in
the company.
