How to properly onboard your new developers

Growing up#

So you need to grow your tech team, in order to sustain your product's growth. You fire up your industry connections and HR department and you end up hiring a couple of developers every month. Fantastic!

But after a short while, you realize your team's output is far from what you think it should be. Sometimes you actually feel it's worse than when you were only a bunch.

Of course, you begin optimizing the hiring process. You scold the HR team, and you question the decision makers, and start to wonder how is it that all your competitors claim to have the top 2% of engineering talent on the market, because it's obviously not true.

You've gone through rigorous processes and paid 115% of the market rate, yet you still didn't get what you needed. How could they?

Well, a less known secret in the industry is that building your team is by far the most difficult thing you'll do in your company. More difficult than strategy, sales, marketing or handling unsatisfied investors.

What are some key insights that could help you build a high performance team?

Onboarding#

The most critical moments are of course, the first 2 weeks. Do you have a plan in place? It doesn't really matter because the process starts way before the employee onboarding begins, with your company's culture.

Forget about what your new employees were or they did before. Consider them a clean slate, ready to be molded, ready to soak in all the strengths and weaknesses that you've accumulated since you've started.

This is why some engineers will look really strong in some teams and just average in other teams.

How can you make sure you build the right culture? Or what is this thing called 'culture'? It means different things for different teams. In engineering teams -- it's never about competition with each other. Like how it is in sales teams, or in marketing teams.

In engineering teams good culture always revolves around how teams communicate and share knowledge.

The more you can get your team to have the same knowledge, the more predictable they become. The more happier, the more productive.

So how can you get them to share more knowledge, communicate and collaborate better?#

It's a question nobody can answer for you. Everything you do always has to be done in the context of your team, product, business, skills and so on.

But here's a couple of hints.

Start with the interview.#

Instead of asking what they did and achieved in the past, which is a thing they could always tell lies about, or have them spend 3 hours doing algorithms on a whiteboard, ask them:

• what are the last 3 technical books you've read?
• what's the last open source software you've read or contributed to, and what did you learn from it?
• how many words were in the last technical documentation piece you've written? did you enjoy it?
• are diagrams necessary for a simple 3-tier architecture for a web app?
• do you prefer face to face or offline knowledge sharing?
• would you rather write your documentation in your code or have it somewhere else? why?
• what did you learn from being in a small team and what did you learn from being in a large team?

The answers will answer the question: should I hire this person?

The answers will also set expectations unconsciously, so when you do make the offer, it will be weighed down when they consider whether to say yes or no. You might dodge some bullets just by doing that.

Offer lots of reading material when onboarding them.#

This is proper onboarding -- making sure they know what they're getting into, and arming them with the knowledge they need to be accepted and thrive in this new community.

Just getting their new MacBook Pro, 4k screen, and copied note written by CEO and being told to dive into code and figure stuff out on their own is not enough. Mainly because it's so impersonal, has no history, has no human touch to it. Nobody read through 50k lines of code and said: "oh my gosh what a f**king beautiful piece of information. I will stick to this team forever"

Providing lots of reading material sets the expectation that this is the company's culture -- a culture of learning, sharing and collaboration. This signals from afar and without any type of confusion: ***"this team goes out of their way to make sure everybody is treated the same, have the same knowledge, same hardships and the same opportunities -- I want to be here, contribute and benefit from our success"

How, we really hope that you will know how to properly onboard your new developers*! And also, I hope I've given you enough value to consider the following pitch.*

How can Archbee help with your software engineering team?#

Archbee Wiki provides an easy to adopt solution for internal knowledge sharing that is specifically tailored to software development teams.

We've studied many teams and their workflows, we've identified common use cases and coded them into our software's DNA.

When your team picks Archbee, you are guaranteed to see upsides like team happiness, synergy and productivity within less than 3 months of using our product.

Here are for you two extremely helpful read recommendation:

1. How to Craft an Excellent Welcome to the Team Email
2. 15 Inspirational Welcome Messages for Your New Employees

FAQ#