Remote Team Productivity

Vineet Kumar, Keerthana AK, Saumya Dubey, Catherine Madden at UXDX Community: Bengaluru. Video: https://youtu.be/JmHaXzBdAkA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Welcome and panelist introductions

[00:00:00] Catherine: Hi, all, and welcome back to the event. My name is Catherine, and today we're going to talk about remote team productivity. It's an interesting time for all of us, certainly with the events of COVID. We're going to look at what the teams and companies joining us, and the people joining us, are doing, both in the short term and the long term, from a productivity perspective, from a team structure perspective, and also whether it has changed or shifted their perceptions on recruitment, or how, going forward in their business, they're going to adapt for the better.

[00:00:40] I'd like to welcome all of our panelists here today, and hopefully you've had a chance to watch their really insightful talks. Vineet Kumar, he's UX director for Postman. Keerthana, she's product manager for Zynga Games. And Saumya, who is principal product manager for Swiggy. So welcome to you all, and purely because you're on my top right, Vineet, I will start with you to do an intro, and you'll hand over to Keerthana.

[00:01:11] Vineet: All right. Hey, guys. I work as the director of UX at Postman. I've been one of the lucky guys who's been around since Postman was a team of ten, so I've had the opportunity to see a startup scale from a team of 10 people to almost 300 right now. I love building collaborative experiences, whether they're digital or physical, and I think just conversations between people are the biggest game changer for anything that happens in the world. But yeah, that's a quick intro about me.

[00:01:50] Catherine: Great. And Keerthana?

[00:01:56] Keerthana: That was a great intro. My name is Keerthana. I work as a product manager at Zynga. Like Vineet, I've been part of a startup prior to this, actually two startups. My earlier startup had an exit. I was in a team of three, and I grew it to a team of about 22, and we had a successful exit, so that was one of the things I'm really proud of. And I'm leading somewhat of a startup within Zynga itself. So yeah, that's my intro.

[00:02:29] Catherine: Right. And Saumya?

[00:02:31] Saumya: Hi. Hey, folks. Saumya here. I'm principal product manager at Swiggy, and I lead the Instamart charter [?], which is Swiggy's own grocery delivery offering. I've had mixed experiences. When I started, Swiggy was, I think, 10 PMs, so I was probably in the first 10 PMs. And after that I've seen Swiggy grow by leaps and bounds as a company. And then I got lucky again when I could become part of Swiggy's new initiatives team, and since then I've been leading their grocery offering from the product team.

Team structure at Zynga and remote by COVID

[00:03:03] Catherine: Yeah, all three people with very different backgrounds in ways, and I know there are some interesting and varied thoughts on this topic, so I'm looking forward to getting stuck in. Keerthana, we'll start with you. You described your team at Zynga as being a startup when we last spoke. For the audience listening, could you explain more on what the structure at Zynga Games is, and what it's like?

[00:03:32] Keerthana: Sure. My team is slightly different from the other teams at Zynga. My team builds new games in a niche space. The way my team is structured, it's a mix of engineers, UI/UX, game designer, content designer, artists and testers. This is how my team is comprised. We are still exploring how to get the most efficient process to do this, so that's why I'm saying it's a startup mode and not a scale mode. That's how we are different. And the aim is to build games fast, on par with the competition's quality, and with a lean team. So this is how my team is.

[00:04:15] Catherine: Interesting. And are you a remote team by default, or by COVID?

[00:04:25] Keerthana: Right now at Zynga we are remote by COVID, not by default.

[00:04:34] Catherine: And will that change, or will you go back into the office in the future?

[00:04:38] Keerthana: Sure. The way the communication is right now, the company will take a call on it based on how the situations are locally, because everywhere it's different. So based on how it progresses and how things change in individual places, they're going to take a call on starting the offices. And they're also saying there's no pressure to continuously work out of the office. So that's how it is right now.

[00:05:02] Catherine: It's a really good way of looking at it, and from how we spoke the last time, it's really positive to hear. And I hope it continues, the low case rates and everything, so I hope everyone's on the way out of it, but it's nice to hear.

Tripling a UX team at Postman during the pandemic

