Onboarding a new team member

I know someone who had recently gone through a very traumatic experience of joining a new team. Although he considers himself a really tough guy, who is not easily scared by challenge, within his first few days he had immediately taken the decision to quit at all costs - he did all he could to quickly learn the technologies and understand the environment, he simply believed that the team he was in was SEVERELY lacking in communication. Too bad: big trauma for the poor guy, big loss of time and money for the organization, all could have been prevented with some communication.

Here is some advice to properly handle a new on-boarder.

1) tell him/her in advance what technologies he will be working on. Since normally it takes minimum one month before you can join the team, you can learn that stuff at home and reduce the initial sense of "fremdheit" (alienation, alienness, disorientation.... in Italian we say "spaesamento", which is "feeling you have when you leave your village (paese) and enter into foreign territory)

2) since day one, spend regularly time (say minimum 30 minutes a day) talking and mentoring the new guy

3) invite often the new guy to participate in the resolution of a problem on the actual applications you are developing/maintaining - nothing better than "learning in action".... later he can read the documents, he will understand them much better when he can attach them to some living application he has seen before.

4) avoid by all means to assign tasks by email/chat. Talk to the guy to explain him the task, and answer to all his questions, make him very clear that communication is open at all time and he is very welcome to ask questions

5) give the new guy a "play environment" (ideally a VM or docker container) where he can experiment without fear of breaking the existing code

6) don't make the poor guy go through the pain of applying himself for all the rights he need to access the different environments. All this account creation and rights is an activity that should be started BEFORE the guy arrives. It's painful, it's boring, in some large organizations it means using half a dozen tools and clicking like crazy.

7) even if everybody is very busy, find the time to say good morning, how are you feeling, etc

8) document, in a written form, the requirements you give to the guy. You won't believe how much still today people believe that you can actually work on something like "please write me the tests on this application" without even giving the specifications, without having any javadoc, without even documenting the DB structure.... and sometimes they don't even say "please"

9) make sure that the guy knows BEFORE JOINING what exactly is expected from him

10) if the guy gives explicit signs of being uneasy, don't ignore them!

And remember, you you think something (requirements, implementation details) is reckoned not being worth to be written, then most likely it's not even worth to be implemented.

Even if all this sounds simply common sense, you won't believe how multi-million projects still rely on a "swim or sink" approach - maybe someone particularly macho is even happy if you sink.

Wonderful (?!) pictures of military training available here http://uk.businessinsider.com/insane-military-training-exercises-around-the-world-2015-2/#south-korean-special-warfare-trainees-are-covering-themselves-with-snow-here-to-help-strengthen-both-physical-power-and-psychological-fortitude-8 , but remember, IT requires you to be smart and knowledgeable, not to be a hero.