I love talking to impressive people.

Like Job van der Voort, who might be even more kind than he is impressive.

And that’s saying a lot, because Job has quite the resume.

He’s the Co-Founder and CEO of Remote, which is a $3 billion global HR platform that helps teams around the world manage payroll, taxes and compliance.

Prior to starting Remote, Job was the VP of Product at GitLab, the world’s largest all-remote company. While at GitLab, he helped the company hire talent in 67 different countries, grow from 5 people to over 450, and reach a valuation of over $1 billion dollars.

Job is an expert on all things remote, including scaling remote-first startups, building remote culture, and working as a distributed team. So I sat down with him to talk about his experience building Remote.

We also talk about:

• Why you should treat your company like a product.

• Why managers should always stay close to the actual work.

• Why Job lets Remote’s engineering teams work on whatever they want.

• How Remote built a culture of human connection on its fully remote team.

You can listen to our full conversation on Almanac’s YouTube channel, or you can read it below.

Enjoy.

Where did the idea for Remote come from and what made helping companies hire global talent an interesting problem to solve?

I used to work at GitLab, which was a fully remote company since day one, and I learned a lot there. The way we built that company was clearly the future. We could hire the best person we could find–regardless of where they lived–we didn’t have an office, we worked very transparently, and we gave a lot of freedom to individuals. Everybody loved that, and it also worked really well for the organization.

The one thing that didn’t work well was how we’d pay people–who lived in different countries–while remaining compliant. We learned pretty quickly that you can’t hire everybody as a contractor and just wire them money. So we had to solve that problem, but we couldn’t find any good solutions for it.

There were plenty of solutions out there, but they were expensive, bureaucratic, and not very user friendly. So I thought, this model (remote) works so incredibly well that it’s obviously going to be the future, but it will only be the future if we can solve this crucial little bit. So that’s where the idea came from for Remote.

I was actually planning to leave GitLab after one year to start my own company, but I stayed there for five years because the company grew so fast. After five years, I was like, “now it’s time. I have a good idea. I should try this new thing.”

Are there any values that worked well at GitLab that haven’t worked so well at Remote?

Not particularly values, but we certainly do things differently at Remote than we did at GitLab. It really comes from the personalities of the Founders and CEOs. Sid is a really great CEO, and he built GitLab in a very particular way. At Remote, we do some of the things the same way he does, and other things we don’t.

Our documentation processes are somewhat different–like how we use our handbook. Personally, I’m not very good at strictly following rules and processes. So you will find that Remote’s rules and processes are much more relaxed. I don’t mind if many people use many different agenda formats for meetings. I generally prefer one in particular, but I don’t really mind if others use their own. I also don’t really mind it if people don’t always contribute to the handbook–I’d rather we use it when we feel like it is most necessary instead of always feeling forced to use it.

In other ways we have a different company culture. We created different values from the start, which are kindness, ownership, excellence, transparency, and ambition. Those are very different from the ones at GitLab. But I think the essence is almost the same, which is that you want to generally be good to each other. You want to give individuals a lot of trust so they can take freedom in their work. And you want to be kind in your interpretation of other people’s words and actions. When you combine those things, they make for a really excellent remote working culture. Both GitLab and Remote align themselves well with those values really clearly.

What are some management trapdoors that you’ve fallen into that haven’t helped you to become a better manager?

The most important one took me several years to realize. It pertains to almost any manager, and it’s that you can’t be a full-time manager. What I mean by that is: you always have to stay close to the actual work. As soon as you create too much distance between yourself and the actual work, you become a worse manager because you don’t have sufficient empathy. You can’t lead strategically, because you’re just managing the people as if they are resources rather than working together with them to achieve a particular outcome.

I’ve personally experienced this a lot over the years–every time I took too much distance, I became less empathetic for the problem or I made decisions that I wouldn’t normally have made. I feel very strongly about this…if you’re a manager of a lot of people, no matter how high up or how low in the organization you are, you should stay really close to the actual material–the products that you’re building, the service that you’re delivering, and the sales that you are doing. And you should attend sales calls.

If you’re an engineering manager, maybe you don’t have to write code, but you sure as hell should know exactly what people are doing and how they are doing it. And you should have a look at the code every once in a while. At the end of the day, everybody should be working on the work–the product, the service, or the company. They shouldn’t just be working on the people–I don’t think that’s productive. That’s a really specific one that I feel stronger and stronger about almost every day.

How have you given people autonomy and freedom at Remote and how has that contributed to the success you’ve seen today?

One of the most shocking things is that we don’t really use any agile practices on our engineering teams. We don’t do sprints, we don’t do planning, and we don’t do retrospectives. We give individual teams the freedom to run however they want. Because for the most part, people just pick up work, do it, and deliver it.

