Hello world, meet the GitLab Configure group! They’re the folks hard at work improving Auto DevOps, the Kubernetes integration, and all the related applications on GitLab. They, like the rest of the GitLab engineering function, recently changed how they work together when we split up into devops stage groups according to product area. Each group contains a product manager, UX designer, several engineers, and other contributors. They still belong to teams with others usually in their same role, but they work together as a group dedicated to a stage of the product lifecycle.
So far, Configure group 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 stable 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 set of people for each product area; they enjoy more latitude and no longer face as much competition for getting their work prioritized. These are all benefits of stable counterparts, or people in different functions, departments, or teams who routinely work together, easing communication to avoid conflict and the downsides of a matrix organization.
Some of the challenges that drove this change have been echoed in our user research, with cross-group communication a common and recurring roadblock. In our 2018 Global Developer Report, a quarter of engineers 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 colleagues 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 stable groups 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 group, 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 Backend Engineering Manager for the Configure group.
Thong: I’m new here! I’m Thong and I'm a senior backend engineer.
Mayra: I'm Mayra and I'm a backend engineer for the Configure group.
Taurie: I'm Taurie, the UX designer for the Configure group. 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 group. In short I have to make sure that the features we ship are aligned to 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 stable devops stage group 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.
What are some of the big differences that arise from working with people in different roles, versus working more with people who share your background?
Thong: Key for me is the different strengths and perspectives that we all bring into the group. I'm pleasantly surprised how well our strengths overlap and support the group. 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 group'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 group 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 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 new group?
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 group members and has resulted in fairly healthy collaboration and high levels of trust between group members. We've also done 1 retro as a full group, 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 group members as a way to discuss things outside of work and continue to strengthen the connection between group members. Our monthly group retrospectives are a great way to discuss what is working well within our group, 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 group along the lines of engineers waiting for issues to be labeled "UX Ready" before starting work on any feature. But now as a group 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 group 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 group?
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 group 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.
Anything else you want to share?
Daniel: We're always looking for engineers. 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!
