Ep. #44, Building Opinionated Software with Job van der Voort of Remote

Grant Miller: All right. Job, thank you so much for joining.

Job van der Voort: Thanks for having me Grant.

Grant: So I'd love to just dive right in. Tell us how you got into enterprise software?

Job: Yeah, sure. It's a bit of a winding road for me.

I have a background in neuroscience, so I worked as a scientist for a number of years.

Grant: Cool.

Job: And I was about to start my PhD when I discovered Hacker News and the world of startups and I decided that being generally quite impatient, I should try to get into that.

It seemed much more appealing to run my own company than to just work as a scientist where you're always reporting to some management.

And so I did a bunch of things.

I tried to start my own startup, ran out of money and eventually ended up as a software engineer at a Dutch company building software for the Dutch government.

Which it was quite extreme because I went from not doing any software engineering to doing the kind of stuff that has a gazillion tests and separate companies that were validating our code before it went into production.

And shipping things into production required literally the CEO of that company to get a key, to open a box, in which box there was a USB key that had to be inserted into a particular computer at the same time with another USB key, and that was the only way to deploy particular changes that we were making.

Grant: Whoa.

Job: That was quite intense.

And at that job, so I worked on software that handled particular government things.

I worked on software that was used to create licenses and certificates like SSL certificates.

And at the job we used GitLab as source control, which was only open source at the time.

But one of my coworkers happened to be starting a company based on that and it was Sid.

And he left that company to say, I'm just going to focus on GitLab.

And he told me, "Job, if you ever consider doing something else, you should join me."

So a month later I left that job and I joined GitLab, which at the time was a company without any customers.

So yeah, that's really where my start was.

And of course, GitLab being an enterprise software company.

Grant: Wow. Okay. So you met Sid working at this, you were actually working for the government?

Job: Yeah. It was a company that their main contracts were all with the government.

They had a few other products, but yeah, their main contracts were with the Dutch government. Yeah.

Grant: Okay. And you were GitLab users just using the open source stuff.

And had Sid brought it in or how did they end up using GitLab at that point?

Job: I don't think he had, I think they were using GitLab and Sid was consulting to them as an engineer, not as a GitLab anything, he was literally just writing code in Ruby on Rails, just like I was.

And I think he was already there by the time I joined.

And then shortly after I joined, a few months later, he left and I left.

I was there for less than a year. This was a cool job though.

Grant: Cool. And then, I mean, so super early days of GitLab, I mean, this is obviously GitLab has grown a lot since then.

So talk about the start, talk about what were the insights and what were the challenges in those very early days?

Job: It was very interesting because GitLab itself is this open source project existed for several years already.

This was early 2014, I think. And GitLab existed since 2011.

And so we already knew we had a rough idea based on downloads with packages and such that there were about 100,000, if not more instances of GitLab live, and we assumed those were mostly organizations.

We also knew that there was a whole bunch of them that we would never see because we just saw the download that there was no active ping that we got from them.

So we had a good idea that there was a large install base and there was no enterprise product at the time.

And at first we thought, let's just make money on support. And we started to get inquiries once we had a business established.

Like, okay, we are large enterprise we use GitLab with a whole bunch of people and there's no way to support it.

And it was surprisingly hard to make good money on it but part of the fault was that we had no experience in building a business like this, and we had no idea how to charge it.

So one of the things that happened was that a Fortune 100 company, it was like a Fortune 10 company reached out and said, "We have this massive GitLab installation. And we run the open source version and we need some mixture features that are not in there right now."

And that's essentially what got us to start an enterprise addition for GitLab where we built, it was some SAML features at the time, to be able to help them and to be able to charge for that.

And I think we charged a ridiculously low amount, like $1000 a year for this massive enterprise installation.

I think since then that bill went up 1000 fold, if not more. But it was certainly interesting.

And looking back a ridiculous start, but it was also a good start because we basically had users, we had customers before we established a company because it was open source.

Grant: That's awesome. And I guess you were in the same city as Sid at that point or where were you?

Job: Yeah, so the company we were working at before was in Utrecht, which is in the Netherlands.

I was living quite far from there actually like an hour and a half by train, two hours on a bad day.

Grant: Oh wow.

Job: And so GitLab was founded by Sid and Dmitriy, and Dmitriy was in the Ukraine.

And other people that worked there were Marin who was in Serbia and Jacob who lived elsewhere in the Netherlands in Amsterdam.

Yeah. So we didn't have an office and we just worked remotely from day one, essentially.

Grant: Okay. So you were remote from day one. And what was your role when you first started?

Job: Yeah. I started as a surface engineer, which basically meant I do support, I write features and fix bugs and everything else.

I was very much interested in other things than that. Like I built a website at first.

Yeah. Our website was really terrible and so I renewed that. I redesigned it and built it myself.

And then over time I got more into like, what should we build?

And I just named myself a product manager and everybody was fine with that.

So I've been leading product since very early on at GitLab until I left.

Grant: That's funny. So a self proclaimed product title, and then just, it's almost like titles don't matter as much, it's what you do, right?

Job: Yeah. And I really liked that.

I think the first five or six people at GitLab, everybody was an engineer.

So we were just all enjoying GitLab as a product itself.

We were all contributing directly to it.

Everybody did everything. Everybody cared about everything. GitLab has been releasing new updates every single month on the 22nd of the month, a new version.

And we did that back then as well. And it was really a rally around that.

So one of the things I took on very early on was just writing that release post and making it a big deal every single month.

Like, "This is a new version of GitLab and this is why it's awesome."

But yeah, I really enjoyed it, at those early stages, I think, of any company, but at GitLab for sure, they were very exciting.

Grant: Okay. And so GitLab was part of Y Combinator at some point, right?

Job: Yeah. So the company was founded at the end of 2013, I joined early 2014 and then in early 2015, we went to Y Combinator.

So we went with the whole company, all its employees in a single house in Mountain View at the time that was nine people or eight people.

Yeah, we went through Y Combinator.

Grant: Oh, wow. So everybody moved to the valley for three months?