[00:05:16] Vineet, you've an interesting story on your team. Since you started, and COVID hit, you've tripled in size, if I'm correct. Tell us about the structure of that and what have been the challenges of navigating through recruiting in a virtual world.

[00:05:36] Vineet: Right. The UX team at Postman started 2020 with a team of five and quite a flat hierarchy within the team itself. I think as we grew, we have had to bring in a few lead designer roles, essentially to help mentor and onboard the newer members. I think the biggest challenge has been a lack of organic sources for context. In an office you could always depend upon workplace conversation or water cooler conversation to build a better idea of what everyone's working on. Without that, we found we had a few people who weren't necessarily aware of what's happening in the rest of the team. So we've had to consciously move away from low-context meetings that involve lots of people, and instead focus on smaller groups, make people work together in pairs.

[00:06:34] Hiring has also been quite a transition. It's been quite unreal hiring someone who you have never met face to face. Since almost two-thirds of the team joined after the pandemic, we have never really met each other in our lives. While this hasn't necessarily affected our ability to assess talent, it has been quite a strain when it comes to gauging culture fit. I just feel that it's a bit of a hit or miss a lot of times, and it's much harder. You have to invest a lot more in communicating your company's culture on a day-to-day basis with these new hires.

[00:07:19] Catherine: Yeah, it's a very interesting one, and we discussed it. Our team here, Louise started purely in the same situation as you, completely remote and online. But I feel that comes down to the personality of the individual in terms of their self-drive and motivation. Which obviously Louise is good at, because she's listening. But she's great, and I feel like I've worked with her physically, and we haven't actually at all, really. Is there anything that you look for to get that type of talent? Has your perception changed on who you hire, and will it change in the future?

[00:07:59] Vineet: The way I see it, in my experience there have been two kinds of people, both within the team and in terms of the candidates that we have looked at. One set of people are eager to take initiative, learn about things that they might not be working on directly. And then there's another set of people who gain this context passively, as I mentioned, through water cooler conversations and stuff. I think the transition was much easier for the first set of people, but for the latter we've had to find ways to replace that feeling of working right next to each other. I do think that our recruitment process has maybe subconsciously leaned towards hiring people that I described first: people who can take initiative by themselves, who are slightly more independent, outspoken, and just generally communicate more effectively.

[00:09:03] Catherine: Does that restrict you to a personality type?

[00:09:07] Vineet: I hope not. I don't think I've seen that yet. We have had quite a diverse pool of hires since the time the work-from-home policy started, so I haven't really seen that yet, which is a good thing.

[00:09:23] Catherine: Yeah, no, it's a great thing, because that is the fear.

Shipping fast at Swiggy: principles and empowerment

[00:09:27] Saumya, I'm going to get to you now. In your talk you spoke about shipping fast, in fact accelerating your shipping during remote times and during COVID, and you had some great success with this. For anyone who's listening in, I would encourage you to listen back to the talk. But what are the key factors to that success when it comes to the way the team works together remotely?

[00:09:56] Saumya: I think I'll extend a bit from what Vineet was just saying. Because of the remote setup, that common talk that was happening in the hallway goes missing, and that's one of the biggest things that starts breaking in your team relations. So to get that right, what we started doing was emphasizing a lot more on clearly defining the principles, the goals and the priorities for the team. When we had a big project, we made sure that everyone understood that shipping it in 60 days was a lot more important than building the right platforms at that given point of time. The same principles could be very different for a different product or a different initiative that we are taking, but having that common language across the team, on knowing what we were doing and why we were doing it, was super crucial.

[00:10:43] Because of just having this common language, we didn't really have to be as prescriptive. You didn't have to get into the L2 details, and the teams could run a lot more decentralized. For example, with Instamart we actually had the case where design was still getting closed, but engineering could get started. And we still didn't have any throwaway code, or problems of "oh, we built something wrong". That didn't happen, because that set of principles, and how we are thinking of the product, was so clear to everyone.

[00:11:12] The second thing, which is very important, is that in this environment you should be focusing on empowering people more. What happens at times is people end up micromanaging, because you just don't know what is happening. And this is the biggest mistake you could make. Anyway, people are feeling less connected, and you are working harder to make people feel connected and passionate about the same goal. If you go about micromanaging, it just backfires immediately. What you need to instead do is give them higher ownership, but have the right processes and cadences set up for reviews, where everyone comes and showcases what they did, versus someone checking with them, "Hey, are you done with this? Hey, are you done with this?"

