How to decrease your software engineers' ramp times using Flow
Intro
Considering that the average tenure for a software engineer at a tech company is less than two years, ramp time is literally money.
But when are you actually done onboarding? This playbook refers to a formal 4-week onboarding process that ends when your engineer understands their basic team processes, but “time-to-productivity” is a longer perspective that ends when your onboarded engineer has met the productivity of your more tenured engineers.
We looked at 11.5 million Flow data points (representing the work of 2,642 engineers) and the relevant onboarding practices employed by each company to better understand ramp time--and the results were substantial. Although the average time to fully ramp a new engineer was 6 months, we found that organizations actually fell into two camps: companies where the typical time-to-productivity was 3-4 months and organizations where onboarding took 11 - 12 months. Clearly, we’d prefer to be in the former group. So how did organizations get there?
Our study found the companies with the fastest time to productivity used strategies like peer shadowing, pair programming, complexity scaling, and a skill development program enabled by objective insights from Flow.
The biggest takeaway from the study and our own experience was that the better companies planned, the more successful their onboarding was. This playbook will walk you through how to plan your onboarding process using Flow.
The Four Pillars of Engineering Onboarding
In onboarding, there are four pillars that have equal importance: feeling a sense of belonging, onboarding for coding, understanding the product, and learning and growth. Flow helps with all four pillars.
Belonging
- Connect with co-workers
- Feel valued
- Understand the engineering culture, values, and mission
- Connect with mentors
Coding
- Make contributions to code base
- Show up for the team in code reviews
- Build impactful commit, PR, and ticket behaviors
- Use frequent feedback loops to improve
Product
- Share a vision of why your work matters
- Champion the customer
- Understand the product architecture and interfaces
- Learn about competitors
Growth
- Define success in the role
- Find and complete stretch projects
- Engage in career discussions
- Set aside time for learning
Onboarding Preparation
Set expectations with the team
Before you start onboarding, become familiar with the following three reports. Check that their configurations are correct, and explore your current team’s data to understand trends. To keep your new hire from getting overwhelmed, focus on one report per week.
Week 1: Check-In
See what your new hire has accomplished and what they could use help with.
Week 2: Review Collaboration
This report helps visualize the connections your new hire is making.
Week 3: Team Health Insights
Use this to see how the overall team is doing, and make sure that your new hire is feeling connected to the team’s process.
Tips
If you’re onboarding more than one engineer at once, create a New Hire Cohort to track their progress overall. To do this, go into your Flow settings, click “Teams” under User Management, and click “Create Team.” This helps leaders see how they are supporting new hire onboarding efforts. Are new hires getting slowed down by roadblocks? Or are they having a hard time with a specific area of the code base? It’s important to note that your New Hire Cohort team should not be a tool for comparing new hires to each other.
Week 1
In this first week, focus on the Belonging pillar and the Check-in report. Your new hire should meet each person on their team, learn how you use Flow and its data for good, and start to get an understanding of how they can contribute to the team.
Belonging
- Set up your engineer with a buddy who can answer questions and introduce the rest of the team.
- Welcome your engineer to the team by shouting them out on Slack or Teams, and encourage your team to welcome them individually.
Check-In
- Your engineer might be unfamiliar with, and therefore wary of, Flow. Explain that this report is to help the engineer see their strengths, grow, and celebrate their accomplishments. It’s not to monitor their every move or compare them to their team members.
- Use Check-in during 1:1s, and encourage your new hires to own this report as their progress tracker.
- Set a short-term goal within the report. Your new hire can then track their progress within the report, and report on that progress during each following 1:1.
- Look at the commit complexity widget. Your new hire’s work should scale up in complexity throughout the onboarding process.
- Look at the “Total activity” after the first 1:1, to discuss what your new hire has been working on, and how they’ve felt about that work.
On the technical side, introduce your new hire to your local development environment. At Flow, our own engineers’ first ticket is to improve onboarding documentation so they can get a commit through the entire process (merged to production) as quickly as possible while becoming familiar with the environment. Choose a simple ticket like this to get your new hire started, so they can feel that they’re contributing to the team as soon as possible.
By the end of the week your new hire should:
- Understand how Check-in works for them. Check for understanding, here, by having the new hire lead your next 1:1 with Check-in.
- Accomplish their first ticket.
- Meet their team.
Week 2
In the second week, focus on the code pillar and the Review Collaboration report. Your engineer should be making progress on the first tickets you assigned, pair programming with at least one other engineer, and they should start reviewing their peers’ work. This way, by the end of week two, they’ll have a pretty good understanding of your code base.
Set up a 1:1 at the beginning of the week. Talk with your new hire about how their first tickets are progressing. Are they running into any issues? How do the tickets feel in terms of difficulty: too complicated, too easy, or just right?
Code:
In week two, have your new engineer review at least one other engineer’s pull request. Have your engineer set up a 1:1 with the other engineer to discuss any changes or feedback they might have.
Reviewing code as soon as possible helps with onboarding for 3 main reasons:
- It helps the new hire meet their team.
- The new hire gets to show off their skills, which helps with any feelings of imposter syndrome.
- The existing team gets to learn from the new hire, and hear from a new perspective.
Review Collaboration:
Look at Review Collaboration to see who your new engineer has collaborated with so far. Are they reviewing their team’s work, and vice versa? Your engineer should be reviewing at least two team member’s code per week, and they should do this until they’ve reviewed everyone’s code at least once. Again, this review process is a crucial step for helping new engineers get to know the team, helping them get up to speed with the code base, and facilitating learning across the team.
As you show this report to your new hire, emphasize that the goal is not to be at the top for the list for “Most PRs reviewed,” as that can mean the engineer is struggling to focus on their own work. The goal, instead, is to have as many lines between the reviewers and submitters, as that suggests a collaborative team.
By the end of the week your new hire should:
- Understand how Review Collaboration works.
- Review at least one team member’s PR, and provide a thorough review.
- Meet with the team member with the PR, to get to know them better and to provide verbal feedback.
Week 3
In the third week, focus on the Product pillar and the Team Health Insights report. By the end of this week, your engineer should have a sense of “normal” within the team. They should understand their day-to-day work and have a rough sense of their and their team’s tickets and largest priorities.
Product:
Have your engineer have a 1:1 with their product manager (or the closest equivalent on their team). Engineers should have an understanding of:
- The roadmap for the next quarter and the next year
- Their company’s biggest competitors, and how they stack up against each other
- Who their customers are, the customers’ needs, and how their company addresses those needs
- The “why” behind their tickets and how that relates to their product
- The epics, or largest priorities, and why they’re important for business and product success
Having good context into the product and the why behind the product roadmap will help your engineer’s motivation and sense of belonging.
Team Health Insights:
This report will help your new hire see what the team’s current review processes look like. Click “Edit metrics” and then select only the metrics under the Culture tab.
Reaction time shows how quickly a reviewer responds to a PR. For new hires, it’s particularly important to aim for a fast reaction time. Slow responses can make new hires feel dismissed.
Responsiveness is the flipside of reaction time. Once the reviewer sends their feedback, how quickly does the original submitter apply that feedback? With new hires, it’s okay if this response time is slower, as that means the new hire is taking time to understand the feedback.
Thoroughly reviewed PRs is the percentage of non-trivial comments, which we calculate by looking at the word count of the reviews. This prevents rubber stamping and encourages engineers to give valuable feedback.
Time to first comment sets the standard for team expectations. Make sure that your engineer feels free to work on their own work, but also that they know that reviewing others’ work is also an important priority.
For Unreviewed PRs, your team should aim for zero. Unreviewed PRs are a potential security or quality risk.
By the end of the week you new hire should:
- Understand how Team Health Insights works.
- Understand the product roadmap and a general sense of competitors
- See how Team Health Insights shows how the team works together
...And Beyond
Managers know that onboarding is never quite “done.” In fact, our study found that the companies with the fastest time to productivity have onboarding plans as long as a year. Round out your onboarding process by focusing on the Learning and Growth pillar and making sure that your engineer understands how Flow reports interact.
Learning and Growth
Give your engineers opportunities to get their hands dirty with new coding languages, technologies, or projects. That said, too much learning, or too many new projects can feel overwhelming, especially for new engineers. Pluralsight Skills has courses to help your engineers upskill, along with assessments that will guide their learning. Make it clear that these courses and assessments are there to support, not measure, them.
Flow as a whole
As part of their learning, encourage your engineer to explore the other reports in Flow to see how their data shows up across the report. For digging deeper into Flow, share Flow playbooks with your engineer:
- How to reduce cycle time
- How to improve collaboration (coming soon!)
- Getting started with Flow (coming soon!)