Job: Yeah. I left a little bit earlier because I was getting married at the end of the time there, but yeah, we all moved there.

We had one car, so we bought this one big old SUV and we put a GitLab logo on it.

Grant: That's amazing.

Job: And it was awesome. It was everything what you would expect from an early startup.

It was like a normal house in Mountain View, which I don't know, it's like the most boring place on the planet, which helps because we just put a giant table in the middle of the room, sat on there every single day with our laptops and just worked, just worked our asses off.

And it was pretty good. I think it was a pretty good way to try to go faster.

Grant: I love that. Okay. So you're in YC, when did you get that first kind of big customer?

So I guess even before that you were selling "support?"

Job: Yeah.

Grant: And what does that even mean at that stage, what are you actually selling people?

Job: Yeah. We'll start to getting into real deep enterprise stuff right now because GitLab primarily served as on-premise software.

So our customers, we had a cloud product, but especially early on, it was not very good because we wanted to use the same code base for both the cloud product as well as for the enterprise product, for the on-premise product.

And so what it means is that most of our customers, they were using GitLab by downloading a code.

Early on it was literally just a source code and then long instructions.

And then installing it on their own service and then managing that themselves.

And the reality is, is that most enterprises, what they have is they have nowadays almost everybody use Kubernetes, but at the time everybody had their own systems to deploy things.

Everybody had their own specific databases.

And GitLab itself it was not super simple because git happens on the file system.

So they have a lot of IO on the file system. And then you have a database which is heavily used.

And then you might have some sort of caching or something like Redis.

And so what we do as support is we would do various things.

Sometimes we would just help setting this up. Like, how do you set up like a scalable GitLab instance?

And this was continuously would involve because early on what we thought was scalable would quickly break and we would have to replace components.

And then for many enterprises they had built their own set up.

And so for example, they might have a chosen database.

They say, "Well GitLab uses PostgreSQL, but we have this mega MySQL cluster. And every application we use must use that. And if it doesn't use that, then we're just not going to work with you."

And so our job was either help them maintain that or help them get set up in that sense.

And because it was an open source project and because early on there was not really a company driving it, there was a large part of customers that essentially downloaded GitLab one day, installed it on their service, maybe started modifying it and then realized that they had a product that they could not update.

Because we would bring out regular updates and there might have been some sort of interest from individuals around the organization like, "Oh, this new version of GitLab looks really cool."

But they essentially forked GitLab and made this whole custom configuration.

And we would then help them migrate it to the master branch of GitLab and then still make it work for their setup.

So yeah, there were all sorts of tasks and it was interesting, but also incredibly challenging.

Grant: Oh, that's interesting.

And so it really was about like technical supportability of the product and how do you operate this thing, update it and then potentially extend it and bring it back, I'm assuming when you wanted to migrate or get back to the upstream version of GitLab they also had to like figure out how to keep some of those changes or something, right?

Job: Yeah. Yeah. This was a mega challenge.

And generally it wasn't really possible.

We early on took on a stance that we were not going to support those kind of customizations.

Yes, you can customize GitLab, you have access to the source code even in the enterprise version.

And we had a good API, so you can build things on top of that, but we didn't want to have many different forks be alive because that was going to be impossible to maintain.

And it's going to be very hard to continue to iterate on a product.

And early on, we also had the opinion that we wanted to build very opinionated software.

And to build opinionated software, you should be able to iterate quickly, make changes quickly and sometimes be a bit radical, which can be very difficult when you're selling to enterprises which tend to shy away from large changes.

But that's going to be impossible if you have multiple forks, or you have many scenarios that you have to support.

And given all of that, I think we still supported a lot.

As I said, we supported multiple databases for a very long time and that definitely was a really, really large challenge.

And then I think still today GitLab supports quite a few different ways of deploying it.

And that was also a really big challenge. So yeah, there was a lot to handle there.

Grant: Yeah.

And were you doing any sort of almost like customer success where you would help them adopt, eventually obviously GitLab became very DevOps focused, but were you doing that in the beginning and helping them understand how to set up these workflows and like, "Hey, here are the best practices of doing git and doing it this sort of GitLab way?

Job: We built the application in a way that was quite opinionated and that forced you to work in a particular way what we thought was preferable.

And for sure for a very long time, we thought we're going to make it very hard to do particular things that we think is not a good idea.

So of course we published content. At least early on, we wouldn't do the customer success thing.

I think later on that became much stronger, but it was very hard to maintain a super opinionated stance when you have very large enterprises asking you to essentially build the opposite thing.

And so what we ended up doing is basically creating a very opinionated, default state.

And then only if you really went out of your way to customize things or to switch different things out, then you could get into a state, which we thought was suboptimal or sometimes just bad, but it wasn't completely impossible.

I think the whole DevOps thing became much stronger because later on once we integrated CI, which was definitely not in the beginning, it was later in the evolution of GitLab, by the time we did that, and it really became one application with source code management and CI, then that became a much stronger thing.

And that part of the application, I think the opinion we had there, as in building opinionated software being this should be easy to do.

You shouldn't spend a lot of time integrating. I think that was very successful.

And successful to the point that no one really argued with that point, and that really helped.

Grant: Yeah.

And so let's return back to this early customer, the start of GitLab enterprise, you have all these users and somebody comes and says, "We need this very specific feature, some integration with a," you said SAML, was there a kind of internal discussion like, "Well, should we just open source this?"

How did that come about?

Job: Yeah, that's a good question. Actually, I think that until right when I left, it was like an ongoing discussion.

And not in the sense that it was unresolved it was more in that it's an evolving discussion.

So throughout the life cycle of GitLab, the life of GitLab, we had different times where the way we thought about what is community edition, so open source, and what is enterprise edition, what goes in each version, we had different philosophies around that and we changed a few times.

Actually I don't remember very well how we started, I think, early on what we said, essentially, if it's a feature that you typically need when you're 100 or more people using an instance of GitLab, then it's more likely to be enterprise.

Sometimes it's a bit of a gut feeling, it's like, is this an enterprisey feature then it should go into the enterprise edition.

