Details & Thrive: How Gather’s Engineering, Product, and Design teams fixed 116 bugs in two weeks

A few weeks ago, our EPD team (Engineering, Product, and Design) decided to test a new kind of sprint: Details Week. Or as we nicknamed it internally: Details & Thrive! 

This sprint was entirely focused on the details of the Gather experience. And in just two weeks, the team pushed 116 bug fixes and improvements to the platform. Seriously, give them a round of applause! 👏 

To celebrate the hard work that went into this sprint, Liz George, Head of Community at Gather, sat down with three members of the team to give a look behind the scenes. 

Watch the recording of the livestream here, or read the transcript below. 

‍Liz: Hi everyone, I’m Liz George, Head of Community here at Gather. I’m gonna go ahead and throw it over to the team to do some introductions. 

‍Justin: Hi everybody, I’m Justin Key and I’m a Product Manager here at Gather, and I’m based in Seattle. In a nutshell, my job as a Product Manager is to set the vision, strategy, and feature requirements for the products that we build. And then partner with Design and Engineering, and other internal and external stakeholders to bring those products to market. 

‍Josh: Hey everyone, I’m Josh. I’m an Engineering Manager on the Core App team, based in Vancouver. And as Justin said, we work closely with Product and Design to execute on the user-facing features that we build. 

‍Lau: And I’m Lau. I lead the Design team here at Gather. Our challenges lie within everything from interaction design to visual and brand. Also working with Engineering and Product to define those problems in a super user-centric way. 

‍Liz: Awesome! In the spirit of remote work, I think it’d be great if everybody could share our locations. I’m in the San Francisco Bay Area. 

‍Lau: I usually work from Toronto, Canada, but right now I’m in Dublin, Ireland. 

‍Josh: As I mentioned, I’m usually in Vancouver, but right now I’m in San Francisco. 

‍Justin: I’m based in Seattle. 

‍Liz: Alright, let’s jump right in. For any new users here, tell us what Gather is and generally what the product team is focused on right now. 

‍Justin: At a super high level, Gather helps distributed or remote teams build digital spaces that bring everyone together and make virtual interactions feel more human. When our customers are using their virtual space (their virtual office), whether they’re collaborating in meetings, coworking, stopping by somebody’s virtual desk, connecting with their team becomes more of an energizing experience where productive work, collaborative work, and company culture can happen no matter where their team members are based. 

In terms of some of the things we’re working on, some examples coming up are enhancements to our meeting experience, including features like screen recording and more in-depth calendar integrations to help our users schedule meetings and participate in meetings on Gather. Along with fun improvements to our desktop app, and upcoming next year is an all new Gather mobile app, which we’re super excited about!

‍Lau: Yea, definitely everything that Justin has outlined. I kind of want to put a spin on the design focus of this. Gather’s design challenges within the platform itself are really interesting, and I think that they’re really different from anything that’s out there. 

We’re talking about a platform where people interact with each other, but not only that, there’s also a world attached to it. And we’re trying to really hone in on how people work within this space. 

The cool part about working in this product is that we’re always coming up with new interaction patterns, taking things that belong to existing products. You have your meeting platforms UI patterns that exist, and we’re adapting them for this world that is quite new in the way that people can be connected to each other. 

So it’s a really cool challenge that we have with the remote work focus, as well as making sure that people are really easily connected to each other no matter where they are in the world, or time zone even. 

‍Josh: I think Justin and Lau covered it perfectly. They said everything that I would’ve said. 

‍Liz: Well that means you’re going next for the next question! So today we’re talking about something new the team did: Details Week. Do you want to share what that is and how it’s different from a normal Product and Engineering sprint? 

‍Josh: Justin, you want to take the start and then I’ll add the Engineering perspective? 

Justin: Yea I’ll kick us off. So again at a high-level, we move very fast at Gather to bring new products and features to our customers. At any given time, we have a bunch of projects, I can’t even tell you how many at various stages of development. 

Over time, as we build, launch, and iterate on new features, we inevitably introduce bugs into the customer experience. And we also identify needed feature improvements, changes we want to make, or customer feedback we want to incorporate. 

So with our Details and Thrive sprint, what we essentially did is carved out time for the entire team to focus on getting those details right. Fixing those bugs, incorporating those small incremental feature requests, and prioritizing focused work across the entire team and dedicated time to work through our broader feature backlog, while we paused some of the bigger product initiatives that we were working on. 

‍Josh: To add to that, from an Engineering perspective, at many companies you’re always trying to balance “How do we move quickly?” “How do we build the things we really want to get out?” and “How do we also make sure they’re really high quality?” 

And it can be easy to fall into one side or the other a little too much. It can be easy to try to get things so perfect because there’s so many things we want to build for our users and we really want to make sure they’re great. But we can spend so much time on one thing trying to make sure it’s perfect, that we might not end up getting to those other things. 

On the other hand, we can end up doing the opposite where we end up spending so much time trying to build out all the exciting things that it’s easy to lose focus on those details. 

So I think this provided us an opportunity to make sure we were carving out explicit time for the details. And I think we were also just very intentional about it. 

