Dealing with your first hire in a distributed team
Captain's log, stardate d30.y36/AB
In our last blog entry, we described our first day with our new hire, Javi. Two weeks in, and the whole team has felt the boost of having a new employee at MarsBased: the company is producing more, he's learning while having fun, and so are we.
However, a new employee brings in a whole set of risks that need to be addressed when running your own company. One of them is the integration in the team, and this is what this entry is about.
We're talking about our first employee here. Serious business.
After having read a lot of literature on how to deal with this situation, we found these tips worth sharing:
Day to day
When introducing a new hire to your company, you need to make sure he feels integrated as soon as possible, especially in small companies. And even more so if he/she is your very first hire.
The most valuable piece of advice here is work naturally. 37Signals' book Remote: No Office Required strongly advises companies to continue working like they did before the employee was hired. Changing your behaviour will look like unnatural and will create awkward situations.
Be yourselves while making him part of team decisions, not leaving him out of meetings, and showing him everything is there to learn. Obviously, you'll be spending some time teaching him all that stuff, but consider this as an investment.
On the other hand, terms like "family" or "friends" should be avoided. After all, this is a business relationship. Experts tend to favour the usage of expressions such as "we're a team", instead. Or else, no mentioning of this at all. This blog post explains the situation very well.
The bottom line here is: show, don't tell. Your actions will be more valuable than your words.
Distributed teams meet seldom. In these companies, the limits of your duties and/or responsibilities are sometimes unclear. Especially if the introduction to the company isn't done right.
This issue can be avoided by introducing the team accordingly, and telling the new hire clearly what you expect from him or her.
For instance, when hiring a new programmer, do not send him into coding without explaining what's your coding style, which methodologies do you use, whether you do pair programming or not, which technologies do you expect him to know, the frequency of your commits, what additional tasks will he have to handle (devops, code refactoring, QA, performance tests, etc.) and so on.
In these situations, it is better to tell them what they are expected to do according to their role, but that they set the limits to their involvement with the company. That is: programmers deal with the development of the apps, but they have the option of getting involved with social media, writing in the blog, participating in the sales processes, improving internal organizational processes, preparing workshops for events, etc.
Besides that, in small teams, the figure of the leader - bosses who work by your side - is enforced, instead of the classical boss enclosed in his own office. An almost-flat hierarchy helps to ease this process.
Remote: No Office Required is one of our favourite books and a mandatory read for distributed teams.
Communication is key
Spending half a day listing all the communication tools you use as a team, and how to use them, is never a waste of time. On the contrary: set the rules now, and forget about it.
At MarsBased we use Basecamp for internal discussion that needs to be recorded. Then we use Slack for real-time communication and having the water-cooler effect of always having someone to talk to.
We hardly ever email each other save for communications with third parties.
In conclusion, it is very important to present all the tools to the new hire, as well as the frequency of use and some rules that need to be met to ensure a fluid & correct communication.
Get-togethers, for work or leisure, are necessary for all remote working companies.
Imagine a team that never sees each other's faces save for video calls. As hard as they might try, there's a great chance they will not bond as much as a normal company due to the lack of physical connection.
In distributed teams, not everybody lives in the same city. In some cases, you might even have an employee in the other side of the globe, that might probably feel a little left out if not dealt with properly.
Get-togethers help to bridge that gap. They create a sense of bonding that should be enforced regularly, depending on the maturity and budget of the company.
On the other hand, get-togethers for working will also boost productivity for a day. Instead of everyone working separately, try getting the team together in the same room for a day. This will boost creativity and create an exciting vibe to get more stuff done before the session ends.
Lastly, get-togethers on the new employee's first day are also critical to help to ease the introduction to the rest of the crew. He or she will want to meet the bosses & co-workers on the first day.
From the company side, that shows appreciation and interest in the new employee. Not only will this help him/her gelling in with the rest of the crew, but they can all get to know one another in a more natural way.
Is your company a distributed team as well? Feel free to share your tips and experiences with us in the comments below!