What helped our position a lot was that even though our enterprise edition wasn't open source, the source code was available publicly.

So you can still read the source code it just doesn't have an open source license, which is a subtle, but very important difference.

On one end, it allowed our customers to also contribute changes to the enterprise edition.

So if you wanted to change our semi implementation, because you wanted to add something in particular, you could do that as long as you understand that this is not an open source license.

So that helped us a lot.

And then whenever something felt enterprisey and we brought it to the enterprise edition, then our enterprise customers would be happy and the open source community would not respond with like, "Why do you put this there?"

No, they would understand it. But sometimes we got it wrong.

And because we operated very publicly and our issue checker was fully public if we made the wrong decision, they call us out.

The open source community would call us out and then we would revert it.

I think if you have two versions like that, or multiple versions, it's much easier to start with, we're going to bring it to the more closed version, the paid for version.

And then if you've got to get pushback, I can bring it to the open source version.

You don't want to do that too much of course, because you're just going to look like a bad steward of the open source project.

But I think that is essentially how we started off separating the two. But it was for sure a challenge.

And then later we introduced more tiers and you have to think, what tier do I put things or does it go through open source?

And I think eventually we ended up with what is the buyer profile for getting a particular version of GitLab?

Whereas, the most expensive ultimate, that's a CFO that buys it or a CTO that buys it and these are the things that they tend to care about and so therefore these features need to be in that version.

And then the lower in the corporate hierarchy you go, open source features are very developer focused, whereas, the lowest tier are maybe engineering manager focused.

Grant: Yeah. That makes a lot more sense.

It kind of reminds me, I've said before that I think that the open source model that particularly, I think GitLab helped popularize is premium for the enterprise.

Where what you're doing is you're getting this adoption from all these different companies who, in my thesis being that I don't think that most of those companies want to use some freemium SaaS products because of all of the data and security challenges around adopting a premium SaaS product.

But if it's an open source thing, they can just deploy into a server, they will.

Does that match your experience from GitLab?

Job: Yeah, I think that is true, but I also think if you make something open source and easy to install and to run, and it's a nice thing that is gated mostly towards the developers, what you see is this, as they call it bottom up uptake, whereas individual developers in enterprises, instead of going through the whole procurement process, they just install it.

And we heard this so many times at GitLab where it was like, "We had a group of three developers that decided to open a GitLab instance, which is against the tool that we chose as an enterprise, but they liked it more."

And they just set it up and then started inviting their friends throughout their company and they started using it.

So it's not even that there's a decision being made about, should we use this or this is easier to install in a server, it's just that it would happen.

It would literally just happen.

Which is also some of the secrets of GitLab's growth is that many of the things that we wanted to introduce later on were features that we just shipped them along in GitLab.

So for example, GitLab CI, once we made it one application GitLab CI was fully integrated in GitLab.

So if you installed the update from one to the next, you would just have a CI tool now.

And so what we did is we just turned it on by default.

So if you upgrade it, you now had a CI suddenly there.

It was very easy to get started. It basically turned itself on, there was a little message that says something like, "You have CI now, just connect something to run your code, and now you can run."

And that helps a lot by just making it super easy to get started and then not getting stuck in that procurement process.

Grant: Yeah. That's interesting.

So it's like this concept of shadow IT, except just on the free, open source side, plus it being able to just use that reach that you have to bring in new functionality and expose that to folks along the way and continue to increase the usefulness?

Job: Yeah.

Grant: No, that's really smart.

And it's also just reflecting back on GitLab, just the idea that it was a project for three years plus before there was a company around it.

When people think about the trajectory of the company, no one thinks about all of the years of zero growth as an open source project and then very small growth as an early stage company, everyone thinks about the rocket ship at the end.

But there's so much work that's done up front and ground swell that has to be built it's hard for companies to start from day zero and say like, "Hey, we're going to do the GitLab thing," because there's a lot of work and foundation that's laid before you're really building a huge go-to-market org.

Job: Yeah. Yeah. It's very interesting.

It's funny to think back about those early days where I remember we were nine in total and we felt like a big company at the time.

Because it felt like our beginnings were so humble, we were just an open source project and now we had a company with nine people and it was very impressive.

And then I think we did a summit in Amsterdam and we were 40 in total.

And I was like, "Wow, this is a big company now that I'm working for. I should consider starting my own company because this is getting too big for me."

Yeah. It's very interesting to think about that. And for sure it helped us a lot.

I think one of the interesting things is that that early start where it was just an open source project that led to so much more business much later in the life, I remember, I think it was 2016 or so that a very large prospect came to us that said, "We've been running GitLab for many years."

And this was a company, a very large company, like an electronics company.

I don't even know exactly which, very large electronics company that essentially told us, "Yeah. We've been using GitLab for many years."

And we didn't know about it. At GitLab we had no idea. There was no ping coming into us.

They would just download the package or install it from source.

And they had their own version running and they were using heavily that for years.

And only until our enterprise versions got interesting enough, they thought, "Well, maybe we should contact them."

Grant: That's cool. Yeah.

I mean, all these seeds that are planted, right, that eventually you're able to harvest because you've added so much about value into the world.

I love that. And one thing you mentioned with CI and adding some of these other, I'll call them core features, because they're not necessarily these enterprisey features like SAML, but they're more like core functionality of the product, one thing I think I've noticed over time is maybe GitLab has bundled in some other open source tools and products alongside of it.

How were you deciding between bundling in something else that was open source versus building something from scratch?

Job: I think we want to be super pragmatic about it.

And there was a trend that we saw, which is that there were these really great open source tools that were hard to set up, but if everybody got them for free and you wouldn't have the need to set them up, then that would be a massive benefit to everybody.

That was basically our attitude. And that's why we integrated them.

We would just be redoing someone else's work if we wouldn't just bundle that.

So the decision was super easy to make in that sense.

I think CI in particular it started out because Dmitriy didn't want to maintain our Jenkins server.

That's why it started out. And then we figured out if we do this, this and that, then it can just be one application.

And at the time I remember people thought, well, it's going to be too heavy on the server.

And we just tried it and it was fine.

