People are the most vulnerable during transitions. It’s a time of uncertainty, when everything is changing and you aren’t sure what you can count on. Many things you were used to have changed and you need to quickly acquire new knowledge and integrate it into your world. This concept has been well-studied in health care, but I find it’s a more general principle. In particular in this post I will apply it to three aspects of working in tech, and give some suggestions on how we can protect people from failure during transitions.
Onboarding
Most people would agree that onboarding is considered a critical part of the hiring process. Yet in practice it’s often done without any structure or haphazardly. This can result in very negative outcomes–it’s not unheard of for employees to quit merely because onboarding was bad. Even if that doesn’t happen, good onboarding can accelerate employees to become productive much more quickly. Often companies will just “throw people in the deep end”, expecting them to figure things out. Maybe they’ll have some basic onboarding task, but it only lasts a few days and doesn’t cover everything important. These might be ok for some people, but for most it’s not enough. Here are some key things to consider in any onboarding plan:
Give everyone a mentor. There should be an existing engineer whose job it is to ensure that the new hire is successful. This could be expected to take up to, say 50% of the mentor’s time, it should be the most important thing they do for that period. They should be very responsive in answering questions and unblocking the new hire. Some are fond of pair programming with the mentor, this can be an option for those that like it.
Adjust the onboarding plan to the employee. Some people have experience in your stack and some don’t. Some are straight out of college and others have decades of experience. Some are extraverted and will meet everyone at the company on their own, some need to be pushed. Each person can benefit from a tailored plan to focus on learning the things they won’t do as well on their own.
Don’t be overwhelming. There is so much to learn in any new job that it is easy to get overwhelmed. A good onboarding plan will spread out information in logical groupings so that the new hire can focus on each one at a time. For example, week 1 could be basic environment setup, familiarizing with tools and the product, week 2 could focus on learning about how the frontend works, week 2 could be about some particular service (say the API server), etc.
Pick a good onboarding project. Typically you can start with some very basic starter task (like fix a tiny bug) just to get them comfortable with the environment. After that give them a medium-sized project that they can use to learn other parts of the product. It is often good for this to be something that helps them understand the core business so they are more aligned with the company goals. Try to avoid giving them boring cleanup work, you don’t want to be their first impression.
Don’t end onboarding too early. It’s easy to think that once someone has shipped some code that they know what they are doing. In reality there are many things that they need to learn, and this will take a lot of time. Onboarding typically takes on the order of 3-6 months (longer for more experienced hires), and it can be helpful to have structure the whole way through.
Changing Teams
There will come a time in which an engineer on your team wants to do something different. They might immediately consider looking for a new job. As a company you should instead encourage them to change teams within the company. This saves you the high costs of hiring and onboarding a new hire, and allows you retain that employee’s context. Having people move around teams like this can give new perspectives on different aspects of your business. However, this type of transition is also a vulnerable time. There are some important aspects to consider in any team change process:
Don’t make it too difficult. The goal is to discourage the employee from applying to other companies. If your internal transfer process is equally difficult as that, for example if you require a full interview loop, then they might think they are better off “playing the field”. A more abbreviated and informal interview focusing on their motivations is better, prior performance should be shared within the company and so obviate the need for interviews to gauge performance.
Support them on both the old and new team. For the new team this can be seen as another type of onboarding (see the section above), but it can be more abbreviated since they likely have a lot of necessary knowledge (this will depend of course on how similar the new team is to the old team). But a part that is often overlooked is that the old team should also support this transition, for example by directing questions away from the former teammate and helping them to transfer their previous responsibilities. They should be given the chance to fully focus on their new role.
Be honest when talking to potential hires. Your goal should be to ensure that the potential hire succeeds on your team, not that you simply get anyone as soon as possible. Hiring the wrong person is potentially devastating and can set back a team months or even years. Be honest with what role you are looking for and what their work will entail. Make sure that there is alignment there, the engineer might themselves not realize this, but you as the manager should be able to have a better sense of whether it’s the right fit or not.
Changing Software
A third type of transition that can be risky is when software changes. It’s often said that “people don’t like change”, but this is clearly false. What they really don’t like is abrupt change with no transition plan. If you are redesigning your software to have a completely different UI, this is going to be very jarring to your users. Just like any other transition, it’s therefore a concern that they will quit using your product as a result. Here are some suggestions for handling software UI changes in a better way:
Make gradual changes, if possible. Sometimes you do need to change everything at once, but often it’s possible to roll out one change at a time. People would much prefer to learn one new thing at a time than everything all at once. Indeed I’ve often seen many changes made together simply for “marketing” reasons, like being able to make a big announcement. This can have value (consider something like a new iPhone release), but in general it’s less disruptive to avoid that.
Roll out in phases. Don’t release all the changes to everyone at once. This gives you time to collect feedback from the first users and potentially make revisions before you roll it out further. The simplest way to do this is just some simple % rollout, say testing on 10% first. This has the advantage of being an automatic A/B test you can use to compare metrics. However it may also make sense to roll out first to interested users (“sign up for the beta”) or power users, as they will be more likely to be willing to learn new things and give you feedback.
Provide proper guidance. Some kind of walkthrough or guide of new features or changes can help people to acclimate more quickly. However, you should be careful of this, as many users will completely skip them out of habit. Don’t assume that a confusing feature with a good tutorial will be fine. It’s much better to spend more time making the UI itself clear and easy to use than to make the tutorial fully comprehensive. Of course ideally you would have both.
Offer an opt-out mechanism. If you are rolling out in phases (which you should be), then you can offer a temporary opt-out mechanism while the changes are still being worked on. It is useful to ask for reasons for why the user is opting out, as this is a good time to get “in the moment” feedback about what specifically prompted them. However, you must also be careful with this approach. Some people will opt out just because they don’t want to learn something new, and this doesn’t mean your changes are bad. Additionally, if you ultimately will force everyone to the new version, then providing an opt-out can make this transition even more difficult. Make sure to set clear expectations as to how long this opt out will last.
General Principles
You can see a lot of commonality in the advice I’ve given for dealing with these three types of transition. These general principles can be applied to any other transition in business or in life:
Move slowly. The bigger the change, the slower it should be implemented.
Provide extensive guidance during the transition process.
Be flexible with how the transition is done, and allow for some customization.
Make sure the transition makes sense and be open to revision.