We give them sufficient autonomy to also decide together what should be prioritized in what way. Now, some things must be delivered in a certain period of time, but for other things, we give them the freedom to do whatever they want, however they want. And that works really well for us.

You’ve talked about the importance of connecting together as humans on a deep level. Tactically, what does that look like at Remote?

First off, we’ve created this culture where people are free to connect with each other. It’s a safe place. Kindness is our first value and I often translate it as, “we don’t want any assholes.” That’s a performance thing for us–you can’t be unkind to each other, period. There’s no alternative and we will fire you if you are not able to figure that out. So that helps us create an atmosphere where it becomes very easy to connect with each other.

We also create opportunities for people to bump into each other, like through Slack pods. And then for teams that really want it, they might meet up in person. But I don’t really see that as an important pillar of how we help people bond. It’s an optional one that many people opt into.

For the most part, we just make the threshold to connect with each other really low. That’s the most important thing. Now, we do see a lot of colleagues looking each other up if they travel, and sometimes they travel on purpose to meet with their colleagues. Our people always end up coming together if we have a meeting or an event of some sort.

The most important thing is that we’ve created a somewhat safe environment, and then we’ve lowered the barrier for connecting with each other, so our people always sort themselves out.

What do you think separates good teams from great teams on the internet?

It’s important to do your work together, and then do the performance and private stuff one-on-one. There should be a harsh separation between the two, so that if you have a one-on-one with your report or with your manager, then it shouldn’t be about the work. It should be about the career, the person, the circumstances, or whatever else–anything but about the work itself.

If you’re able to do that, then you can do all this really great work out in the open with your team, which makes work much more collaborative. So while my advice doesn’t directly make for a great team or a great manager, it’s one of the clearest signs that you’re working really well. The rest is just to be a team that is continuously over communicating. If you’re continuously over communicating, then you are solving all the potential problems you could possibly have.

You talk about how remote work can help people get jobs that literally change their lives. How has that played out at Remote and in your life as well?

The people at Remote live all over the world. I don’t personally know where they live, but I do get a lot of messages from them saying that they live lives that were previously unattainable to them. I also get these types of messages from the people that we employ as an employer of record, which is amazing.

Personally, I’m a father of two small kids that I’m raising together with my wife. Both my kids were born prematurely, so they spent a really long time in the hospital, which was not fun. Now, maybe it wasn’t the best thing to do with two really small kids, but I was able to build Remote while they were really young and we were in the middle of the pandemic. The company was taking off, and I was able to structure my life in a way that made me maximally available to my family, while also being able to be ambitious. That was important to me. And, when my kids were born, we were living far away from my parents. We wanted to be closer to them, so we moved. To me, that was really impactful and very important.

What started to keep you awake at night after you found product market fit? What stopped keeping you awake?

I am a person who sleeps really well. So there’s very few things that really keep me up at night. The day to day doesn’t really get to my head, but I do worry about inequality and our ability to continue driving the other direction. Remote is an active employer of record in over 80 countries. There are ~200 countries in the world, and many of these countries are still really hard to get to. I get so many messages on LinkedIn and Twitter from people who say they’d love to be able to earn even a minimum wage in a Western country, but they’re not able to. So that’s a really big challenge.

We designed our pricing so that employers wouldn’t be discouraged from hiring people with low wages or from giving people raises, which traditionally, was very much the case in this industry. So that keeps me up at night. You know, the questions of, can we be the employer of record in all those countries? How can we actually reach all those people? How can we actually make sure that employers will find those people and hire those people? And then make sure that there’s not some other force acting against that?

Right now, we solve part of the puzzle, but there are a lot of components to solve here. And they’re really complex.

What advice do you have for other founders who are looking to start their first remote company?

Treat your company as a product. So, you build your product by releasing a version, and then you learn from your users and your customers. You figure out what do next, how to improve it, where you want to get to, and at a certain point, it all starts to work. But no matter what point you get to, you will always have to iterate on it.

We don’t have a template for a remote company yet–a vanilla template doesn’t exist. There are handbooks from Gitlab, Remote, and Almanac out there that you can copy, but these handbooks are very specific to these three companies. There are so little templates out there for remote companies, so yours will probably be unique. You’ll have to continuously iterate on it and look for the things that are broken. Try to fix them, try to find solutions. Try to build up new features to improve the things.

We did a lot of things at GitLab that we thought were crucial to running the company, but it turned out that they weren’t. We either don’t do them at all at Remote, or we do them in different ways, and we turned out to be just fine. So there’s no template to building a remote company. Instead, you should treat your company like a product and iterate on it.