But yeah, for anything else building something from scratch when there's an established great open source tool that everybody likes, that's much easier.

And there really is nothing against it because this is a win-win for everybody.

The fact that we were using it means that we would end up contributing to it more, it would be used more.

So we were just being very pragmatic about it.

Grant: Yeah. And some examples, I think maybe is Prometheus bundled?

Job: Yeah.

Grant: Is there a chat solution bundled? I can't remember?

Job: Yeah. Yeah. So Prometheus, which is this monitoring solution, which is really, really nice.

It scales incredibly well.

So it made a lot of sense to not build our custom solution there and if you are able to bundle something open source and it just comes along, it saves everybody so much time.

So that was very easy. And Mattermost, being an open source Slack competitor, again, that made so much sense.

The fact that Slack was already then very dominant and there was basically no great competitor to it, and then here was this company, there was building this awesome, the same model as GitLab, awesome tool it basically did everything that Slack did and that if we were to bundle that and start to integrate that, it basically gave us a chat client that was automatically from the get-go integrated with GitLab.

That was really, really cool. And we believed in the idea of making it very easy to do things from chat so it was an obvious thing to do.

I think the Mattermost one is probably the most controversial one because it was least integrated with GitLab, but nonetheless it made us excited to ship that along and just make it easy to adopt and run your own chat tool rather than relying on an external party and suffering with that.

Grant: Yeah. Was the CI tool, was that part of another open source project or was that something that you built from scratch?

Job: No, that was built from scratch.

So Dmitriy started building CI by himself, GitLab CI.

It was a separate project, a separate repository altogether.

And then I think at one point Camille, who was this amazing Polish engineer and I think he still works at GitLab, he built an improved version of Runner that was much more efficient that worked much better.

I think that eventually led to integrating GitLab CI into the main GitLab code base.

But yeah, no, that was from scratch.

The way it worked heavily inspired by other new CI software at the time, which is like you have a YAML config, it's very easy to configurate.

And you have all sorts of good defaults so that you don't have to code everything from scratch.

You can just say, "I want these pipelines to run in parallel. I want these to run in sequence,"that should be very easy to configure.

So we gave of tools around that.

And the main difference was that Jenkins at the time you had a configuration, your Jenkins server that then would run your CI. And then if you wanted to take that configuration from repository, there was a lot to get through. And then building GitLab CI from the get-go with thinking, well, as long as the CI configuration is in the repository, it means that all your commits will forever run because the configuration moves along with the head of the branch.

So everybody does this nowadays, but at the time it was very useful to people that were not using that.

And that made for a really good start. Yeah.

And again, the fact that it came shipped by default, you got it for free and you basically couldn't turn it off.

You could just not use it. You could integrate it with Jenkins which in the beginning most enterprises did, but we just never turned it off and that made it a lot easier to use.

Grant: That's cool. And so back to you and your involvement here, you started off, you said almost like a support engineer, right?

Job: Yeah.

Grant: It's mainly what the company did, how did you scale with GitLab as they grew?

Because I think, oftentimes really employees, not everyone makes that transition to really scale up so well.

So what did you do to make sure that you were able to stay on the same trajectory as the company?

Job: I think I was, when I joined GitLab, the deal I had with Sid was I was going to stay for one year and then start my own company.

And then I ended up staying for five years. So I made my ambitions clear very early on.

And then I just spoke up when I felt like I wanted to change function and I wanted to do something else.

And then whenever I felt like I was in over my head or when that time would come, I would make sure that I would find someone to mentor me or to help me out with the steps.

I think a lot of what GitLab did and still does, we were a fully distributed company. We never had an office.

We did all these things which were weird and that meant that we had to have this attitude of constantly learning and iterating, I think I applied that to how I did things as well.

In the sense that rather than thinking, well, I'm going to build a product organization, I'm going to do it as other people have done, I was just very pragmatic about it.

And that means that I made a lot of mistakes.

I think looking back, there's a lot of things I would've done differently right now, but I was ambitious and I made sure that we shipped a lot of great stuff.

And I think that was my focus, having really, really great output.

And if that's your focus, then you're forgiven of making other mistakes that then you can later solve. I think that's the main way.

Grant: Yeah.

But I mean eventually there was probably a pretty big product org and there's lots of different execs, and you've grown up with the company, realistically, that's pretty uncommon.

So is it the mentorship, what do you think were the real keys to being able to do that so successfully?

Job: No, I don't think it's the mentorship.

I had a few good mentors, but it was not too intensive and not for most of the time.

I don't know, I think a great product leader cares about the product first and foremost, and secondly cares very much about people and those things are things that I think I generally do well.

I think I have a good eye for product and I'm quite good with people I think.

And I think if you're good with people that helps you, not just managing people that report to you, that doesn't just help you manage the executive team, which definitely was a thing.

I think I did it relatively well working with the rest of the team, but it also really helps you customers and potential customers.

One of the secrets we had at GitLab was we were so fast at building new things and shipping iterations, and we were very good at building a minimally viable product or minimally viable change that I could go into a large Fortune 500 company and they would say, "GitLab is great, but we just need this one feature."

And I'd be like, "Well, we'll ship it by next month."

And I would quickly on my phone open Slack and send a message to one of the developers and say, "Can we just make this change? It doesn't seem particularly complex."

And I think that kind of attitude, it scales quite well because it's about getting stuff done and working well with other people.

So I wouldn't know what else it is. Maybe Sid just really likes me, but yeah, I think that's it.

Grant: And obviously¸ you've gone on to found Remote and that's been a pretty quick, but very successful journey.

And so obviously you have proven that it's not just a fluke, but you're able to do this twice, so there's definitely some skill there, but you just don't see it that often.

It's hard to make that transition. But I think there's a lot of folks that--

And maybe it is, the other part is probably cultural and the fact that GitLab was willing to continue to allow you to grow and take those steps and not try to hire over to you constantly and keep you in some position, but give you a lot of growth opportunities?

Job: Yeah. And I was always very blatant about this as well.

I was never really interested in reporting to someone else, but to the CEO.

