Building High Performance Remote Dev Teams w/ Eric Johnson of GitLab

**SPEAKER_1** (0:02)
Stay remote or go back to the office. This is the question engineering teams are trying to answer in 2021 But there's an even bigger question. What does it mean if we stay remote? How do we onboard and hire and optimize workflows asynchronously? GitLab has been a fully remote, globally distributed engineering team for years.
That's why I've brought in Eric Johnson, the CTO of GitLab, to help us learn how the experts are creating high-performance remote engineering teams and what advice he has for the managers and leaders who are starting their own full-time remote journey.

**SPEAKER_2** (0:42)
This episode is sponsored by Linear B. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**SPEAKER_1** (0:57)
Eric, thank you so much for joining us today.

**Eric Johnson** (1:01)
Good to be here.

**SPEAKER_1** (1:02)
Yeah, awesome to have you on the pod. Super excited about it. GitLab is definitely an awesome company. I think most people know that. And also a very, I would say, unique company. You were all fully remote even before it was trendy or even mandatory with the pandemic situation to be fully remote. You also are open source and you have this incredible culture of full transparency.
Even transparency to the point where I've seen you answering some questions on YouTube maybe every month from employees. So pretty amazing stuff.
Before we get into our conversation about building high-performance remote teams, I'd love to learn a little more about the GitLab engineering team and a little bit more about you. So let's start out with how long have you been at the company and how did you get involved with GitLab?

**Eric Johnson** (2:06)
Yeah, I've been here coming up on four years. I started as a VP of engineering, so that's kind of the type of CTO I evolved into. Sometimes the CTO is the head sales engineer. Sometimes it's the PhD running the lab outside of engineering. I'm kind of like the super VP of engineering. That's the type of CTO that I am. And I've got seven departments reporting to me.
Development, infrastructure, quality, security, support, UX. And then we just recently had an incubation department. We're going to be sort of like our labs.
We're going to be working on kind of far future ideas that eventually make their way into more mature GitLab features and teams. And all in, the whole team is about 560 So that's grown about 5x over my tenure at GitLab.

**SPEAKER_1** (2:52)
Yeah, that's awesome. And I'm happy that you described exactly your role as CTO, because you're right. Sometimes you get some CTOs that aren't really involved with day-to-day development or delivery of new features, maybe more on the partnership side. And I love how you said that you're like a super VP event. So that's really, really cool.
So for GitLab engineering, how do you think about the structure of your teams and maybe dev methodologies that you use or don't use? How do you work?

**Eric Johnson** (3:27)
Yeah, so our teams are arranged functionally. So the seven departments I mentioned, they all represent different roles, different titles you recruit for.
But I get the sense why you're asking these questions because different companies slice it different ways and wherever you slice it, you have problems across those seams. And so we like the functional model because you have managers who have come up doing the same thing that their team members have done. So they have that empathy, they have the technical expertise, they know how to recruit for really effective people in their own specialty. And in terms of collaboration, we have something called stable counterparts.
And so we found the most effective thing is, for instance, if every product manager is getting randomly assigned a different front-end engineer every release, they have to get to know that person, establish that relationship. And so we do what are called stable counterparts, meaning people are kind of permanently assigned to various areas. So we have these product development groups who work on features and their product managers, their backend engineers, their front-end engineers, their test automation engineers, and they mostly work together even though they're on separate functional teams. Yeah, that's really cool.

**SPEAKER_1** (4:39)
I mean, throughout my career, I definitely want to know the person at a personal level who I'm working with. You can rely on them. There's a lot of trust elements of that. So totally respect why you would do that.
In terms of methodology, is there...
Hey, everyone, I don't know. Let's think of the functional teams that you mentioned or like feature delivery kind of teams. Does everyone have to use Scrum or Kanban, or is it up to, I guess, the team leader? Like who decides how each team works?