It let us really be intentional about what we wanted to do and make sure we had the time to do it, which I think was key. 

‍Lau: I think it’s quite important to also note that Gather itself is very young. I was talking earlier about all these new interaction patterns that we have. When we first started, we started them as experiments. Will this stick? Is this going to be the right feature that we move forward? How are we going to evolve this past an MVP, for example?

And as the year went by, in which we looked back and said “Okay, what are the things we need to adjust?” we learned a lot from our early-age experiments. And not only did we learn a lot from it, but we saw it in the real world with other platforms. 

Because we made a big splash in this space, a lot of other platforms were also taking our patterns, mimicking them, and then putting them out there. 

So not only did we have our own Design and Engineering debt, but we also kind of owed a debt to the other platforms out there for putting things we were just experimenting with. 

So this time was really good for us to look back and see how it affected our platform and the way that people connect with each other, and how we can make it better so that people can actually do the things they need to do on Gather in an easy and delightful way. 

‍Liz: Thank you for sharing that. Is this something that’s really different from different approaches that we’ve taken before? 

‍Lau: I think we definitely were a little bit more experimental in the past, and as Josh and Justin said, we move extremely quickly. It’s great that we do that because we can learn a lot really fast, but then we make a lot of mistakes along the way as well. 

So looking back and seeing, “Okay, maybe we should have done this a little bit differently.” It’s this learning that we can take on to the next challenge. So we’re continuously learning not only how to work with each other in Engineering and Product, but also how to work within the space that is so intricate in the way that we all connect to each other. 

‍Liz: The three of you have extremely different roles. Can you explain to me what your role in the sprint was? 

‍Justin: First and foremost, it’s very much a team effort. Me specifically, I worked with Josh and Lau and their teams to organize and prioritize the list of bugs and feature improvements that we wanted to work on during the sprint. And then provide my input on each to ensure  we get everything built and working as intended. 

‍Josh: Yea as Justin said, it was definitely a hugely collaborative effort. I think for me as an Engineering Manager, I just wanted to make the team had the right tools and felt supported. 

As I mentioned, there were so many things we wanted to get done. There was the great blog post: 116 bugs, details, and improvements that we made. 

There were even more tickets than that. We had a ton of things that we wanted to get through. So just really making sure the team felt supported and understood how to work through those things. 

‍Lau: Very similar to Justin and Josh, we worked together every single day. We met up with each other for a few hours every day to make sure that all the tasks we had collected – from feedback from users to our own internal team – were looked at and sorted properly so that our team could easily pick them up, make sense of them, and design or engineer them. So this was the collaborative effort that we did. 

And then from the design point of view, my role was to make sure my design team felt like they were empowered to make decisions based on those tickets. They had enough information so that they could go ahead and create an improvement on the pre-existing format, but then also to make sure the design ended up being holistic. 

The feedback that we received and the tasks that we attached to these tickets were from all sorts of different parts of the platform. So from video to settings to whatever, everything was scattered all over the place. So I really had to make sure that our full team had the same visual UI, interaction patterns, and principles of design that our own team has, to make sure everything looks like part of the same platform. 

‍Liz: Now that we talked about what it is. How did we decide to dedicate entire teams to these details for two entire weeks?

Justin: This kind of work often gets put on our backlog as we prioritize the bigger, more strategic projects, like the ones I mentioned earlier. Individually these things are small: These bugs, these feature improvements. But collectively, they add up and start to impact our customers' perception of how well Gather works. 

Making sure we get the details right ensures that Gather feels like a polished experience and it’s one that meets the needs and expectations of our customers. 

‍Lau: Design is essentially constantly looking for ways to improve our platform. We don’t wait for a certain time to see how we can make things better. We’re constantly looking at things and being like, “Hmm that doesn’t look too good.” So we set up times within our own weeks to make sure that those pesky little problems get addressed. 

But what Details Week did, it helped us to actually focus in on that and make it our full priority. Just like any other designers out there, our own platform bugs us. The more that we’ve been looking at it, the more imperfections we have. So it’s just this endless list of improvements we want to do. 

‍Josh: Yea, and I think the thing I wanted to add on top of all that is that we all had the same kind of mindset. We were all working on it at the same time. 

Usually we’re working on a bunch of projects in parallel, and thinking about a whole bunch of different problems in these bigger buckets. Details and Thrive helped us all get on the same page about trying to be in the mindset of knocking out these smaller details and really improving the product as a whole collectively. Which I think was really helpful and super good to have all at one time together. 

‍Liz: So we identified the issues: A lot of these things were on the backlog. We want to make sure things are perfect because we’re constantly staring at the screen and seeing these bugs popping up. How did you decide which ones we would focus on? 

‍Justin: Thinking about the process first, we already had this existing backlog of bugs, feature feedback, and customer requests that we’ve been collecting over many months of work. 

Once we decided we wanted to pursue this Details and Thrive sprint, we also reached out to our broader internal Gather organization to solicit inputs from the team or other feedback or feature requests that they had. We ultimately collected well over 300 new requests and features, which we organized as tickets. We reviewed each of these one by one across this group here (Product, Design, and Engineering) to prioritize the work. 