And actually I never really wanted to have a boss, which is why I ended up founding my own company.

But I think the combination of being really ambitious and I've been generally quite confident and able to speak up when it was necessary, I think that certainly helped me.

Grant: Cool. And then the other thing that obviously GitLab has I think established a model that many companies like Mattermost and Rocket.Chat and many others have followed in terms of open sourcing a core piece of functionality or core tool that companies use and then following up with an enterprise edition--

But the other thing that GitLab did that, I think, I mean, there's several things and maybe they're very tied and you can talk to those, obviously fully remote and fully distributed, but also incredibly open and transparent.

And every meeting is posted to a YouTube unfiltered channel.

And I mean, the amount of content created and made freely available is mind boggling.

So can you talk a bit about those decisions and what led to that and how that maybe worked with being a remote company and how those things play off each other?

Job: Yeah. I think it's the thing that strengthened itself.

So we started out as an open source project.

And so if you're open source, everything is public.

And so changing the way that we did business, just because we built a company, it felt unnatural.

And actually we started out like that, we started out with private issue tracker and such, and we quickly realized that there was really no reason to do that.

And there are massive advantages to being very public about things.

The advantages being that we would have our customer and not just the buyer, but the people that were actually using GitLab, the developers, the DevOps people at different organizations, they would be active in our issue tracker.

And in particular, when it came to enterprise features.

And that was really useful because we could literal just talk with them whenever we were developing things.

That gave them immense trust in us. Because we would say, "We're going to do this."

And then for the customer, and then we would send them a link to like, "This is where we're building it. Oh, this is the merge request?"

"Yeah. We're actually going to ship this next month. Here, this is where we're working on it. It's already merged here."

This would give so of trust in customers.

And then sometimes we would actually contribute to that.

Or sometimes we would just leave comments, but above all, it would just give them an immense amount of trust.

And what we realized very quickly was that the reason companies don't do this is there's all sorts of reasons, but mainly they're afraid that the competition is going to steal something.

But our competition was GitHub, which was massively funded. It was already giant by the time we barely got started with the company.

And we really, on one end, we had nothing to lose, but we also realized that if they were going to spend time reading what we are doing and what we are working on, then they're already behind, we're going to be faster than them.

The only thing we have as an advantage to be fast.

So we really have nothing to worry about. They can read our issue tracker all day.

In the meantime, we're just building things and shipping things.

And that's basically how it started.

And then with building a distributed company, that's all remote, one of the largest challenges you face is how do you deal with information?

And so it's well established nowadays, if you have distributed company you need to have some sort of single source of truth of company information and processes.

And so we had a handbook for this.

And again, we could have made this private, but it would do two things, one, it wouldn't allow other people to contribute to it, which we really liked when people did that.

Because just like an open source project, if your companies open like that, then people, volunteers from around the world, people from the community would contribute not just to your product, but to your company.

So we really liked that.

And the other thing is, and this is not to be underestimated, and which is why I think if you're very distributed, it's good to be very open as an organization, even if it's just internally open, is that access to information is a real problem at scale, in the sense that it quickly becomes a problem that people are not able to find the information because it's locked down, it's in a particular app and then maybe they don't have access to that app.

And then they'll have to ask someone to get access to that app. And those are a lot of steps.

And when you build a company where documentation is a part of the culture and where searching through the documentation and self-serving information is important, you can't create too many steps to actually access all of that.

And so that helped us a lot to just open up the handbook, which is still publicly available.

And besides that, it gave us a really great opportunity to use GitLab to build GitLab because the handbook was just a static repository and so everybody had to contribute to it.

And to contribute to it you had to use GitLab. So that literally forced every single person in the company, salespeople included that never wrote a line of code, to use GitLab.

And of course it was really challenging.

And so we had to teach everybody git, and later GitLab introduced more and more features to make this easy, but it also had advantage that they actually knew what they were selling, which is quite a technical tool.

Explaining what GitLab does to someone that has never thought about how software is written is quite difficult.

And here we have our salespeople having a relatively good understanding of what git is, how it works, how it is part of GitLab, and what a merge request is and why that is important.

So there were all little advantages over time that we discovered as we did this and that just strengthens our position.

And you have meetings, but you want to work as a company asynchronously, so you start recording those meetings.

Okay, now they have to be stored somewhere.

Well, what if we just put them somewhere on YouTube?

So there's all very pragmatic individual decisions.

It was not like a massive decision early on that everything we're going to do is going to be public.

And actually there were all sorts of things that we had to stop being public about.

But yeah, all those things come together and nowadays it's a very transparent company.

Grant: There were things you had to stop being public about?

Job: Yeah. Many things. Many things.

You regularly run into issues with customers that don't want that you talk about them.

You don't want them to talk about the things that you do.

For example, as we got really big and we had a more serious security program, if you say, "Well, we have found this massive security hole," you don't want to publish that publicly.

So there is actually some code now that is not public and before it is merged and released, and then it becomes public because it patches some sort of security hole.

Grant: And you need to give notice to the teams and there's a whole process for disclosures? Yeah, okay.

Job: Yeah.

And there's all sorts of little things that you don't really think about until it happens, which is like addresses of servers or access to particular things.

We were, I think GitHub continues to try to push the boundaries of this, but the bigger organization and more professional it gets, the more you run into little things that you can't do.

There's all sorts of people, operations, issues that become very hard to manage if everything is public or almost everything is public.

So yeah, over time, I think there were many little things here and there that we had to stop being public about.

But nonetheless, I think most of the benefit comes from being public about how your company is run in a more general sense and about building your products.

Grant: Yeah. And I love some of the early sentiment about this, which is by building in the open, you create this amount of trust with enterprise customers.

I think it particularly matters, it wouldn't really matter for consumers, to be built in the open this way, unless they're like a super nerdy involved consumer.

But for an enterprise customer to see that features aren't just promised, but there's like, "This issue has been opened and then it's been planned for this sprint."

Or, "Here's the code that's starting to address it. And we're breaking it down."

It's almost like, it's funny, people talk about waiting on hold you really want to tell people how long they're going to be on hold for right?

Job: Yeah.