Kanban, visibility and clear communication

[00:11:53] Catherine: Yeah, it's important. It is a really interesting one. And Keerthana, you've talked about a similar piece on working within your team and working like a startup, and you're still defining your process. Do you have anything to add, in terms of whether there are different challenges in an agile team like that?

[00:12:11] Keerthana: Yeah, definitely. I totally agree with what Saumya said. We need to empower and we should not micromanage. That is very, very important in a setup like this. One challenge for me is I cannot define a longer-term roadmap, because I don't know what's going to come next. That's very different for me. And there is no defined way of execution, so the cadences are still not set up, because sometimes what happens in a place like this is the cadence itself becomes a bottleneck for us. So that's very important, because I cannot define it right now.

[00:12:49] Some of the things that we have implemented are for these kinds of situations, where the team already doesn't have a very good social life, social connect, and they're already in a place where it's very different for them. How do we ensure that we don't pile on top of it? Some of the things that I've done: one, because of a continuous change situation like that, we don't do sprints, we do Kanban instead, so that there is a continuous list added on top of each other, and anybody can pick up the tasks after their work is done. That is one thing that we've done.

[00:13:30] The other thing that I've done is that the team needs to have clear visibility on their immediate tasks, even though the larger roadmap is not there. At least they should know, what should I do next, and it should not be very ambiguous. So that is something that I make sure is there. It's not just visibility; prioritization is also important. If you don't prioritize, you will micromanage. So that's something I make sure of: I prioritize at the beginning of the day what needs to be done, and then I just sit back. I don't go and be like, okay, have you done this, have you done that. That's not required as such.

[00:14:05] The most important thing for me right now is very, very clear communication. It is so easy to be ambiguous, and it is so natural to be ambiguous. When we are in front of each other in the office, we just go and say, do this, do that, blah, blah, blah, and then after five minutes it's very easy to come back and ask, what did you mean? But right now that situation is not there. So the communication has to be on point. There should be absolutely no room for ambiguity while talking and while writing your specs or whatever it is. Otherwise it's super difficult right now. It'll end up in hundreds of Zoom calls, unnecessary calls, everybody's productivity being lost. So these are some of the things that we as a small team are ensuring we do, so that our productivity is not hit.

[00:14:58] Catherine: Yeah. Vineet, do you have anything to add to that?

[00:15:02] Vineet: Yeah, I think everything that Saumya and Keerthana mentioned just reinforces a few of the things that we've been doing. There's been a very strong stress on documentation of everyone's work. There's no relying on meeting notes anymore. Almost every meeting note transitions into a more formal form of documentation, just so that everyone's on the same page. I think in my talk earlier I had also alluded to the fact that we use Jobs to be Done as a way of building consensus as well. So any tool that you can use to build that consensus and get everyone on the same page, I think that becomes a lot more important in a remote team.

Prioritization and the power of saying no

[00:15:47] Catherine: Yeah, I think it's a good point. I'll just take a quick second break to remind people, if they've got any questions, I'm looking at the channel, and the team are also here on Zoom to ask your questions, so please feel free to ask them. This is a nice opportunity. Saumya, I'm going to ask you, still on the same topic of prioritization and alignment really: how do you prioritize, or what's the biggest learning or piece of advice you could give to people on prioritization to improve release times?

[00:16:27] Saumya: I think PMs don't do as bad a job at prioritization, but do much more of a bad job at communicating what was prioritized, and that is where they end up losing a lot more time. This is something that I feel happens so often: just because you had a meeting, and just because you didn't share an MoM email saying this is what we exactly aligned on, the same discussion will come up a week later, and another week later. And then you do a retro exercise of figuring out what happened. There are so many of these things where you lose time. All of this was not necessary if you just communicated what your priorities were.

[00:17:05] Now, answering your question a little more directly, on how we went about prioritizing. I think it's slightly linked to the first answer I was giving you, on defining the principles and the goals. I think Vineet had it in his list in his presentation, or someone else did: you not only need to define what we are going to do, we should also define what we will not be doing. That's where a lot of the gap happens. For example, while building Instamart, we said that we want to solve for the weekly and urgent needs of consumers, and we also explicitly put that we are happy if we are not solving for the monthly grocery needs of consumers.

