Recently the teams in my workplace have decided to hire several junior engineers. We have been able to get several excellent applicants through outreach to universities, internships, meetups and the hard work of our recruitment team. But this post isn’t about that - it’s about the next problem: how to support junior engineers when they start working with us?

We want new starters to feel welcomed and comfortable from the very beginning, and we want them to be able to grow into wonderfully productive and happy colleagues. The most important output of the best senior engineers is more excellent engineers. But we have little experience of how this actually happens. Therefore our first step was to think about what the needs and wishes of a new starter are, and make sure that we had some way of ensuring that those needs would be met.

This post describes how we did that, and what we discovered. Some of it is naturally specific to our situation (3 dev teams, cloud infrastructure work) and some is probably useful to any team. I found that there was not much information online on this topic so I hope my writeup here is helpful.

Brainstorming

After a brief mention in our weekly huddle, we found a half-dozen interested people (including, happily enough, our 2 most recent hires) and ran a 1-hour diverge and converge meeting.

diverge and converge

Our first objective is to discuss: What does a new starter need?

  • before they start
  • on day 1
  • in their first week
  • in their first month
  • in their first year

Also: what new-starter antipatterns should we avoid?

The specific times there (day/week/month/year) are rather arbitrary - intended to make sure we consider their changing needs as they settle into their new job.

This generated a lot of ideas. So we discussed them for a while and then considered the question from another angle: What roles need to exist to make sure these needs are met?

Our approach here was to spend time grouping and classifying the starter’s needs, discussing who should be responsible for making sure they aren’t neglected. We also recognised that this is a living process and should explicitly consider sustainability and feedback for improvement.

We identified 6 independent roles, which seemed to naturally cover the set of things we want to do. A few important notes:

  • The person in a particular role is not responsible for meeting each of the starter’s needs. They are responsible for noticing whether the needs are being met and providing help if necessary.
  • Support and training should be available for people looking after new starters.

Here are the roles we ended up with:

1. Onboarding buddy

Goal: Make sure the initial onboarding instructions are accurate and provide help with things which starters need to do only once.

The onboarding buddy is usually expected to be the previous most recent new starter (who has it all freshest in their memory). I’ve worked with this arrangement before and it’s helpful for keeping things up-to-date.

  • Before they start
    • Make sure the new-starter checklist is up-to-date (this says how to check SSO/access email/setup VPN etc)
  • Day 1
    • Introduce and explain the new-starter checklist
  • Week 1
    • Orientation of internal systems: here’s how to request holiday etc
    • Help with completing any mandatory HR items
  • First month
    • New starter checklist is complete
  • First year
    • Support when the starter is someone else’s onboarding buddy

2. Social buddy

Goals: Check that the new starter feels comfortable, is known in the office, and is included in social activities.

Maybe best if it’s someone from a different team. If the new starter already knows someone then so much the better.

  • Day 1
    • Introductions to people around the office
    • Get everyone to go to lunch together
  • Week 1
    • Do people hang out after work? Invite the new starter
    • Explain where the best coffee is bought from
    • Go to Brewdog
    • Play foos and pool
  • First year
    • Make sure there are more social events (karting, bowling, gin-tasting, etc)

3. Manager

Goals: First point of contact. Career mentor. Various bureaucratic responsibilities. Represents the starter in the company.

  • Before they start
    • Decide who the manager will be, introduce yourself by email
    • Send out a day 1 itinerary. What time to arrive? What to bring?
    • If multiple new starters are starting together (eg intern groups) connect them with each other
  • Day 1
    • Is physically present when the new starter arrives. If not possible due to travel/illness/vacation/etc, has delegated all day 1 activities cleanly
    • Introduce to other supporters (social buddy etc)
    • Inform if anything important is happening today (visitors, all-hands, etc)
    • Tour of the office. Fire escapes
    • Knows which team the starter will join initially
  • Week 1
    • Explain what projects are happening in the office. Both the technical teams and the university/startup outreach teams
  • First month
    • Frequent 1-1s
    • Up to this point, new starters should not have had to care about politics/deadlines/other corporate stuff. Start to introduce it now
    • Start to widen their network outside of co-located teams
    • Training/learning needs identified. Show O’Reilly bookshelf, find external courses/MOOCs if desired
  • First year
    • Weekly 1-1s
    • They have worked on several different teams
    • Ensure increasing levels of responsibility/autonomy/independence/trust
    • Ask if they can join the hiring/interviewing teams
    • Get involved with meetups/conference speaker/uni visits (if wanted)
    • Progressive targets & encourage setting of own targets
    • Broad understanding of several work areas. Contributions to a subset of that
    • Starter still works here. Or, if it’s genuinely not working out, make sure there is a clear shared understanding of why not and possibly help with further career goals outside of our company

