GitLab Switched to Cross-Functional Teams. Here's How It's Going.

Hello world, meet the GitLab Configure team! They're the group focused on improving Auto DevOps, the GKE cluster integration, and all the related applications on GitLab. They, like the rest of the GitLab engineering organization, recently changed how they work together when they split up into brand new cross-functional teams according to product area. Each working unit contains a product manager, UX designer, and several developers.

So far, Configure team members say this has helped them stay focused and connected. Staff UX Designer Taurie Davis explains that while she used to have to switch gears and spend time getting caught up on different product areas, she can now hone in on finding solutions to familiar problems. Having a fixed group of collaborators also promotes shared learning, because they're working together on the same issues at the same time. Product Manager Daniel Gruesso also sees benefits in having a dedicated team for each product area; they enjoy more latitude and no longer face as much competition for getting their work prioritized.

Some of the challenges that drove this change have been echoed in our user research, with cross-team communication a common and recurring roadblock. In our 2018 Global Developer Report, a quarter of developers indicated that they feel siloed, and lack visibility into what their colleagues in operations, product, and security are working on.

This was reinforced in recent interviews by our UX research team, where many developers we spoke with said that they're frustrated by changing requirements and scope creep, and pinpointed poor communication with and empathy for other teams as the cause. Their counterparts in operations roles face a similar challenge in convincing others to invest cycles in proactive work that can save them time and stress in the future. Although implementing cross-functional teams may seem like a big change, we've seen positive results and hope that sharing our experience may help others take the plunge.

I recently caught up with a few members of the Configure team, read on for their perspectives on how it's been going.

Can you each introduce yourself and explain your role?

Dylan: Hi I'm Dylan. I'm the Engineering Manager for the Configure team.

Thong: I'm new here! I'm Thong and I'm a senior developer.

Mayra: I'm Mayra and I'm a developer for the Configure team.

Taurie: I'm Taurie, the UX designer for the Configure team. I work closely with product and engineering to help shape the overall user experience of our products.

Daniel: I'm Daniel, the Product Manager for the Configure team. In short, I have to make sure that the features we ship are aligned with our vision; this involves interacting with everyone from customers to the CEO. Working together with engineering, UX, and leadership we make our vision a reality.

In general, how do you think it's going so far?

Dylan: So far the cross-functional team is working well. I believe that backend teams already were well focused on specific product areas, but I think the addition of focused UX and frontend engineers on our product area helps in a few ways. First, we know who to talk to about UX decisions, and the UX designer and frontend engineers have good context across the feature set and often have good insights based on this context. Backend engineers also get to collaborate and form better working relationships with UX and frontend, and as a consequence, we communicate more effectively in general.

Thong: Key for me is the different strengths and perspectives that we all bring into the team. I'm pleasantly surprised how well our strengths overlap and support the team. Because we come from different perspectives, I feel we can often challenge each other constructively and check that we are heading in the right direction with respect to achieving the best value for the product. The challenges I have seen in the past would be establishing a common understanding of the team's goals, which sometimes might not be exactly aligned with each department's goals.

Mayra: Thong's answer is a really good one. I'm also quite impressed by how our strengths bolster the team productivity.

Taurie: We bring different perspectives to the table which can only improve the product in the end. It also greatly improves communication and allows us to work together instead of in progression. I, personally, have also learned a ton by working so closely with both product and engineering on a daily basis.

Daniel: I greatly benefit from learning the technical aspects of our work; if I only interacted with other product folks I would surely not learn as much. This is by far the job where I've learned the most in the shortest amount of time. I love that.

How has the new team structure impacted your day-to-day?

Mayra: For me, it has had a positive impact because now I'm focused on developing particular features for certain areas of GitLab, like the Kubernetes integration and Auto DevOps.

Dylan: We have deeper conversations with UX designers and frontend engineers as they understand our product set well. Ownership from the UX designer means that as an engineer I feel less stressed about resolving UX decisions or making issues for UX issues, as I can see that Taurie will often take responsibility for seeing this through.

How have you tried to bond as a team?

Dylan: We are bonding quite well. We started with daily standups and worked our way down to twice weekly. The daily standup really accelerated the bonding between team members and has resulted in fairly healthy collaboration and high levels of trust between team members. We've also done 1 retro as a full team, which I believe was a more comfortable and open environment as a consequence of us bonding for some time before hand.

Mayra: At the last GitLab Summit, we had our first on-site dinner; sadly, Thong was not able to join us, so we'll need to update this picture on the next summit!

Taurie: We also have coffee break calls regularly with different team members as a way to discuss things outside of work and continue to strengthen the connection between team members. Our monthly team retrospectives are a great way to discuss what is working well within our team, what has been on our minds, and what we can improve for greater collaborations and results.

Daniel: I always try to start calls with a personal touch, no matter how small, I've found it sets people at ease. We plan synchronously and clear up any doubts on the work before starting. Once we're aligned we mostly catch up asynchronously.

Are there any previous problems, delays, or frustrations that have been resolved or prevented in the new structure?

Dylan: Difficult to say, but at a high level, we had many discussions before forming this team along the lines of engineers waiting for issues to be labeled "UX Ready" before starting work on any feature. But now, as a team, we've come to realize that we're all involved from the beginning to the end, and engineers are responsible for ensuring the UX makes sense and the UX designer is also responsible for ensuring the final product makes sense. We also regularly have UI contributions from Taurie, which saves the round trip of commenting on the MR and waiting for the engineer to make the changes.

Taurie: Shifting between multiple different product areas made it much more difficult to learn and keep up to date with the more technical areas of our product such as Kubernetes, and Auto DevOps. Being integrated into a team who is constantly working on these features means I have more domain knowledge and can more confidently answer questions related to the user experience of our area.

What are you most excited to tackle together, and what can we look forward to seeing from the team?

Dylan: We're focusing on making Auto DevOps clearer to users; making more decisions based on research rather than relying on industry trends; building a large and engaged user base for Auto DevOps that helps guide us to make better decisions by collaborating on issues; and improving the code architecture so that frontend engineers are more empowered to build better UX without the need to involve backend engineers (eg. more user experience handled in pure frontend Javascript code).

Taurie: I am excited to see the team continue to grow and tackle issues that improve the Auto DevOps experience so that it is widely used among GitLab users.

Daniel: I am definitely excited to participate in some of our big initiatives like serverless and PaaS. In the near future, you can look forward to group-level Kubernetes clusters as well as some great Auto DevOps improvements like the ability to initialize and migrate databases.

Daniel: We're always looking for developers. Familiarity with Kubernetes and expertise with Ruby will help you land an interview.

Dylan: Try out Auto DevOps and don't be afraid to create issues for us if you run into trouble. We love hearing from our users!