Better Short Term Goals for New Engineering Hires

As a manager, one of the most impactful things you can do is successfully onboard a new hire. A good onboarding experience will get new engineers contributing to the code, team, and product, and will hopefully set the stage for a successful run for the next few years. Setting impactful and achievable short term goals in the first 90 days will kick off new hires on the right foot.

While hopefully you have support from HR, Operations, Recruiting, etc. on general company onboarding, it is your responsibility as an engineering manager to make sure it goes well; the buck stops with you. Onboarding into engineering is particularly challenging, and has more aspects than can be covered in one blog post. Before going any further, I’d recommend reading this post by Kate Heddleston. Kate has written and spoken extensively on the topic of engineering onboarding, and her post does a great job covering responsibilities of the team. This post is meant to supplement hers, focusing specifically on managerial responsibilities.

Now that you’ve read Kate’s post and have all the structure in place for successful onboarding, what are your responsibilities as a manager? How do you hold yourself and your new hire accountable for becoming productive?

30 / 60 / 90 day goals

In other disciplines, you hear a lot about 30 / 60 / 90 day goals. I’ll save you the business-y terminology behind it all (though, Google it, if you’re into that sort of thing), but the idea is to break up different phases of how you’ll start accomplishing your job in 30 day chunks. Often when applying for jobs, candidates will put together a 30 / 60 / 90 day plan, that they can then be held accountable to when they start a job. It sounds great, I like the symmetry of the math, and this all seems to be a well accepted practice in other disciplines.

For engineering, there’s a lot to like about the 30 / 60 / 90 day model. You can tell a lot about an engineer in their first 90 days on the job (certainly more than you can tell about them in a few hours of interviewing). There are also clearly different stages of onboarding in engineering — getting an environment set up, building your first big feature, etc. However, the timing feels a bit off. So I offer the 5 / 30 / 90 plan. The math doesn’t work as well, but I think it reflects sound goals for engineers starting up.

Engineering Onboarding 5 / 30 / 90 Day Plan.

The 5 / 30 / 90 day plan for onboarding engineers breaks the onboarding focuses as such:

• By day 5, learn to commit
• By day 30, learn the process
• By day 90, learn the code

Let’s look at each of these phases in detail.

By Day 5 — Learn to Commit

When a new hire starts, remember that they’re starting with a completely blank slate. Whether they’re downloading code from a remote repo or everything is already set up on their machine when they get there, it’s all new. So the first things they must learn are the basics of compiling, running, modifying, debugging, and committing changes to this new system. The goal should be to set all this up within 5 days, if not faster.

Obviously before anything can happen, your new engineers need to be able to get and compile code. While this is best left as a responsibilty of another engineer / mentor on the team, it’s incumbent on you the manager to check in on day one and make sure this happens. It’s easy for the responsible party to get sucked into a meeting / fire / conversation about their favorite podcast, and often hard for a new hire to muster the courage to ask for help.

Remember also that while this is easy for you with everything already set up on your machine, your new hire doesn’t know the special maven incantation or tweaks to the IDE that are required to actually run your build. Be patient, and document all the tribal knowledge you can, as you likely won’t hire engineers often enough to remember everything.

Once a new hire has code up and running, task them with a small fix. This is a fantastic way to learn the code, and will help new hires to feel way more productive than reading documentation or a code “scavenger hunt” (AKA “Find the checkout screen!”). For entry level hires, this is particularly impactful as they’re often craving the ability to make an impact as fast as possible. Your job as a manager is to feed that desire!

When I say “small fix”, I do mean small. The act of fixing is much more important than the impact or complexity of the fix; the easier and smaller the better. I’d rather see a new employee move a button 10 pixels or update a localized string than take on a complex feature.

Your goal is not only to have new hires make the change, but also go through every part of the process of committing that change: commit to the right branch, request a PR, run the tests, update the bug tracking system… this list could go on, and will depend on the culture of your team. But that’s the point! Your new hire doesn’t know which of these things are part of your process, or where to find them when they do exist. This 5 day period and small bug fix are their opportunity to start learning.

Finally, while I refer to this as a 5 day period, your goal as a manager should be to get your new hire through this as fast as possible. Five days is acceptable. One day is ideal. And yes, I’ve seen that happen. Often.

By Day 30 — Learn the Process

Committing isn’t the only thing that’s different team to team; processes also vary throughout the industry. Whether you do Scrum, Post Agile, Post Buzzword, or anything in between, you should focus on getting your new hire accustomed to you the process in the first 30 days.

Thirty days is significant based on how most teams seem to operate. In 30 days, a new hire should see one or two development cycles / sprints / units of development time. That should be enough time to see how you run different meetings, how you estimate work, how you review completed work, etc. Your new hire will need to understand these processes before they can take on larger tasks.

In 30 days, your new hire should start to get a sense of the shipping process as well. Hopefully your teams ship to production at least once every 30 days; if you’re a web shop with a strong continuous delivery culture, it will be a lot more than that. Either way, this will be important for your new hire to understand. Remember that just because these processes are happening “around” your new hire, that doesn’t mean your new hire will learn them! Can your new hire shadow your release lead? Who’s showing the new hire how they navigating release analytics? Make sure the existing engineers are teaching these processes.

By Day 90 — Learn the code

Before you go flaming me on the internet, no, I don’t expect in 90 days a new hire is going to understand every line of code in your complex system. But in the first 90 days, you new hire should learn enough of the code to be comfortable taking on larger tasks, and have a general idea of the strengths and weaknesses of the architecture. They’ve probably encountered some of the more challenging parts of the code that haven’t aged well. They may have even shipped a production bug (it happens to the best of us).

The important thing is that by day 90, your new hire is integrated in the code and while they don’t know everything, they know where to look. This should allow them to take on most tasks that you’d ask of someone with their experience level.

Delivering the 5 / 30 / 90 day plan

As a manager, if you’re following the 5 / 30 / 90 plan (or any other plan for that matter), you should set these expectations with your new hire from the start. Talking to your new hire in a 1–1 on day one and laying out some of these expectations will help your new hire understand when they’re on track for doing awesome work. I often find day one is hard for new hires to absorb everything, so focusing on the Day 5 section on day 1 and saving the 30 / 90 section for the second week may be helpful.

Regardless of how you talk to your new hire, it’s the same principal as the rest of onboarding. The most important thing is ensuring your new hire understands these expectations, and has all the tools to deliver on them!