One of the challenges with onboarding remote, early-career engineers is generally the lack of structure and planning.
Leaders often put together a simplistic onboarding program without taking into account different personalities and work styles. The onboarding program tends to reflect the biases of the person putting the program together and doesn’t always lead to successful outcomes for the new hire.
Since there is no one-size-fits-all approach, we should try and optimize for the behaviors that have tended to prove successful in remote work environments, such as asynchronous communication. However, we need a structured approach for building up new hires’ muscles in this area. The overall goal is to outline a program that is rigorous and laced with feedback and defined transition steps. Adopting a structure that sets measurable goals for remote worker development can increase success rates for engineering teams.
Learn the product
Many teams believe that having engineers spend their first weeks working in support is a great way to build empathy for customer issues. Additionally, it’s a hands-on way to learn the product. However, most teams implement a fixed-time approach to this model that rarely exceeds one month. Do people really build sufficient empathy in a few short weeks? The answer depends on the individual as people learn and build empathy at different rates. The real question is, are we achieving our desired outcome with this approach?
We cannot assume that most product engineers possess the qualities of successful support engineers. They often do not. That’s not to say that there is no benefit to them performing a rotation in support. It’s just questionable whether that should be one of the first things they do. Providing good support requires knowledge they have not yet acquired because they have not yet learned the product.
Try this instead. Give your new engineer six features of your product to learn using either a test account or an instance on their local machine. For each feature, ask them to provide as detailed a write-up as they can. The write-up should include:
- The problem the feature is intended to solve;
- How to use the feature;
- Suggestions for possible improvements;
- Extra credit: video demonstrating the feature in action.
Most of this should be straightforward if you have good documentation available. The goal, however, is to assess how well the new engineer understands the feature and is able to communicate it. For the person being onboarded, this is an achievable and constrained task. To avoid potential spiraling, set an expectation of one-to-two features being documented by the end of each week.
As documents are completed, have the new engineer share with the team and request comments. You should have already set the expectation with your team that they should provide feedback as their contribution to onboarding. You are now setting the expectation with the new engineer that requesting and receiving feedback, primarily written and asynchronous, is part of the culture.
Learn the codebase
Engineers want to code, especially early-career ones. Your job is to provide context and guardrails. You could just throw them at your codebase and let them run wild, but I’d advise against it. Many teams provide tons of possibly up-to-date documentation about the code for new engineers to read. That’s helpful, depending on how up-to-date the docs truly are.
Code reading is an infrequently used tool for learning a codebase. When done effectively, it helps engineers understand the corner of the codebase they are working in. However, given the number of third-party dependencies that exist in modern codebases, this may not be as effective globally as it once was.
One key to success with early-career engineers is setting the expectation with them that they cannot learn everything about the codebase upfront. Instead, they should focus on learning incrementally and on-demand. This can then be reinforced with the practice of assigning bugs and writing tests. Instead of treating these tasks as chores to be dumped on the new person, the more enlightened view is one of learning opportunities.
Fixing bugs allows you to see how the new engineer approaches problem-solving in the context of your application as opposed to the smaller scope of the interview questions you gave them. Similarly, asking them to add tests in an area of the codebase that has little test coverage can give you insight into how much or how little they explored and understood that area. In both cases, you can assess their pull requests (PRs) for both comprehension and clear communication. Feedback on PRs signal to the new engineer that their team is there to help them and reduces the possibility of major issues occurring.
Communicating intent
‘Just read the code!’ is one of the least helpful pieces of advice early-career engineers are given and is often an excuse for under-documenting an application. The code communicates the how and the what but often obscures the why. The lack of this context often leads to new engineers joining and contributing to the mutation of the codebase away from the original design principles, especially in engineering cultures that prioritize speed.
In reality, the saying ‘Sometimes you have to go slow in order to go fast’ has proven correct more often than not. Design documents or Request for Comments (RFCs) are fantastic tools for capturing intent. Coaching early-stage engineers to capture both the problem and their proposed solution in an RFC is effective and time-saving. Submitting an RFC for the team to review is less costly than having to review multiple PRs only to find out that some incorrect assumptions have been made. There is also less impact to the engineer if they are getting feedback on a document, as opposed to potentially having months of coding work rejected. Over time, a centralized repository of reference RFCs is a way of paying it forward to future engineers on your team as well as the ones already on board.
Trust but verify
A popular misconception is that once you hit the Merge button and your code is deployed to production you’re done. Are you? Sure, your feature is implemented and available for customers to use, and that confirms the output of your work, but what about the outcome?
Remember that JavaScript snippet your product manager asked you to include for activity tracking? Or, those events they asked to be pushed to your data warehouse for later analysis? The days and weeks after a feature has been deployed are a perfect opportunity to engage your new engineer in the product-engineering feedback loop. Engineers should understand the impact of their work on the business. They should be asking themselves:
- How many customers engaged with the feature?
- Is usage increasing or dropping off?
- Are actual behaviors trending with expectations?
- Has performance been impacted?
- How many new bugs have been detected for this feature?
- How many feature requests or modifications have been generated from this feature?
All too often, engineers build features that meet specifications but not expectations. This is due to an overemphasis on code completion (output) as opposed to mission completion (outcome). By involving engineers more in outcome-oriented activities, they start understanding the relationship between their work and business value. Over time, they will intuitively consider business impact as part of the process of writing RFCs and, subsequently, features.
The end of the beginning
Software engineering is a discipline that is fueled by continuous learning. Most onboarding programs were designed with an expectation of co-located teams and learning that occurs through in-person communication rituals. The combination of these factors can prove challenging to early-career remote engineers. While these engineers are likely eager to learn, learning to work effectively in a remote-first environment presents an additional hurdle for those just starting out.
To succeed in remote-first environments, people must master asynchronous communication practices. By crafting onboarding experiences that combine task-orientation with a focus on explicit asynchronous communication we stand a better chance of growing engineers that are capable of producing more than great code. We often say that engineers should spend more time thinking than they do writing code. Today, it is even more important that engineers spend greater amounts of time thinking, communicating, and collaborating on the problems they are trying to solve. This should drive our efforts to onboard early-career engineers and help them become successful.