[00:17:46] So saying no is in fact a lot more important, and not only in your product specs, but when you are taking up new discussions with your business counterparts or your engineering counterparts. A lot of times it's just so easy to say, "Hey, we'll park it for now, and I'll come back to it in a couple of days." And that "come back to it" is what you're doing with bad prioritization. Because of that bad prioritization, someday you are going to have a huge backlog, if not in your notes, then in someone else's head. And they are going to come back and eat your head on why we are not doing these things: "You promised me it was going to happen this month. You promised. We discussed this six months back," and so on.

[00:18:22] This is so much time and energy that you waste, not only of yourself but of your whole team, by getting into these questions, which you could have just solved by saying a simple no, by giving a logical note, by giving the reasons for why this is a no and how it links to our overall objectives, the goals of the team, et cetera. Delaying that no is how you do bad prioritization.

Documentation, silos and reading sessions

[00:18:46] Catherine: Yeah, it's a really good point. And I guess that is, as you said at the very beginning, what defines a good PM and a bad PM. And it's a question that Vineet brought up, but can you over-document? Is there a risk of slowing down?

[00:19:03] Saumya: I don't think it's over-documentation. It's not communicating sharply. That's what PMs tend to do, just because you've been asked to document. For example, if you were to write the minutes of a meeting, it does not mean that you become like a typewriter and just type every word that was spoken in the meeting. You are supposed to understand the crux of the discussion and drop in a note on the highlights. Similarly, if you are running a huge project, of course there are 10 breakpoints of that project and there are statuses attached to each one of them. But what your leadership really needs to know is, A, is everything green, and B, if there is a blocker, how can I unblock you?

[00:19:46] People don't end up doing that summary job well, and think, hey, I was communicating so much more, and still things were not landing. I feel that while communicating, we also need to think like PMs building a product: what is it that your user really wants to hear, and what do you want your user to hear? If you think of your stakeholders like users, I think your communication becomes a lot better, and then the over-documentation bit isn't a problem that you'll have to worry about.

[00:20:17] Catherine: Yeah, it's interesting. Vineet, did you have anything to add there?

[00:20:21] Vineet: A more realistic fear, at least in Postman, has been documenting in silos, where everyone has their own version of a spec. Typically what we do in Postman is, for every product spec you'd also have associated engineering and design specs, where each one addresses a different thing. But the problem is that because these are three different documents altogether, there's a very realistic fear of them each developing the feature in their own way. And that just brings me back to the point of using any tool you can to gain consensus and bring everyone onto the same page. In our case, I think it's mitigated by the fact that the product team, which includes the designer and the product manager and the engineering manager, works together all the time. Your product team is your family in some sense, so those kinds of divisions don't arise too often. But I can totally see that happening.

[00:21:23] Saumya: Yeah. One more thing that helps to avoid these silos is doing a lot of reading sessions. For example, this was something I used to do even two years back, when we didn't have remote work, where I would just get all the engineers in a room and say, for the next 20 minutes we are just reading this spec doc. No one is talking, no one is giving you a walkthrough; let's just go through this doc. Because otherwise someone will skim through it, someone will just see a couple of comments, and things get missed all the time. And even if I am giving a walkthrough, there is a good chance that I missed an L2 or L3 detail. So I always love to do that: let's use the next 15 to 20 minutes to read through the doc. And I found it to be a lot more efficient and effective in getting the point across.

[00:22:16] Vineet: There's another thing that we do around demo days. We feel like pitching an idea should always be done through a demo. The more someone speaks about it, the more points of feedback you'll get, or the more resistance you'll see. It just acts as a conversation starter for a lot of things. Sorry, I interrupted you.

