Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
Special Episode: Creativity and Connection in a Remote Workplace
The current pandemic has thrust many workplaces into adopting a remote-first attitude which they may not have been prepared for. Serendipitous events, like chance encounters at the water cooler or camaraderie built during lunches, not only help strengthen but also lead to improved productivity. Jamm is a startup seeking to rebuild these crucial social experiences for remotely distributed teams. Its founder, Badri Rajasekar, explains his motivations for the app, and why solving remote communication is about more than just video chats.
Rick Newman is a Director of Engineering at Salesforce Heroku, and he's joined in conversation with Badri Rajasekar, the founder of Jamm. Jamm was created out of a need for remote and distributed teams to not only work together, but for people to feel connected and invested with each other. Under the belief that remote teams were often confronted with a deluge of emotionless texts--from Slack DMs to PR mentions to email--Jamm makes it possible to send video messages to people in your organization. Meetings can also be open access, allowing curious individuals to pop in and join conversations, or allow audio-video chats to play in the background.
Badri recalls that, early in his career, he believed that the only way people could align together was to establish stringent processes. This could take innocuous forms such as "No Meeting Mondays" or mandating formal summaries after every meeting. But now he recognizes that a culture of creative freedom within teams often results in more organic unity. Creating this organization requires clearly stated goals and trusting that individuals will be able to execute on them.
There also seems to be an artificial tension between synchronous and asynchronous workflows. Badri argues that instead, organizations should recognize that each style of work comes during different periods. Synchronous workflows are often best defined at the beginning of a spring, where product managers, designers, engineers and the like can discuss what problem they're trying to solve. Asynchronous workflows can then go and implement solutions, review code, and ship deployments. Moving past this false dichotomy lets people talk to each other when they want to, not because they need to. Video chats then take the space of being a communication system people look forward to having with each other, rather than a meeting that they are expected to participate in.
Links from this episode
- Jamm provides video collaboration for remote teams
Rick: Hi, welcome to the Code[ish] Podcast. My name is Rick Newman, I am a Director of Engineering at Salesforce Heroku. I am here with Badri Rajasekar. He is the founder of Jamm and former TokBox CTO. He's joining us today to talk on the topic of creativity and connection in a remote workplace, and he is especially suited to talk about this with us. So we're excited to hear from Badri, it's nice to be able to talk to you.
Badri: All right. Thanks so much for having me on the podcast, I'm super excited to be here.
Rick: That's great. Would you tell us a little bit about the company that you started Jamm and what you're up to today?
Badri: So Jamm is a lightweight video collaboration application for remote and distributed teams. How do you have serendipitous ad hoc conversations? How do you assimilate those water cooler conversations you have, and just encourage a video first, a micro interaction across your remote and distributed teams, and that's what we've been working on. And like you mentioned in your outline, Jamm was also born out of a very personal need we face in a previous life, as it was working across a remote and distributed team.
Badri: This started out in my previous company, we started out as a small Silicon Valley startup, and at some point we got absorbed into this much larger global conglomerate called Telefonica. And I went from being part of leading a relatively small collocated Silicon Valley team to now suddenly being faced with the daunting task of coordinating across 10 cities and seven times zones globally. And it immediately became apparent to us that we run into a couple of major issues. One of the things being loneliness and feeling disconnected from the mothership is a real problem, remote and distributed teams and we wanted to find a mechanism to be able to solve that.
Badri: The other issue we commonly faced was, what I call this drowning in the sea of text, it's this stream of consciousness data on the workplace. It's incredibly noisy, whether it's Slack channels or Git commit threads or Figma comments. There's a lot of stream of consciousness data and conversations happening in texts, and oftentimes found ourselves at this position of, it would be so much easier if you could just rise above the den of that text noise and be able to quickly talk to people over audio and video. But at the same time, we didn't want the pain and headache of formal structured video conferencing.
Badri: And so we were always going back and forth between the Zoom video conferencing world and drowning and Slack type, text data. And so we really wanted to build something in the middle that would be a very engaging audio, visual connectivity system, where you can use video to have these micro interactions and actually collaborate. One of our engineers came and told me, he said, "Real work happens in between meetings, right?" And then he was just tired of jumping from one meeting to another and then catching up on email threads and Slack threads later on. So it was really trying to solve this product white space for micro-interactions that live somewhere in between Slack and Zoom. And that's really what we're trying to solve with Jamm.
Rick: So it seems not that it's a good thing but now that with COVID certainly your target audience has grown, almost everybody is remote. Has that had any change in your thinking or maybe in your learnings?
Badri: Yeah, that's a really great question. Unfortunate as it is, I think we've all been forced to go into this much more accelerated adoption of remote work. And I think a lot of organizations have been suddenly thrust into it and they're all trying to figure out what are the best ways to deal with that remote culture and remote work future. And I think one of the things that's becoming blatantly obvious from some of the COVID situation we have right now, is people's schedules need a lot of flexibility, right? It's very hard to be able to control your schedule in your current environment, you can't all make it to meetings at the same time and things like that. So I almost feel like we as organizational leaders have to become much more empathetic to creating a culture and a workflow which lends itself to people having very flexible schedules, right? So I think that's an important dynamic that's playing out in the workplace.
Badri: And I would almost add to it, there's this dichotomy that exists between a whole bunch of people having fatigue, meeting fatigue or people call it Zoom fatigue. It's like, "I don't want to be in a video conference day in and day out." So you have that dynamic going on the one end, on the other side you also have this dynamic that people miss that face to face interaction and so it is useful to have video on and catch up with people. And I think really what's going to come out of it is this recognition that the human centric approach in teams in terms of communication and alignment, it becomes important. And then it becomes the question of figuring out, what's the right way to do that in a way that it doesn't feel obtrusive. In a way that you don't have the pressure to always be on and available. In a way where it doesn't feel like things will be mandated by process, in a way that's just not natural to how people work and interact with each other.
Rick: With thinking about that, with everybody either being accustomed to or forced into participating in working on distributed teams, what are the problems you faced and have thought about and are trying to help out with? I guess, in your thoughts on how do you manage a distributed team? And it could be an experienced one or an inexperienced one.
Badri: I fell early on in my career, I think I fell into the same trap a lot of people seem to be getting embroiled in, which is trying to use process and relatively stringent process as some mechanism to drive alignment under modern distributed teams, right? And you can see this take a lot of forms, people say, "Hey, we are going to have no meeting Mondays." Or, "We're going to get everybody to write up a summary after each meeting ." Or, they're going to move to a memo based world. I think you often see some combination of process, but I think it's really important as we all go into this world to recognize that the bedrock of making sure you have a healthy and productive remotely distributed team is really boils down to building the right culture of trust and alignment and creative freedoms within teams.
Badri: It's basically the question of treating people like adults and making sure you have a culture of trust. And then if you're able to start from the basis and the question of, how do I create a team where people are aligned? How do I create a team where people have a high degree of trust? How do I create a team where ideas bubble up to the top? And then you layer on processes or workflows or systems in place to refine that experience. It's a much better alternative than saying, "We're going to somehow use process to solve the problem." So I think the first thing is the recognition that you want to build a culture of trust and creativity in a remote and distributed team firstly, and then productivity and all the other things flow out as emerging side effects of that culture of trust and creativity.
Badri: And so I think it's important to be very intentional and design that culture. And that could take a lot of forms, right? It's making sure you pick the right tools. It's making sure you have the right systems in place. It's making sure you set aside time for people to have these casual informal conversations. It's making sure you have a mission driven organization rather than a goal driven organization. It could take a multitude of factors but I think it fundamentally boils to being systematic and intentional about designing for their remote work setting to be successful, people in that workflow to be successful.
Rick: In your mind what are some of those steps that you can start to become effective in that way?
Badri: Yeah, I think it could take a multitude of forms, I think the first thing is creating an organization that is very clear about what their mission is and articulating the entire organizational structure around a mission rather than setting aside little goals and micromanaging people. It was almost interesting I was in a panel the other day, and a lot of the panel discussions centered around this question of, "Hey, people feel like their managers are looking over their shoulder." And managers feel like, "Hey, I really want to know if people are slacking off or being productive." And as I sat through all of that conversation, for me the entire framing of that conversation was strong. The very fact that people feel that way is it is symptomatic of not having a mission driven organizations, that's both on trust of how you empower different parts of a team with the right amount of end to end responsibility. Where once a mission is defined and a higher level path is set forward, each of these teams are able to execute with a certain degree of autonomy.
Badri: But at the same time, what you also want to encourage is what I call this osmosis of information across various functional teams. You don't want each small sub team to go off and be in a silo, even if they're being super productive. And so oftentimes what works is creating avenues of forums, where people can share things they have been working on in much more lightweight ways with the rest of the people. And this could be, "Hey, we're going to do product demos on Fridays." Or "We're going to send a recorded show and tele video of what we've been working on." Again, I think it's creating these right forums for this osmosis of information across functional teams is super important as well. Not only is it important for the best ideas to bubble up, but I think it's equally important for everybody to feel their voices are being heard, their ideas being heard.
Badri: And this is especially a problem in remote or distributed teams. You have this feeling that there's... And especially in hybrid teams where you're not entirely remote and parts of your team are remote. You almost have this, there's HQ and there's everybody else dynamic coming to play sometimes. And I think it's super important to be able to create these forums and avenues where people are able to bubble up ideas, and that also jogs a lot of creativity within teams. Like as people have these playful sessions where they're talking about what they're working on or a new prototype they built or, "Look what we did in our internal hackathon this week." I think that creates the energy, the culture of trust, the creative buzz happening. And it's all the more important to be able to create that buzz virtually somehow in a remote team, especially if you're not all in the same office where you can feed off that energy. That's the question, how do you create that energy in a virtual remote setting where everybody can feed off of each other's positive energy and be creative?
Rick: Yeah. What you mentioned about almost micromanagement, oftentimes line manager is your day to day managers. They're realizing that they were getting almost an accountability check for free, right? The classic there's butts and seats and we laugh at it, but a lot of us just do that. Well, I see them sitting down, I see them looking intent, I see them working. And when that's missing, suddenly that could result in micromanage. I can absolutely see that and I didn't realize that that would be a natural outcome.
Badri: And oftentimes you see this take really bizarre incarnations. In certain teams, I have seen like engineering organizations, especially recently mandate things like, "Hey, you need to come to work and then turn on your camera and be in a Zoom call." And I think all of those are symptomatic of the fact that... It's exactly like you said, it's butts in seats. It's like I want to see you be present and I think that's very unhealthy and they're much more nuance based with solving that problem. And I think fundamentally it's again, both centered around... It's a signal of lack of trust and culture in the organization. So when you see those sorts of things coming up, I think it's more important to double down and fix the root cause of the problem rather than try and patch the problem in superficial ways.
Rick: So obviously this is related to Jamm and the product and your product is aimed at this... Kind of want to think about ethos, that productivity springs from that cultural connection. And I can assume and hope that Jamm uses the product internally.
Badri: That's right, that's right. We are an extreme case and I joke with people, it's almost as if we took a world map, we picked the worst possible our plan route, and then decided that's where we want to set up our teams. So we are literally spread across San Francisco, Barcelona, and Sydney. And if you actually think about the time zones, there's probably 60 minutes a day of where we can all be online together at the same time. And so it's a pretty extreme version of a remote team but that's exactly right, like we wanted to dog food Jamm in a way and to some degree it's what you mentioned, the way we sold as a Jamm is enabled people to have these lightweight micro-interactions, but I want to talk to you for a couple of minutes and say, "Hey, I checked in this code, do you want to just push it to pre-prod and test it out?"
Badri: And somebody else can do that, and they come back to you a couple of minutes later and say, "Hey, I pushed it to pre-prod but A and B and C was happening." And so we can have these lightweight micro interactions over audio and video without having to necessarily schedule a meeting or jump onto a conference call. And one of the epiphanies we had was what I call the multiplayer problem. Especially if we are developers and designers and product managers, we are using the keyboard a lot. We are coding or we were on the terminal or we were on Figma using design. And so essentially what you almost want the audio video condensation to be a secondary experience.
Badri: So it's not like you're sitting in a video conference, you're basically working on your stuff. And then video just happens to be a secondary experience, very similar to how if you're playing a multiplayer game, you could be in an audio video channel with your buddies but you're actually playing the game. And coding or designing or code reviews or power program, all of those are very similar concepts and so we tried to incorporate some of those things in Jamm to create those lightweight experiences where you can be focused on what you're doing, but have a simple, lightweight way where you can communicate with other folks. And we also have a whole bunch of discovery built into it, it is exactly like you said. Can be reading presence in interesting ways if, A and B are in a conference room and are chatting, can we show those visual presence in interesting ways within Jamm, just so you feel there's activity around you. You can see people talking to each other, you can crash those meetings and we tried to facilitate a lot of this serendipity in conversation.
Rick: I really like what you just mentioned about that serendipity, and being able to create, just see that activity. I'm not particularly outgoing or social, but I really enjoy working from a coffee shop just being around others and seeing that is a lot more clear than looking at a nine individual's calendars and seeing what they might be doing in a given hour or afternoon.
Badri: That's exactly right and we often find that it's just a mere fact if you see people having these conversations or you have these audio visual cues of what people are doing, it's super important even if you're not participating in any of those conversations is exactly right. It's the coffee shop effect, I guess.
Rick: What have you learned, and maybe this would seem like a little bit of I'm fishing for a feature but I'm really not. What have you learned, say over the past year that might have affected how you think about the product especially as we mentioned at the beginning, just due to COVID you likely have a lot more input from interested parties.
Badri: If you look at a lot of the conversations that are happening within the remote work community, one of the important conversations everybody seems to be having is this tension between synchronous workflows and asynchronous workflows and you see this all the time. And in fact the more mature, fully remote organization you are, the more asynchronous you tend to be. A classic example is an organization like GitLab where they say, "Hey, you know what? Everything's got to be asynchronous." And they're a fully remote team and we're going to design everything around being asynchronous. And it's an interesting conversation that's happening, the remote work field. And our view and our learning has almost been this ebb and flow of synchronous asynchronous, it's a false dichotomy. And if you actually notice it, the synchronous and asynchronous workflows actually happen within a productivity cycle or within a sprint. In the early half of the sprint, let's say you were talking to product managers about a feature and design and you're talking to the rest of your team more like architecture instead of aligning on the design itself.
Badri: There's a lot of synchronous conversations that happened during the ideation and requirements collecting phase. And then when you're actually heads down building the product and you're actually coding and you're actually building it, what you want to do is you want to go into deep work. You don't want a whole bunch of distractions, you don't want people bothering you. I'm going to put on my headphones I'm just going to be coding, I'm going to be turning code out. And then once you're done doing that, maybe you want to show off what you've built and some sort of a sprint. So if you actually think about the workflows, the workflows themselves alternate between periods where you want to have a lot of synchronous back and forth conversations, and there are periods where you want to be heads down, focused, deep work, where asynchronous work close makes sense.
Badri: And so one of the learnings for us has been this false dichotomy between asynchronous and synchronous and so what we have done is build Jamm in a way that you could do both live calls and quickly talk to people if you wanted to. Or you could actually leave them recorded audio, video messages or create show and tell messages and support a fully asynchronous workflow. Purely because we ourselves are going through periods of high synchronous activity and periods of high asynchronous activity. And I think that's been an interesting dynamic that has come out of how work has evolved of late especially.
Rick: Like you mentioned, you've really embraced that even with the geography of the company. Referring back to these little micro interactions and these quick videos that you mentioned, what's the most interesting example of one of those that is either you've seen or is maybe even common at Jamm?
Badri: Yeah. There's a whole bunch of interesting examples, I mean some of it are fun then trivial and some of it are a little bit more obvious. One of the things we see a lot of patterns even with a bunch of other teams we closely work with is asynchronous audio video messaging is often used to go through a whole bunch of bug repro steps. Like when something happens, instead of writing these long-winded convoluted repro steps, oftentimes you see people actually recording the reproduction steps and actually posting it. And so it becomes super clear in terms of what happened, what environment they were on and what they were doing and things like that. We also use this sometimes to actually resolve contentious pull requests.
Badri: Somebody was telling me the other day, there's no feeling of victory like merging a pull request, which has been open for 30 days and it has had 500 comments. And sometimes what we do is as part of the pull request thread, there are these recorded voice and video commentaries of people actually even explaining their comments and talking about their own design philosophy and saying, "This is how I would have done it." Or, "Here's is how the locking mechanism should work." Stuff like that. And so I think that layer of color and context is super useful to not feel like it's a battle of ego between ideas in a pull request.
Rick: Right. I'm sure others do this, is it takes me so much longer to write out maybe the reasoning behind an abstraction than if I can just talk for a couple of minutes and wave my hands a little bit.
Badri: And even these hallway conversations and these synchronous conversation discovery is useful because oftentimes when a couple of people are quoting an idea they're going back and forth. But other people who feel like they're missed out of the conversation as they see these frequent conversations, crash those meetings, and they're like, "Hey, I noticed you guys are having these." Honestly maybe I need to be in the loop too. Well, that's good and bad, for the most part I think it's very healthy to have the discussions just like you would in a physical co-located space. You see somebody talking, people come up to your desk and join conversations all the time. All of those interactions have been interesting on the more trivial side, we have all kinds of videos. Oftentimes on Thursdays, people send out cocktail recipes of the latest cocktail they did. But what we want is a live video of somebody actually being a mixologist but there is-
Rick: And making it.
Badri: And making it. And we do a lot of pretty fun, silly things internally.
Rick: I bet everybody gets over this, one of the things I noticed in this switch to everybody working from home and has canceled all conferencing events that we do an awful lot of interaction with. And they've had to shift to just either pre-recording these conference talks that they would give or doing on video when they prerecord, I'm starting to see a tendency of now it's got another recording has to be perfect because for some reason, in our head when it's a recording, it just has to be flawless as opposed to when I get up and talk, it's a mess. And I stumble over words and I forget where I am in my outline and it's totally fine. I assume that that is just a small hill that people get over eventually.
Badri: That's a great point, it is a very nuance behavioral aspect and I think people actually get over that fairly quickly for a multitude of reasons. I think you are much more cognizant in terms of the production value of your content, if it's going to be broadcast out to a much larger audience, versus I'm going to record something quickly with the three other folks I most closely work with. You are a little bit more open and free and you don't have to worry to much about the production quality of things. Also, this is another interesting use case I didn't mention, sometimes when we're deploying code there's one or more people deploying code at the same time, they're all in a lightweight floating heads expedience in Jamm. Where they're in a conversation with each other and they're actually deploying code, but as they come to the important steps in the deployment process, they also record little snippets of the deployment process itself.
Badri: So you almost have this audio visual audit trail of what happened in each deployment, which is super interesting. I haven't seen a lot of organizations do that, but we actually do that and find it incredibly useful to actually have a visual view of the deployment process itself and what got deployed. Did I make the schema changes, did I miss out something, did they run this config script? It's super interesting, even as an internal knowledge base, as a mechanism to institutionalize and memorialize internal knowledge, it's an interesting mechanism.
Rick: Well, this has been a lot of content and I'm positive that some of the individuals listening in are listening almost with some desperation. If they've encountered over the past three or four months a new reality in remote and distributed work, it might have been completely unfamiliar to them. And obviously you and your group at Jamm give a lot of thought to that. Do you have advice either line managers or individual contributors, employees and companies, some steps that they and we can take to build a better environment for where we are now?
Badri: My advice to individual contributors first and foremost is to say, you really want to focus on yourself and make sure that you have a strict separation between work and sort of not work. And it's almost becomes even more important right now to schedule time away from work, you know what I'm saying? Otherwise the entire day is one giant blur, which never seems to end. And of course we all have those days closer to release times and things like that. But I think it's super important to be very cognizant to say, "Hey, you know what? I'm going to set aside 30 minutes in the middle of the day to do yoga." Or, "Go for a walk, brew a cup of coffee." It's super important to be able to sort of schedule time and be cognizant of not just having this one giant blur of a day. I think it's also important to be effective in your communication because again, one of the things is it's easy to fall out of the loop or not have alignment with the rest of your teammates.
Badri: I think it's really important to actually step up and communicate a little bit more frequently than one would normally be used to communicating, I think those two things is super important. And if you're leading a remote engineering team, I would say it's super important to focus on the cultural elements and very important to be empathetic to people's schedules. It's not fair nor is it practical to have these super strict formal schedules and things like that. So I think it's really important to devise a system where your team has the breathing space and the flexibility in terms of their own schedule in a way about you are also able to clearly articulate what outcomes you want from the team, but then empower them to be flexible and do it in their own time. I would say those are the more crucial elements, of course I could give a lot of little snippets about process and things like that. But I think these two core elements have something I feel quite strongly about.
Rick: well, thank you for being on this episode of Code[ish], Badri, it's been a real pleasure. I have a personal interest, I think you and I talked about before we were recording in this and I find it fascinating and love the... Though like you mentioned, it's not the greatest environment that this is happening in, but I love that a lot of people and companies are moving this direction and being more thoughtful about how we interact and the important principles behind how we interact and how we can find new ways to do that. And not just mitigate the problem, but embrace the environment and to come out actually ahead, find a deeper productivity, find a deeper connection. And I think there's a lot of opportunity here and I'm really glad I got to talk to you about it.
Badri: It's been fantastic having this conversation with you Rick, and I really appreciate you having me on the podcast.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
More episodes from Code[ish]
118. Why Writing Matters for Engineers
In this episode, Ian, Laura, and Wesley talk about the importance of communication skills, specifically writing, for people in technical roles. Ian calls writing the single most important meta skill you can have. And the good news is that...
117. Open Source with Jim Jagielski
Jim Jagielski is the newest member of Salesforce’s Open Source Program Office, but he’s no newbie to open source. In this episode, he talks with Alyssa Arvin, Senior Program Manager for Open Source about his early explorations into open...
116. Success From Anywhere
This episode of Codeish includes Greg Nokes, distinguished technical architect with Salesforce Heroku, and Lisa Marshall, Senior Vice President of TMP Innovation & Learning at Salesforce. Lisa manages a team within technology and product...