Grant: And count it down. And it's some amount of progress meter gives them a sense of comfort that they don't get if they're just like, "Please wait."

So the same concept of when an enterprise customer wants a feature and being able to see that progress going along, it satisfies them in a way that makes them much more comfortable with your team and your product.

Job: And there's this interesting incentive here as well, which is, it works both ways.

So if we for example, would set a due date on expected release for a particular feature, and we would promise this to a perspective customer, then we would have to make that happen.

And sometimes it would happen that we would postpone something for a good reason, because you can't always ship everything on time.

And we would have a customer sending us a message, "Hey, I saw this issue, which I have been following and you just postponed it a month. I thought you were going to release it this month. What's up?"

And that's a really great incentive for you as an organization to one, not over promise because that's really painful because then you're constantly apologizing to everybody.

And two, be realistic. And again, this reinforces itself where if you can show, okay, the things that we plan to build, we actually built on when we promised them and everybody can see that.

And there's a history, right? You can go look at any issue on the history of GitLab that they've built, which is like, this is the initial date that we said is when we expect it to release, and then you can see in which version of GitLab it landed, that just keeps building that trust.

And I really enjoyed that. I thought that was really, really cool to have conversations with customers where they were like, "I want this feature."

And we're like, "Yes, we're going to build it. You can just follow along. You can even add code if you want."

Grant: Yeah. It likely also can serve as a bumper.

I think about, to guide you back to where you need to go.

If the customer's paying close attention and they realize that the thing you're doing is not what they really needed, you might be able to catch it before it goes into production and into beta or whatever else you can get to it even just in a code review, in a comment?

Job: Yeah. This would happen all the time.

And one of the coolest things is when you engage directly with a customer in your own issue tracker, that was so cool.

You could just like, oh, there's this really big customer. And just active.

And part of the discussion of us deciding how we're going to build a particular new feature, that would happen all the time.

And it helped a lot that we really built from a minimal viable change off so that even if they said like, "This is not going to work for me."

We'd be like, "Okay, we're going to release this. And then we're going to build an iteration to solve for your use case."

But in general, yeah, it would happen all the time. That was the nicest thing. You would not expect it.

And of course there were many customers that would not engage on the issue tracker, but even then we would still send them a link, "Oh, this feature that you want, yeah, it's planned for this release."

And it's not just that I could do that because I as produce, it's because our issue trackers public, and everybody could see "Feature X comes in release Y."

And so our support team, or even our sales team could just literally just go through the issue tracker, look up a feature and see, "Okay, this is planned for this release."

And it would happen. That's really nice.

Grant: Yeah.

And there's another thing, drawing back to the idea of your ability to scale up at GitLab, I think being built in the open you're giving access to information to everyone at the company to engage with all of the info.

So oftentimes at companies execs will silo information and use that information as part of their advantage and why they can make a better decision because they have more information.

Whereas at a company like GitLab, it's much more democratized in the sense that anybody can have access to this.

And it's not about who has the biggest title, but it's like, well, I have all the same information that you do so I can make a reasonable and rational perspective or opinion on this and it should be considered.

Job: Yeah And that even goes as far as contributing to it because everybody has the same tools.

I think that was one of my favorite things when we started to write guides about how to contribute to GitLab.

And they were used both for the open source community, as well as for our onboarding.

So that if you were an open source contributor to GitLab and you would join the company, the difference was that you got paid and we would ship you a laptop.

But other than that everything was the same you still had to go through the exact same process. That's really nice.

That makes us feel like merit is what matters most rather than exactly as you said, a fancy title.

And I think you could see that.

I think there was quite a few people that were extremely successful at GitLab because of that, because yeah, exactly as you said, you have access to everything, it's just dependent on you.

Grant: Yeah. Obviously a lot of these things are relevant for remote companies.

And so talk a little bit about what you're doing now.

Talk about Remote, talk about, I mean, I'll say Replicated as a customer of Remote we're using your server to help us start to scale globally, but talk about what you do and talk about the origins of this as well?

Job: Yeah. So we built a distributed company in GitLab, we had people in 67 different countries and we face the same challenge every time we would hire someone in a new country, which is how are we going to provide payroll, benefits and stay compliant in this country?

What many people don't realize is that if you hire someone in a country, you, as the employer have to comply with local labor laws.

And to be able to comply with local labor laws, you have to do things like offer statutory benefits.

And to be able to do that, you need to have an entity.

That is really hard because if you hire 10 people in 10 different countries, which is not a rare thing anymore, then you would have to open 10 different entities beyond the one that you already had.

And opening entities is complex, it takes a lot of time and you forever have to manage the complexity of that and pay taxes in that country, for example.

And so at GitLab, the way we solved this was through different means.

We tried opening our own entities.

We tried working with different service providers like Remote is now one, but obviously it didn't exist at the time, but we found this, that it was really hard, really complicated.

And working with service providers, that experience was generally terrible.

They didn't really understand modern startups. They were very expensive.

And the whole process and everything related to it was very opaque because it was not just a service provider, they tended to work with third parties at the end.

And so what would happen is that a third party would employ one of our employees in Italy, for example, we would only talk with the larger service provider.

And every time we had a question, they would have to go through the chain to the local party and this caused so many problems.

And beyond that, it was just very bureaucratic, not what you would expect from like a modern tech company.

And so I saw that problem and I realized that more organizations were going to work the way GitLab was going to work because of how successful it was. And I thought this is one of the largest things that would stop a company from actually building a fully distributed global work force. And so I decided to address that, together with my co-founder Marcello. And the goal of Remote was very simple early on was that you should be able to scale your organization by hiring anyone anywhere on the planet and doing that should be as simple as signing up to Twitter.

And so we've discovered very early on that the only way to do this properly is to exactly do that, to own everything ourselves.

To not rely on third parties, but own our own local entities, make sure that we are compliant.

And then again, the incentives are so that we as Remote, we are liable and we have to do things well, and that benefits everybody, employee and employer.

And so that's exactly what we do. So Remote works as what is known as an employer of record.

And that means that we employ people.