[00:22:38] Keerthana: I was just saying that's actually a great point, because that's something I've been trying to do remotely as well. The spec is usually a living document, especially in my case, where there are a lot of changes. Simple things like putting it online in Google Drive solve a lot of problems where things happen in silos. And in my last phase I told them that if I don't see even one comment on the spec, we will not have a meeting about it, because I need to know that everyone is reading the spec. Otherwise, like Vineet said, everybody works in silos, and everybody has their own version of what it is going to be, and it's all in everybody's mind. So that's something that we've been trying to do remotely as well: any time a meeting for a review is set up, everybody has to read the spec, and then we assume that it's been read and start the meeting.

Tools: Google Drive, Confluence and reading slots

[00:23:34] Catherine: Yeah. And are there any tools that people use? We use Notion here for our documentation. What do people use that they find useful?

[00:23:42] Keerthana: For us, we use Google Drive, and for specs we use Slides, and I don't see any challenges with that right now.

[00:23:55] Saumya: Yeah, the same suite for us too. What I found is more important is just having any online tool where people can add comments. Anything would do it. I think Confluence has also started supporting that. But what is more important is Keerthana's point of making sure that people either have read the document before they come in, or, in the meeting, you block 15 minutes at the start to say, hey, you need to read the document now. Especially with leadership discussions, we've gone to the limit where, one day before the meeting, I have blocked half an hour or one hour in people's calendars and said, this is a reading slot. This is a 20-page document; please spend the next hour reading it, and don't come into the meeting without reading it. Just that makes the biggest difference.

[00:24:42] Keerthana: That's a great idea. I will also do that, because how do you make sure that they're reading?

[00:24:50] Vineet: We use Confluence. I think we've used Confluence for the longest time. The good thing about Confluence is we found it easy to use as a knowledge repository. Everyone has their own space, and everything just keeps building onto it. Everything that is set in stone, essentially, should be documented on Confluence, as the source of truth.

Self-reflection: what the panelists learned about themselves

[00:25:16] Catherine: Yeah, I think Confluence is a nice integration piece as well, with everything else. Because we have to wrap up quite soon now, I'm going to put a self-reflecting piece to each of you, and Keerthana, I'll start with you. You've talked passionately to me and Tiffany [?] about your team being driven, that they're the most productive they've been during COVID, and that you're worried about burnout. But you never actually talked about yourself. Self-reflecting on this COVID time, what have you learned most about you as an individual, and you as a leader in your job?

[00:25:58] Keerthana: There are two questions, so let me answer the first one. What have I learned about myself? The first thing I've learned is I can stay at home for long periods of time. This was a big fear I had, how will I stay at home, but I think now that is possible, so that's a great learning. I believe that working remotely is not as bad as it is made out to be, if you're able to adjust and balance your life. While working in the office, there was a big commute, going and coming back. It was a huge headache. Right now we have time for ourselves. Either we can grow professionally or we can grow personally. I myself have been running, so that's a great thing. I never used to do any exercise, so that's something that's been good. And also I see that it is less overwhelming working like this, because I'm not constantly looking at a lot of things around, a lot of people around. I don't see that as much, so it's easier for me to take a break when I want.

[00:27:09] So these are some of the things that I've learned. The other thing that I have learned personally is how important communication is. Even before working like this at Zynga, in my previous startup I also used to work remotely, and that is when I understood the importance of effective communication. Just be on point. Like I said earlier, there should be no ambiguity, especially as a PM. The moment I say something ambiguous, three people will think three different things, and they'll go in their own different directions, and then they'll come back to me and say, "This is what you said." So it is very, very hard to deal with such situations. I make sure I am saying exactly what I want, and I'm also writing it that way. Like I think Saumya said in the beginning, we need to think of executives as users who are reading our emails, and be on point. The same way, I think of my team: when the engineer is reading this, what will he assume, what will he think? And based on that I make my comments and stuff like that. So communication is one really important learning that I've had with this kind of work.

[00:28:18] Catherine: And it links to what Saumya was saying as well around documentation. People need to be smart enough to know the outcomes of it, and that it's written down correctly and perceived correctly. Saumya, how about you? What self-reflection have you done?

[00:28:34] Saumya: I think the biggest reflection has been that you can do a lot more in the 24 hours you have. I started realizing this because for the longest time I didn't have any maid or cook coming in, with the pandemic, so no house help. I was doing my dishes, cooking everything all by myself, and was not really ordering in and all of that. And that made me realize that I was doing all of this, and at Swiggy this was a really bad time at the start of the pandemic. We had to ramp up our grocery business from three cities to 300. We saw a big problem in our food business. So I was working 12 hours, and I was doing all of this. So I realized how much more I could do in 24 hours if I could just be more focused and avoid a lot of things, a lot of meetings which I felt were not useful.

