Teams change and Software Development Teams are no different. When this change is about bringing someone new to the team, we call this process an on-boarding. This process involves tasks to integrate this person to the team and the project, but misconceptions and unrealistic expectations make this process challenging for the new person and for the team itself. 

Belief newcomers manage alone a successful on-boarding creates these misconceptions. Some teams spend time with the new person presenting topics and instructions; but deep down the belief remains. “We need a fast learner, are you one?”, “We are in stressful times; we will need you to be productive right away,” “Here is the code and docs, ping me if you have any doubt,” and so on; these phrases reveal who in fact is responsible for a successful on-boarding.

A view which promotes certain indoctrination must occur before new teammates can help. An on-boarding period, “He’ll be on-boarding next two weeks,” is also a bad sign; it makes people ignore the newcomer for the next two weeks. A waste for a good opportunity for the team.

The team is accountable for the on-boarding

A cascade effect happens when the team assumes an accountable position. Documentation, if exists, needs to be effective to explain how the application works and why it works like that. Tools for automation need a “—help” option. Understanding of domain concepts need to be clear to all. And the team must ensure everyone can explain the project to anyone.

Software Development Teams need to develop teaching capabilities. The problems they solve as a group need to be communicated in different levels of abstraction and details. Project progress, challenges, negotiations with other teams, and finally the on-boarding of new members will benefit if the team knows how to teach. And the best way to learn and perfect these capabilities is to practice them.

New team member collaboration from start

 Someone new paying attention to what the team has to teach is a golden opportunity. Did this person understood what this project is about in the first few hours? Can any team member answer a basic question about the project? Commitment to understand the project is an excellent counter measure to the Curse of Knowledge; forgetting how is to not know something once you already know it. Here is an incomplete list of things a new person on the team can help from start:

  • Create a safe environment for learning
  • Review the software architecture
  • Train business analysts and team members to explain the business
  • Review documentation
  • Domain design
  • Identify gaps on path to production knowledge and process
  • Improve automation tools
  • Improve secret sharing and revocation
  • Exercise presentation skills (creating and presenting)
  • Review tests and pipeline for clarity

Setting it up

To work the new person needs a safe environment on which to ask questions and know, as simple these might be, are expected. Creating the safe environment is crucial for this to work, if someone feels insecure they will refrain from asking questions, communicate failure in understanding, and other behaviors that hinder a successful on-boarding.

Assessments on the on-boarding process should be done through measuring outcomes and not pure definition know ledge. Often on-boarding spreadsheets list topics such as “Know what is X,” “Know what is Y,” “Do Z,” “Do W,”  and variations. These measurements can be improved by assessing abilities and not just definitions and repetitions. Examples “Can deploy head to production.” “Can destroy and recreate local environment.” Abilities are more decoupled from tools, last longer, and can drive the improvements the team want to focus on.

To ensure team members perform all tasks during the on-boarding is good to track these tasks and rotate individuals on each on-boarding. Always bring the newest on the team to help.