How we're building our remote culture as we build Slite

I recently attended a meetup of CTOs of small and larger startups. When asked about our biggest challenge, we were all aligned: hiring the right people. Then, when asked about remote work, I was the only one open to building a distributed team.

At first, I couldn't reconcile the fact that one of our biggest challenges as CTOs is recruiting and yet I was the only one open to hiring remote developers. Then, I started to get why:

• Even in the tech sector, prone to be open to new modes of management, hiring remote employees remains daunting for many reasons.
• There's a lot that's been written about working as a distributed team but very little that's been said about building one: hiring the right people, onboarding them the right way and figuring out your balance as a team.
• Bottom line, when you're the CTO of a < 10 people startup, it's tough to find tangible advice on where and how to start on this subject.

At Slite, we're still figuring it out but hope our short experience of building a distributed team can provide some concrete tips and at least encourage people to ask themselves the right questions around this topic.

Taking the leap: to remote or not to be?

When we started out, Chris and I were in different cities for the first few months. By the time we started working in the same offices, we hired a third team member, Arnaud, our first full-remote developer. What it proved was that you don't need to be physically together to innovate, work efficiently, and build team culture.

But it's not so obvious: launching a startup means having to think of 10000 things at the same time. Managing a distributed team feels like adding on top of that list. Starting out distributed meant that we naturally grew open to the idea of remote. It's a mindset you must choose to have from the very beginning because it influences your entire team culture.

1.5 years into this venture, we're a team of 9, of which 5 developers across three continents, and happy to share what we're learning and asking ourselves daily about hiring remote, onboarding, and day to day teamwork as a distributed team. While this article is specifically about our experience hiring and working remote developers, the takeaways apply for all positions.

Hiring: self-management, communication, and reporting skills are as important as technical skills

We've learned that hiring remote requires a specific framework if it's going to work long-term. Above all, we're very transparent about expecting a specific work ethic and management, on top of technical skills, from the developers we hire in remote:

• On point self-management: they basically need to micro-manage themselves.
• Excellent reporting skills: they must be prepared to show how well they micro-manage themselves and clearly report on tasks to establish trust.
• They must be experienced developers: the autonomy that comes with expertise is crucial for the first points to be true.
• They must have experienced remote before even if shortly or punctually: our second full-time remote developer, Alex, had been remote for one month in his previous job, enjoyed it and started actively looking for the opportunity to be remote full-time.
• It must be clearly stated in their contracts: to avoid miscommunication with other team members, we've always made sure there are specific clauses in remote contracts.

Onboarding: get new hires on board quickly to make them feel part of the product team

Onboarding a new hire is hard so imagine when it's someone you'll be seeing more virtually than physically. The importance of making someone feel they have their part to play in the product and team as quickly as possible is tripled. Here are some of the things we've progressively implemented in our onboarding process:

• Avoid the "Full Stack Developer" myth: even as a small team, ensure everyone on your tech team has a specific role and that you hire for specific roles. It makes it easier to divide tasks and spread product ownership when someone new joins the team.
• Work in the same offices in the first week as if you're working distributed: it makes it easier to set everything up and work out the first kinks.
• "First day = first code deployed" policy: every new hire deploys their first code on their first day at Slite. It creates an immediate feeling of autonomy.
• See each other regularly: the frequency depends on how far the team member is but we make sure they come to the Slite HQ at least once every two months.

Management: solving organizational issues early on versus reacting to what happens at the office

Finally, the day-to-day management: the part where most fears about remote teams stem. How do you trust your employees? How do you ensure goals are hit? How do you make sure there's team cohesion?

Often, we've found these fears can be turned into opportunities that'll benefit your team in the long run:

• Building team cohesion: as I mentioned earlier, employees need to feel they have their role to play in the team. Deciding to build a distributed team forces everyone to define their role and their scope of work. For future hires, an interview feedback template can help.
• Reaching goals: a lot of times in startups, goals are unclear, unplanned and unreached. Overlaps and inefficiencies are more likely if your team isn't together physically. Those risks force you to evaluate frequent goals (bi-weekly for us), write up short and long-term roadmaps.
• Efficient communication: cohesive teamwork in a distributed team depends on clear reporting and respecting each other's focus. Nailing communication etiquette early on is a strength for the employee (learning the art of good reporting) and for the manager (avoiding micro-management).
• Ensuring your team members are growing and feeling fulfilled in their work: when you're in the same office it's easier to avoid having one-on-one conversations to address feelings of stress or unhappiness at work. If they're far, those feelings will be exacerbated and you'll risk losing some of your best talents. We hold regular one-on-ones every three weeks with remote and non-remote team members to talk about things that are not working and those that are.
• Creating a unique team culture: work is a huge part of social life and being in an office is full of social events from the coffee machine to lunches to after work drinks. It can feel isolating for those who are not there. We tried having an appear.in social room and using House Party to fill that distance but it hasn't worked for us. What has worked is starting the day with a stand-up meeting: it can vary from taking 10 minutes to taking 30 minutes. The idea is to report, talk about work issues, socialize and start off the day as a team. Slack also helps in small but meaningful ways: our #random channel is often most animated by the remote team members who share interesting and funny articles.

Go for it

When I said earlier that choosing to build a distributed team will impact all your future organizational decisions, I wasn't exaggerating. Our work rhythm and etiquette (few meetings, respect of each other's focus, efficient 1-1 meetings, smart reporting...) derive from reflecting on "how do we make this distributed team thing work?" So far, they've had amazing benefits on the entire team: remote and not.

I'll leave you off with the acknowledgment that it's definitely a leap of faith and requires you allocate time to reflect on issues that might not get you as excited as building your next cool feature. Still, I encourage you to take that leap: you'll hire the best talent and you'll fix important issues early on.