Then Lau and I worked together to add Product and Design definition where we needed it, to help define what we actually wanted to build and what it’s supposed to look and feel like. And then we rallied the team together. 

Josh took all those tickets and worked with his team to assign them out to different engineers. Lau did the same with her design team. And then we worked together over the course of two-ish weeks to bring these improvements into the Gather customer experience. 

‍Liz: Awesome! What was the review and development process like? 

‍Josh: We basically go through the same process as we do with other features. We usually have an idea of the things we want to do. As Justin said, we’ve collected all those insights, so we have a good sense of what to focus on. 

And then when we start working on them, we have a review. We’ll do QA, we’ll have a design review, and we’ll have a code review to make sure the code quality is good and that we’re not introducing any further issues. As we add more, we want to make sure we’re improving the quality as we go. 

And then once things are good, we’ll review it in code, we’ll approve and it gets merged, and usually we’ll have things go live within a week of us completing it. 

‍Liz: To switch gears a little bit, what was your favorite bug that the team fixed? 

‍Josh: For me, we had a lot of requests for a long time for a way to prevent your avatar from being followed. Which comes up in so many places: Like sometimes you’re doing a demo and someone leaves for a little bit and they’re awkwardly kind of following your avatar around, and you either have to leave or join or whatever.... 

So we added that, and it turned out to be a lot more effort than it seemed on the surface. We wouldn’t have been able to do this without having this dedicated time. And you know, I think it’s something that’s pretty impactful. I know it’s useful for me, so I was really excited about this particular feature. 

‍Lau: I’ll go next. It’s not really a bug, but it’s more of a feature that we ended up doing. So everything regarding the guest experience – and my favorite part is the “Guest” tag. So when you’re in a remote work setting and there’s a new person that is not part of your office, we’ve added a “Guest” tag to their name as well as on the Participants List to make sure that people know that this person is not a team member. 

And I think I really like this for a couple of reasons. One, if you think of your experience in a real life office, you know your coworkers by looking at them. You hopefully know their face and remember their face, and when you see somebody that’s new, you automatically “recognize” them because you’ve never seen that face before. 

But here in Gather, we’re kind of hidden behind avatars. Maybe I’ll switch my avatar into a ghost around Halloween (I think I was a bat last year for Halloween on Gather). And sometimes, if I don’t have my name on, maybe I’ll have “Batman” or something, so nobody will know that it’s me. 

So if I were a guest and I was also named “Batman,” maybe they’d think “Oh that’s Lau,” but no – actually it’s a guest. So having that direct tag really helps office managers and anybody that’s interviewing or looking for somebody specific to quickly be like “Okay, that’s a guest.” 

I think of it like the “Hello my name is…” tag when you go to a conference, and it’s very clear who’s who at that point. 

‍Liz: For me, the Guest tag is extremely helpful because I was actually going to have a meeting with a member of our team, but I looked and saw that she was talking to someone who’s a guest. So I was like “Oh, I need to make sure to give her plenty of time because she’s actually speaking with somebody who’s outside of the company.” And I was able to respect that by seeing that Guest tag. So I really enjoy those non-verbal queues a lot. 

‍Justin: Big plus one to everything y’all have mentioned. I’ll say very briefly – as a user of Gather, I really appreciated some of the incremental improvements we’ve made to our chat and emote experiences. They collectively make it even easier to communicate with colleagues on Gather. Even though those things are relatively small and incremental, they go a long way in helping us feel more connected. 

‍Liz: What advice would you give to other teams interested in doing a similar type of Details Sprint? 

‍Josh: I think I touched on this before, but making time for it is really important. It’s very easy to focus on the bigger projects and get things out, and sometimes little small issues will come up that we’ll fix quickly, but there’s those things in between that are hard to make time for. 

And I think it was really important that we set out this time and carved it out, and had everyone in the same mindset. So I think that was a key thing that I’d recommend if you’re going to do something like this. 

‍Lau: My advice is when you’re writing tasks or when you’re looking to organize these thoughts or pieces of feedback, have a really good way of describing the problem that you’re trying to solve, why you’re trying to solve it, what it looked like before, and what your thought might be on how it might look after. 

Even if that will likely change once you get into the design process, it helps to ground the idea a little bit better so there’s less time spent trying to figure out “What does this mean?” 

So it’s more like administrating the tasks and setting the parts of your platform that you want to focus on. 

‍Justin: To close it out, this whole thing is all about making Gather better for our customers. So my advice would be: Put yourself in your customer's shoes. Understand what their day to day experience is using your product. 

If you’re not getting the details right, then odds are pretty good that they’re not going to love your product. Or at the very least, not be as happy as they could be. So make sure you’re sweating the details on their behalf. 

‍

Overall, the team agreed that this kind of approach worked really well to resolve a lot of the bugs and issues that were causing bumps in the overall Gather experience. We are excited to continue sharing more of our process as we continue making Gather the best it can be, bit by bit. Be sure to check out our Pixel-Perfect Details: 116 Bug Fixes & Improvements blog to see everything that the team tackled.

Stay tuned for more live streams like this, as we are just getting started!

‍

Making things better, bit by bit.

- The Gather Team

‍