How not to onboard a new developer

Pain begets pain

When you joined this company, you had to build your laptop out of a pile of electrons while the senior engineer told your mother over the phone how slow you were.

The new hire needs to know two things:

• that you aim for her to have roughly the same experience

• the job interview is not over

Giving her a fresh computer and asking her to get the development environment running is a final test. Her reputation initializes based on how she navigates the out-of-date wiki page and an unfamiliar org chart to find a friendly developer to help. Because you certainly wouldn’t be one of them.

After all, if new software engineers can show up with their environment ready to go, prepped like an operating room is for a surgeon, then they might be able to do their job. And then they would bring all those new ideas and skills to the table. And then you might not be as valued. To keep your local currency high, you need to change the exchange rate.

Or just don’t accept their currency at all. Once they navigate the how-to guides, then humbly offer their Official First Suggestion, make sure you shoot it down with force. Listen, then spend twice the time they spoke telling them how Your Company is Different, has Tried it Before, and It Will Not Work. Don’t end the chat by encouraging other suggestions or asking questions. The more they rise, the more you could fall.

Small details about the software: how to build it, how to support it, what it is, what it does, should be slowly revealed to new hires. Two good times to tell them an important fact about the software are:

• immediately after they cause a problem because they didn’t know it

• when you are absolutely forced to do so

So keep your secrets.

Also, don’t forget to send a welcome email announcing the new staff member to the rest of the team.