How to bring new talent up to speed

February 14, 2017 | by Rodolfo Ortiz

In Human Capital, developers

 Imagine the time it takes to explain to a new employee the details of the project she'll be working on. Now think about bringing 2 or 4 or 6 more new developers up to speed –all at different times. The time can quickly add up to weeks.

Bringing new talent up to speed can be a time consuming process.

There are some things I like to do that help transfer knowledge to new team members.

First, I like to record a 30-60 minute video of how the software being developed works. This can include a tour of the functioning application, a quick explanation of the domain and the business rules, as well as a review of how the code is structured. This only needs to be recorded once and the new talent can watch it even multiple times to make sure they understand the application they'll be working on.

Second, keep a wiki with documentation on how to setup a development environment, code standards, best coding practices, help on troubleshooting common errors in the application, general information about who the stakeholders are, and information about other team members (cellphones, birthdays, work anniversaries). Make sure all the new talent is involved in keeping the wiki up to date (make it a team effort).

Give new talent the tools to adapt to the way you manage projects

Third, the application should be able to run by just downloading it from github/bitbucket or whatever source control you use and hitting F5 in Visual Studio. I know this is not always the case, but you should aim for this. If it is not possible, make sure any extra steps needed are well documented in the wiki and can be followed without any extra direction.

Fourth, ask new team members to listen to design and technical conversations so that they can get acquainted with what's going on in the application.

Finally, rely on continuous integration. New talent will most likely break the build, and what's better than having an automated build let you know when that happens and avoid the breaking change from propagating to other developers? After all, that's what continuous integration is for: to catch when someone breaks the build, not to avoid it.