4. HR/Admin team

Goals: Excellent logistics

  • Before they start
    • Requests hardware (laptops etc) with enough lead-time
    • Request accounts on HR systems etc
    • Building pass

5. Team buddy

Goals: Welcome the starter into the team. Work together and teach how the team works.

This is someone on the dev team they are initially joining

  • Before they start
    • Some advice on (optional) background reading for that team’s work
  • Day 1
    • Empty and clean desk is available. Within the team space, not isolated
    • Help dealing with the monitor stands, unboxing laptop
    • What slack channels should they join (apart from #fooz of course)
    • Commit some code (as part of a pair, probably)!
  • Week 1
    • Ensure the team goals are understood, also who is working on what
    • Provide help with dev processes (source-control, CI, IDE, communication tools etc)
    • Provide a well-defined concrete task (again, as part of a pair is fine)
  • First month
    • Ensure integration into everything the team does together
  • First year
    • Starter been to an external conference (ideally with the team)
    • Starter is delivering/contributing regularly

6. The new starter

Oh yes, they have some responsibilty for their own destiny!

  • Before they start
    • Chill out!
  • Day 1
    • Go with the flow. Stay chilled
  • Week 1
    • Continue being relaxed
    • Knows everyone on their team and is comfortable interrupting anyone
    • Is asking lots of questions
    • Identify areas for self-study
  • First month
    • Be ready to be someone else’s onboarding buddy
    • Articulate some personal goals for the next few months
    • Decide which of the teams’ areas of work is most interesting and move toward it
    • Actively contributing to a project
    • Has done a demo on behalf of their team, to the other teams
    • Gives feedback on the new-starter process
  • First year
    • Is setting own goals and tracking progress effectively

Antipatterns

New starter antipatterns

  • Not enough time spent with the starter:
    • “Here’s the wiki”
    • “Go and look at this and come back if you have any questions”
    • Being thrown in at the deep end
  • Mandatory Training overload
  • No code/commits in “live”
  • Not making enough time and energy for the starter:
    • Everyone is too busy to interrupt
    • Cynical/negative colleagues
  • “Need to know” access to accounts
  • Not ensuring that people who have responsibilites toward a new starter are actually able do them
    • Untrained/inexperienced buddies
    • Being overpowered/forced to learn at someone else’s pace

That last one is very important - there must be support and training for the people in the roles outlined above otherwise it will be bad for everyone.

Summary

We felt positive at the end of this meeting. We will be using this as a basis for how we treat new starters.

I would absolutely appreciate your advice and insights on how we can make it better.

New starters due soon and we’re super-excited about it!

Addenda

I received some excellent feedback to this post - thanks to everyone who read and shared. First of all, I need to credit some colleagues for their help: Thom Rik Martin Alex Owain Andrea Jade, Eric and Dario.

Specific pieces of advice which might be helpful:

  • I think that there’s an important anti-pattern to avoid: do too much for the new starter to avoid bridle him when they want to prove they’re good for the job.
  • The “Team Buddy” need to be careful not to be too intrusive and not to break-down the work down to the smallest detail. (thanks Eric Saint-Etienne)
  • Consider how long the new starter should be given to solve some problem independently. Don’t jump in too soon or leave it too long. Seen errors in both directions. (thanks Stuart)