So if you want to hire Jane in Portugal, Remote Portugal employs Jane, we provide payroll benefits, anything else required to hire her locally.

And we invoice the actual employer every single month for everything related to employment, plus our fee. And that's it.

And as an employer, you don't have to do anything else.

You just treat Jane like any other employee, as long as you pay our fee and our invoice every single month.

And the nice thing about this model is that it works in all ways. So it's fully compliant for everybody involved.

Jane gets normal pay at normal local benefits that she would expect from a local employer.

But you, as an employer, you can just treat her like any other employee, offer any kind of benefits you would want.

And if there are concerns about compliance or labor laws, we take care of them.

And so that's what we built. We started in 2019, January, 2019. We opened doors for customers about a year ago.

And by now we are a reasonably large company with about 150 employees ourselves and growing really fast.

Grant: Yeah. Obviously you had the tailwinds of just the general world moving to more and more global, more and more remote work.

And it probably didn't hurt that with a global pandemic, everyone shifted to remote and this problem probably accelerated in the minds of the market by a few years.

And I think that if you look at the growth of the company, you can see that's reflected in the last year I'm sure it's just been gangbusters in terms of demand and opportunity?

Job: Yeah. Yeah. It's been overwhelming. I didn't think the company would grow as fast as it's doing.

I think we set very ambitious goals and we keep surpassing them. So that's certainly also a challenge, but it's also very exciting.

Grant: Do you see yourselves as serving primarily startups and software companies, or is there larger enterprise organizations that are starting to work with you, what's the target?

Job: Very interesting, very early on we had the thesis that almost all knowledge worker companies would need services like we would offer.

And that seems to be mostly true in the sense that we have very strong inbounds from startups because they tend to hire quickly.

They tend to be early adopters of these kind of models like distributed work.

So we have a lot of startups that are growing quickly and that is the majority of our customer base.

And they tend to be somewhat larger startups usually.

But we also see demand from large enterprises and we also see demand from just regular companies, companies that produce chocolates and that are not necessarily in tech and that definitely has been very interesting.

And we know that this kind of model, this kind of service has existed for decades.

Actually, mostly it would serve large enterprises because they would have expats that would live in a particular country and that they wouldn't want to have a local subsidiary just for the two or five employees that they would have there.

And so they would use these kind of services.

So yeah, the demand comes from almost any kind of organization.

That has been very exciting to see as well.

Grant: And for the larger companies, it feels like particularly based on your pricing page, there's probably a lot of enterprise functionality around producing the reports and the compliance like, "Hey, here's how to prove what's happening. That this is the way that we say it is," is that right?

Job: Yeah. That's basically it. I think it's been less intense than I expected.

Looking back at GitLab where the demands from the enterprise customers were very intense in terms of the features that they required.

I think at Remote I don't think we serve too many large enterprises yet, so it might still come or many regulated ones, but it's exactly that, it's things like reporting and integrations that you would expect.

They have large systems where they roll up thousands of employees and they want to integrate it with that.

Nothing too crazy. Having worked in enterprise server for a long time it's going to be hard to be surprised by what they're asking, but yeah.

Grant: Yeah. But yeah, that also would make sense is the integration side, so making sure that you are integrating with their existing, I don't know, HR admin tools, what are the top integrations that you're doing today?

Job: It's very interesting because it's all over the place.

I think the larger the organization, the more it's around finance and integrating with NetSuite and SAP and those kind of tools.

We see requests for all sorts of tools, the ones like the big HR platforms in the space, but I think in larger enterprises so much is done by custom tools or things that have lived for a very long time we don't even have that many requests for very specific, large enterprise HR tools yet, but it's mostly those finance systems and such that they care about.

And then once in a while, a request for system of which we've never heard of, of a company we've never heard of and then turns out that's apparently used by a very large part of the Fortune 500, that definitely has been interesting as well.

Grant: Yeah. The proliferation of various software products throughout these organizations, I'm always surprised at like, there's, "Oh, that's another $50 million a year software company that I had never heard of."

Job: Yeah. Yeah. It's incredible. And super expensive software that looks terrible and tends to work terrible and has no API. And yeah, we see that a lot.

Grant: Yeah. Those are fun to integrate with.

And so when you think about the future of Remote, particularly for enterprise software companies, what do you think everyone's going to be doing in a few years?

And the other question is always what do you think is going to be the same that it is today? What's not going to change?

Job: In what sense?

Grant: I mean, just like remote work, so are we going to continue to use all these different collaboration tools?

Is there anything to solve for time zone challenges?

Job: Oh yeah.

Grant: What are we going to see emerging?

Job: I think one thing that is really lacking on an enterprise level but I am starting to see that Slack is starting to address it here and there already, is tools that cover more than a need of just having meetings and basic communication.

So I think what is well established that is a distributed company, a company with people in many different time zones you need to work asynchronously to a degree, meaning having great documentation tools.

I think there's no great enterprise level documentation tool.

There's Confluence, which is not great. And then there's tools like Notion and Coda and Slide, which are good, but not great for enterprises because they don't support that kind of scale yet. So there's clear lack there.

And then there's a clear lack of out of the context of work communication, things that give you a sense of presence, things that allow you to have water cooler chats without them being too forced, without them needing to appear on the calendar.

There are quite a few tools that do that, but I think almost none of them, and then that's why I mentioned early on that I think Slack is working on this, but right now none of them are good enough for enterprises and none of them are good enough for scale.

And I think that's a clear miss.

And then there's a last category here, which is actual bonding over playing games together or having more casual, fun together.

Which enterprises tend to do by just having a budget for lunch, for example, or once in a while having offsite.

And I think having offsites will still happen, but actually playing games together and things that force you to get to know your colleagues in some way or another, there's a market for that as well.

And again, I think almost none of these tools are actively going after the enterprise.

I think in part because it's a hard sale, but also because as you know, if you want to sell to the enterprise, you need to have SSO, you need to be GDPR compliant and you need to have your SOC tool ready.

So those are difficult things when you're talking about communication tools.

Grant: Yeah. That makes a lot of sense.

