To get a new software engineer up to speed quickly, several things must already be in place. An assigned buddy who can be the first point of contact for questions or issues that arise. A manager with a written ramp up plan for the new employee with clear guidance on performance expectations. A self-serve development environment with clear documentation for getting your code base running locally.
An assigned buddy helps to make the first few weeks of getting started easier. They will set up time with the new hire on their first day to point them in the right direction. They can help troubleshoot issues the new hire may encounter. They will assign small tasks to get exposure to the code base. They’re also a friendly face that they don’t have to feel bad about asking questions.
Giving explicit permission that it’s is okay to ask questions and take the buddy’s time is very important. When you are new, defaulting to “I don’t want to bother people” is common, but is a detriment to getting up to speed. Remote teams in particular, need to be more deliberate about everything.
The manager of the new engineer is responsible for making sure the new hire understands what is expected of them. The simplest way to do that is to share a 30/60/90 plan and review it at the first one-on-one meeting. The first 30 days should be about solving small tasks that have already been flagged from the backlog which are self-contained and less than a day of work for a fully ramped engineer. At 60 days, they should start working on a medium size project that is has already been scoped out (i.e. there is a reasonable level of technical details worked out so that such that it looks like a list of small tasks). For career level engineers, at 90 days, it’s time to lead a project that they scope out and deliver with one or two other engineers.
The plan gives the manager and new hire something to check in on regularly to make sure expectations are being met. If expectations are not being met according the timeline, share feedback and make an adjustment. If the new hire is repeatedly not meeting expectations it’s time to part ways.
A common mistake is to move on to working on projects too early. Shipping small things (1 small thing per day) builds familiarity with the code base and problem domain. Getting things done is the foundation of just about everything and it is much more difficult to assess how it’s going when they start working on larger, more complicated projects.
It’s likely that your systems and working environment will cause an otherwise successful engineer to fail. Parting ways early if it isn’t working out is best for both parties—you need engineers to hit the ground running and they deserve to work at a place that maximizes their ability to do great work.
A self-serve development environment should be in place so that a new engineer can ship to production on the first day. For example, running a single command to get a fully working local environment (as much as I don’t like docker, it’s still the best for this) and having an easy way to deploy to production. Without this, even the most experienced engineers will spend days if not weeks, struggling to get the right toolchain and packages installed.
See also:
- After ramping up successfully, performance management should continue
- Engineering management