[00:29:26] And from that comes the second point. Because it is so hard to gain attention in a video call meeting, versus in person, where it is much easier to just be focused on what you're doing, I realized that it was much easier for me to tell when a meeting was not effective, not only for me but for the audience. I started questioning frequently: is this meeting required, or can it be an email, or can it be a Slack discussion? Initially it was really hard for me to say on a meeting invite, "Hey guys, can we do it over a Slack discussion, or can we just make a small group and close it?" But I realized, once I started doing it, A, a lot of people also found it useful, and B, I ended up saving a lot of time and energy for myself. So those were the two biggest reflections I had.

[00:30:14] Catherine: It's really positive. I love it. I'm going to take some of your advice. And we'll finish up with you, Vineet. What have been your thoughts?

[00:30:29] Vineet: I think Saumya touched upon it briefly at the end, but the biggest thing I've learned is that it's good to say no in a lot of situations. It's good to say no to a meeting that goes over lunchtime. It's good to say no to a deadline you can't meet. It's much more important to say no than to say yes and not meet it. And I think that's what, at the end of the day, causes a lot of friction within teams, and with remote work. If you can communicate effectively, and saying no is a big part of communicating effectively, I think it just solves a lot of problems.

Taking breaks and removing the guilt

[00:31:02] Catherine: Yeah. You've spoken about how you never actually get a break, because people assume that you're always on, whether it be on Slack or wherever. And then Keerthana, you're the opposite: you have your 90-minute break. So they're very different perspectives.

[00:31:20] Keerthana: But I did not take a 90-minute break. I'm asked to take a 90-minute break. So that's the difference.

[00:31:28] Catherine: You have the option, though.

[00:31:32] Vineet: Doesn't sound like I have the option. I think earlier, when I used to take those breaks, there was this feeling of guilt, and I was assuming that if I could feel it, everyone in my team would feel it as well. But it's been really important, not just for me personally, but also to communicate to the rest of the team, that sometimes you really need to do it, for your own sake. And it's not very easy for you to assess that and reflect on that all the time.

[00:32:03] Saumya: And to add to that, I think it was a lot easier to take breaks in the office environment. Just going from one meeting room to another meeting room was a two-minute break. Now you immediately jump from one call to another, and because you are waiting on the call, that one minute of starting the meeting late is so apparent. You're just continuously looking at the screen and moving from one call to another, and that break never happens if you don't consciously take it.

[00:32:29] Vineet: We had this idea floating around that the first five minutes of every meeting should just be preparation time, because otherwise the guys who have meetings back to back are just going from one context to the other in 30 seconds. It never really materialized, but we try and do it in some places.

[00:32:47] Keerthana: A lot of these things are just illusions right now, very ideal situations, I feel. The only thing I've seen working is consciously saying, I need a break, I need to take a break, and my team needs to take a break, because a lot of times they forget to take breaks. So I say, guys, it's okay, don't work today. It's already eight o'clock, it's already seven o'clock, don't work anymore today. I just go and tell them like that.

[00:33:11] Catherine: Oh, it's really good. We do have to wrap up. Vineet, I think it's a good one, actually, just as an end note: to spend the first five minutes of meetings, as was discussed earlier, in silence, and maybe prepping for that. I like that. There are a few questions on the Slack channel. Shubham has asked some, and we haven't got to them all. Saumya, there's one there specifically for you, and for all of the speakers, I'm sure he'd appreciate it if you could go on to the Ask the Speakers channel and just respond to his questions. And if anyone else is there, you can grab the amazing speakers while you have them. Thank you all for that.

[00:33:56] I think the one piece that I've found out of it is: remove the guilt. I think as human beings we all feel guilty about not doing this and doing that. I think if 2021 could get us anywhere, it's to remove that feeling of guilt, forget about it, and move on and move forward. Thank you all so much. It's been a pleasure every time talking with you, and I'll hand back over to Louise now.