How to onboard a new member to a dev team
For manager and team:
- The ultimate goal should be to get the new member from discussing “how do I do this” to “how do we do this”
- Have a plan prepared as to:
- In week one, you will do this…
- In week two, you will do this…
- In month one, you will do this…
- even better if this is included in JD as many companies do.
- It’s the manager/lead’s responsibility to make sure that there is one person assigned in the team whose job it is to get the new member to pace. You can keep rotating the person based on the area of knowledge or availability or just do a round-robin to not overload any one person.
- Have a person pair program till a change is pushed out to the prod for a while.
- In sprint planning assign zero story points to the new person for a sprint or two.
- Have a dev checklist (what to do and what access to have)
- If the team works on multiple projects, then for at least a month just focus on one.
- The litmus test for the effectiveness of the project’s documentation is how quickly a new developer can get their development environment set up and running your application.
- Remember that too much info can be overwhelming, so find the right pace and encourage repetition - repeated sharing of information. That is why recorded videos are great.
- Manager can watch knowledge transfer (KT) videos and note how the production value of such videos can be increased. (Only if time and budget allow and don’t add extra work to the team.)
- Bonus: if the team has a way of creating structured knowledge transfer videos.
For the new person:
- Get the dev env ready
- Run test cases. And write test cases. It’s a good way to understand what the code does without breaking anything.
- Make notes to understand the system and ask stupid questions to get more info.
- Explain what they have learned to the team so that they would know how clear the understanding is and fill in the missing blanks (reverse KT).
- Have new members go through docs and update the missing pieces and outdated pieces. They need not create new docs necessarily
- Understand the customer requirements, management metrics and KPIs (number of jobs processed), dev metrics (logs), etc.
- Understand the entry points of the system and go deeper into the codebase from it.
- Watch KT videos
- Understand the dev process and release process
- Update documents that are outdated
P.S. Management should realise that adding new members to a team reduces the team’s delivery rate/development speed (initially), and after a certain point no matter how many people you add you won’t increase the speed. (That number would depend on the team though)
What did I miss? What did I get wrong?
If you liked this post then please share with your friends! Click here to share on Whatsapp. Please subscribe to my newsletter if you want to get my posts in your inbox.