How Contrast Simplified and Streamlined Its New Hire Onboarding Process

A hiring team spends a great deal of time identifying and interviewing candidates before making an offer. On average, it takes 58 days between posting a software engineering opening and making an offer of acceptance. Within that window of making do without the position being filled, it takes our engineering department at Contrast Security roughly 60 hours of staff time to go from an opening to onboarding a new hire—a labor productivity cost of about $6,000.

What happens to that investment when the new hire shows up on day one? In software development and engineering, the new hire is often allowed to languish in a purgatory of ignorance. The assumption driving this behavior is, “Since we picked them, they must implicitly know what to do and how to do it.” This is a decidedly poor way to treat a candidate and moreover displays a lack of attention to the investment a company just made in filling the role.

With explosive employment growth happening on our engineering team at Contrast, we sought to improve onboarding for our newest members. We started by breaking down onboarding into two basic systems:

● Program mechanics. Designing a system to ensure an effective new hire experience

● Program metrics. Creating an overarching continuous improvement loop that is critical to both the existing team and newly hired team members

Onboarding Program Mechanics

The mechanics of effective onboarding are important to understand, even though they comprise only about 40% of the problem based on my own calculation. Engineers and engineering managers tend to reason from specific examples to reach general conclusions. To illustrate how our program works, I’ll walk through the first few days of a new cloud engineer at Contrast:

Welcome To the Team

On Day 1, a new cloud engineer receives a standard email in their inbox that provides:

● An introduction to their manager and teammates
● A link to the team’s Confluence workspace page that serves as the guide for the rest of their onboarding process
● A link to a Jira epic with 50+ tasks that they need to accomplish over the next couple of months
● A note encouraging them to ask questions directly in the team’s chat channel rather than via direct message

Their first day primarily consists of HR paperwork and a task to “Buy Lunch on ‘Uncle’ Contrast.” This provides the new hires with a small welcome perk. In addition to helping them feel welcome, it also helps verify that they are correctly set up in the company’s expense system before incurring larger expenses, such as conference travel.

Why Chat in Slack?

Direct message (DM) communications foster knowledge in silos. A new employee seeking advice can easily hit roadblocks or redirections if they do not intuitively contact the appropriate team member on their first attempt. This wastes time and inhibits team cohesion.

Pushing all communications into a team’s chat channel in Slack is a key aspect of Contrast’s on boarding program. This is done, in part, to support our core value of transparency. But it also helps simplify team operations and develop collaborative chemistry.

How teams share knowledge is a direct representation of the organization’s maturity level:

● Individual sharing (immature): What a single person knows
● Tribal sharing (maturing): What the team knows but is not written down
● Institutional sharing (mature): What is written down for any team member to reference when the need arises

If a new hire asks another individual a question, only the new hire and that other person share the knowledge. When the new hire asks the entire team a question in the chat channel, then anyone can participate in the discussion and the answer becomes common knowledge. Further, if the new hire captures the answer to their question in written form to help other new employees (such as an FAQ or guide document), the organization gains high-fidelity materials of institutional value.

Remember, the new hire is uniquely positioned to write the answer precisely because they lack the assumed context. They will naturally include more background and detail important to those who follow them.

Setting Examples in the Engineering Team

At Contrast, each onboarding task a new cloud engineer is asked to do is written in the same format used to write a ticket when breaking down work or describing a bug. For example, see the below:



This kind of example setting helps guide a new hire in subtle ways during their first week:

● It conveys the importance of a mundane task (e.g., email setup) that is essential to successful participation in team activities.
● It demonstrates the “check mark” progress tracker tool.
● It provides some common wisdom for successful task completion (e.g., configuring client rules for filtering).
● It gives them a broader “gold standard” example of the level of detail we expect to see in a typical team ticket.

Why Tickets?

In the past, our onboarding process relied on a long checklist of tasks that a new hire needed to complete. The engineers who went through this process reported that it was better than most of their previous experiences, but it was still lacking.