I think the getting to know the people you work with aspect is really important. One of the things that, so we hired our chief product officer.

He was at GitLabs. He worked with Mark Pundsack, and when he joined Replicated, one of the things that he brought to us was some of the best practices around remote teams.

And I think the one that's probably the most impactful is just we do a weekly all hands and during that time, we just go around the horn and let everyone talk about what's going on in their life for two seconds or two minutes and show photos and just talk about their weekend, and what they're watching and what they're doing.

And we've been doing that now for probably seven or eight months and it really does make a difference in terms of how people feel connected and how you know each other a bit more.

It's those candid conversations beyond work that I think build trust and create, it goes beyond coworkers to where these people become important people in your life.

Job: Yeah. This is incredibly important.

And I think as an employer, you have to actively work on introducing these kind of cultural habits within the organization, actively work on bringing tools that help make this easier.

Because if you don't, you're going to end up with people that feel isolated or feel alone or not comfortable asking favors from a colleague for example, which are very normal, basic things, but you need to build some sort of rapport with your colleagues, and you're not going to build rapport in just together, right?

Like if all your interactions are with someone else, if all those interactions are around the context of work, we're working on this project and this is what I need from you, okay, now you can do this, you don't really build rapport with someone like that.

And that would also lead to higher churn, people leaving companies because what ties you to the company, if it's not the relationships, it's just your salary at one point.

Grant: And I mean, do you see yourselves building anything in this space or is Remote really about the workforce management and access to having those employees, or do you see yourselves kind of getting into this at some point?

Job: In a far future yes, but definitely nothing on the short term.

There are many exciting companies that work on these kind of solutions, all sorts, basic voice chat, different kind of video tools.

But even just like video games, video games are a really great way for teams to bond.

And it doesn't have to be something overwhelming or aggressive.

It can be something as simple as Pictionary, which is a huge hit at Remote.

Or for example, Among Us, which has almost universal appeal, those are great games and they actually serve this purpose really, really well.

Yeah, I don't think it's up to us. I think our speciality is large scale, complicated compliance and operations.

But yeah, I think this can be a massive market and I'm very excited to see what companies come up with.

Grant: And you do host a podcast around remote work as well. Right?

Job: Yeah, yeah. So we do Remote Talks, which is, I just talk with people that run remote organizations and talk a little bit about how they run their organization or what is special about what they do.

And the interesting thing that I found there is that it's so different.

If you think about office culture, office culture you can categorize as very roughly you have the large consultancy banking kind of stuff, which is suits and ties.

And then you have on the other end of the spectrum, you have the Googles of the world, which are very, very rare, there's only a few of them with really relax workplaces.

And then most organizations are somewhere in the middle, which is you can dress somewhat casual, you know exactly what to expect in an office.

You go in the office, you have lunch together and you leave the office and that's about it.

And there's not very much special about it.

When you look at remote and distributed companies, because other than what GitLab basically wrote, there's not really a playbook.

And so companies have to reinvent themselves or define themselves by what they do. And what I see is that all these companies operate completely differently.

The way they run meetings, the way they do bonding within the organization, there's not really an established great model yet.

There's just a whole bunch of companies trying different things and with different levels of success.

That's been very interesting to see. I think one company that stands out to me, the company that built One Password, I interviewed one of their founders a few years ago and he told me that they basically don't use video chat.

I don't know if it has changed in the meantime, but I always think about that, that whole company is run without video chat.

And I always think that's very interesting. I think it's nice to look at people, but maybe that's not necessary to run a company.

Grant: Yeah. That's actually really interesting.

I guess it's because it's still so early and a lot of the best practices really haven't been defined and established.

And then maybe the other thing is it is a format that allows for more variation because it's not constrained to physical location, because it doesn't have a lot of the same constraints it can evolve differently.

It gives you some amount of additional hope that as companies go remote, there's a bunch of right ways to do it.

Obviously there's things that you'll learn that don't work well, but maybe there's a lot of different ways to do it well?

Job: Yeah I think so. It's incredibly interesting. And especially if you start to scale.

And it's been very interesting to talk with large distributed companies, then there are so few examples, but there are so many challenges that you have to be really, really creative.

There's only a few GitLabs in the world although that's accelerating incredibly fast as you see some very large enterprises saying, "Well, you can work from home forever."

That's very cool. It's very cool to see.

Grant: Yeah. I mean, I think it's going to be even just in the US, I think it's been really good for the country primarily because if you get a lot of people to leave these major city centers and go into rural parts of the country and start to like, "Hey, the coasts versus middle America, maybe this rivalry is not so bad. And these are real people on the other side."

Maybe we can bridge some of that divide.

And then also bring the next generation of like careers and jobs and wealth outside of just Silicon Valley and New York and LA, it's bring it into all these different places.

And I think it's really important for people to see what the kind of success looks like.

And so to have a neighbor that's running a startup in middle America just didn't happen as much before, and maybe it will now.

And so that sort of visibility to somebody growing up in Iowa or in Texas, or wherever else could really be influential in the future.

And then to the remote side, now let's take that to the world. Right?

And let's get access to the world's talent.

If you believe that talent and intelligence are fairly normally distributed around the world, we are missing on a lot of really amazing people who could be contributed to the world in big ways, because they don't have the same access that we do in every developed country.

Job: Yeah, exactly.

I think that's exactly how we started out Remote thinking we wanted to bring more opportunities to people around the world.

And then we quickly realized that's not sufficient because it has to be wealth.

Because you can hire someone for very little money in another place in the world. And I don't think we're addressing the problem that way.

And so that's the way our mission has changed.

We want to bring more wealth to people around the world, independent of where they live.

And I think we can. I live in the middle of nowhere in Portugal. There's nothing nearby my house.

There's no tech companies or anything here. There's nothing really, there's not even a supermarket that's close to my house.

And my co-founder leaves 400 kilometers away from me. So I think it's possible.

Grant: No, that's great. I love it. Job thank you so much. I've really enjoyed the conversation.

It's just been cool to learn about all of your different experiences and where you see the world going. So thank you for joining.

Job: Thanks for having me.