When someone on our team observed that we were blind to what a new hire was doing, we had an epiphany. We quickly realized that each onboarding task should be an official ticket—immediately indoctrinating the new hire into one of the key daily rituals of our team (viz., what we like to call “the daily stand-up”).

As engineers, our work is driven by tickets. We manage them on a board from left to right via specific institutional habits. Initiating new hires into these work rituals from day one instantly integrates into a team and accelerates their normalization. This enables them to hit the ground running and begin contributing earlier in their work process.

Why Jira Epics?

The image below is a direct copy from our internal Confluence page on how to run onboarding. While the specific content of our team’s Jira epic will obviously be different from those of other companies, our ideas and themes may provide some useful guidance.



Tasks are organized by week but are otherwise left unordered. This is intentional. Each week provides structure to help a new employee get started while leaving flexibility for them to focus in greater detail on a specific task of their choosing. The “nickel tour” tickets are designed to get the new hire to log in to our systems so they become familiar with them. There are also several demos that involve our supervisor, the security team, and our team in Belfast that works on Contrast OSS.

In Week 6, the ticket “Remove your Robin Training Wheels” appears. “Robin” is our nickname for an internal role on our team—one that’s dedicated to removing toil, repetitive work, and interruptions (as in “Batman and Robin”). By the time a new teammate makes it to Week 6, they should be ready to start making these kinds of critical contributions to the broader team. They can pick any task (based on their interests) to tackle at any time. This often occurs earlier in the onboarding process, as we’ve found that engineers frequently start doing so after Week 3—when questions about code and technology begin to fly around and the new engineer truly starts their technical onboarding.

Onboarding Program Metrics

To understand Contrast’s success in onboarding new hires, it is important to understand one of our guiding strategies:

In order to perform the work the business needs, we must maintain control of unplanned work and constantly seek to remove it when possible.

New hire questions are a form of unplanned work. It was impossible for us to predict what their questions would be and how long it would take to answer them. If we truly valued the reduction of unplanned work—and repetitive toil of answering the same question for every new hire—we needed to address this problem.

The solution for us did not come easily, but it seems obvious in hindsight. A new hire is uniquely positioned in an organization to record the answers to questions they ask. This led to the following realizations:

● It is important to set the expectation that new hires must make the time to read all prescribed materials, become curious, and then read more on their own.
● In order for this material to be useful, it must maintain a high degree of fidelity—such as Confluence docs, README.md, well-organized code, useful commit messages, and PR discussions.
● When the new hire realizes they are lost, their lack of understanding reflects a gap in the fidelity of these written materials. (It is not a reflection of their intelligence.)
● Because a new hire also has large amounts of unstructured time, they must be responsible for updating the materials with information that answers their questions.

This core continuous improvement loop means that most interruptions to the engineering team are much more than one-off assistance to a new team member. Rather, the support they provide:

● Improves the overall onboarding system
● Improves the team knowledge base
● Instills in the core team (through constant positive reinforcement) the value of actively contributing to high-fidelity written materials as part of any work task

Improved Onboarding Experience With Greater Efficiency

Engineers who contribute to their teams are happy engineers—especially when allowed to “choose their own adventure.” At Contrast, we want our newest members to spend their time learning, connecting with teammates, and enjoying a “honeymoon” phase after joining the company.

Since implementing this ticket-based system, our team’s recent hires have enthusiastically reported the best onboarding experience of their careers to date. In terms of productivity, we have seen new hires enter the on-call rotation in six weeks with confidence. Meaningful contributions to processes and documentation happen on Day 1 and to contribute to code as early as Week 3.

We recently added five new engineers to our team. Rather than slogging through question after question while staying up late to get our own “day jobs” done, new employees—with this new process in place—were able to self-serve much of their onboarding needs.

The initial investment of roughly 60 hours of time redesigning the Contrast onboarding process saved us roughly 500 hours of needless toil in 2020. That alone shows the program changes were an investment well worth making.

While the specific details of our onboarding program for Contrast cloud engineers may not map to every team or organization, these tools and techniques can offer a starting point for reimagining a more nurturing new hire process and building a stronger team culture over time—processes and lessons that hopefully are helpful to other engineering teams.