I had the pleasure to meet Rakesh Kasturi, to address some questions that came up on LinkedIn. Centered around remote collaboration, we had the chance to address how to bring people together in a way that allows people to connect online and builds trust - even if you're stuck in home office. We thereafter turned to distinct questions along the design cycle (how to empathize, how to ideate, how to prototype). And finally addressed whether certain workshop-formats are doable in remote settings. But before we go into the details let me introduce Rakesh briefly:
Rakesh Kasturi, aka the Sprint Doctor supports business leaders in creating cultures of collaboration and self organization - and this extends to the remote side of things. Therefore I thought he'd be an awesome candidate to address the most pressing questions on online collaboration.
JOIN MY MAILING LIST
When I asked Rakesh whether he prefers Mural, Miro or Whimsical, this is what he said:
"If you ask me, I'm looking for a nice, fun user experience. For me it has to be Mural. I see that people get on very quickly. There's no major learning curve needed - you can just jump in. You learn how to create a post it and you're good to go. That's the simplest thing, but it does have some feature shortcomings and there Miro provides a smoother interface. Miro has an a slightly more serious look. Whimsical I haven't tried it, honestly, so I wouldn't know."
After establishing that Rakesh prefers Sharpies over Pentel-Sign-Pens in real life we turned to the hard question on online collaboration:I asked Rakesh how he goes about virtual trust building amongst team members, especially if they've not met in person before, and here's what he shared with me:
"This is the Holy Grail literally. I just got off a session where we did an introduction on how people can forge better connections, more human connections in remote sessions and trust is the bedrock. It is the foundation. So, if you look at how people work, when they have to come together to do something [...] there's an implicit level of trust that they start with. If you haven't really met before you trust each other based on the level of skills, and say: Okay we're here for a common goal. Let's see how we can make the best out of this time - and this trust lasts for a bit. And you need to capitalize on that:
So, once people come in you have to create a space so that they can connect with each other and connect on a personal level, so that the initial trust gets extended and gets built on and evolves over time. And this is the same for on and offline teams: It helps to be very clear, and to over-communicate right from the beginning:
The more you share - I feel - the better the chances for people to continuously build that trust."
This does of course put some pressure on those who are organizing the meetings because you need to make the setting comfortable for those who are to attend, meaning: Clarify the purpose of the meeting and make it explicit why the people who are invited have skills that are relevant to that goal. Because then you are creating the safe space of them talking about things they are comfortable about and that's something they are able to stick to. The organizer, facilitator, meeting leader should take care of creating the space in which they can actually put those skills to good work. Rakesh added:
"I like to try and ask people to share something very personal, right in the beginning, to make that a real human connection. Because when we're working virtually, we do not only have this physical distance but there's also psychological distance. So I really want to make sure that people can understand what my personal background is today, [which they have zero chance to empathize with, if it is not being shared]. It helps to clarify that today I'm feeling okay but maybe not hundred percent because... And from that level of sharing. There's a chance or an opportunity to build a personal connection, and I feel that matters a lot."
JOIN MY MAILING LIST
I think there's a lot of muted dish-washing going on in dial-in-sessions. Therefore another question that came up was: "How do you ensure that people stay concentrated in remote sessions?" How do you make sure people are engaged and don't open up other tabs in their browsers and check their mails on the side?
"You can't prevent it hundred percent. that's something, because people are being. I love this quote, that a friend of mine used to tell me: We all have the attention span of a mosquito. And to me, that is very true, unfortunately. And what we can do to counter this fact is to set some first principles. I usually start the session by saying: Can we please have the video on, because that's how we can connect better remotely. If we were in the same room, we'd just see each other but video is the only way now to stay connected.
And it helps to make your session as engaging as possible with small bursts of work, and enough space in between things, so that people don't get this digital fatigue. This digital fatigue where people are just doing something for a while and then losing their attention. It's a question of design, it's a question of being mindful of who the participants are. Are they relevant to this meeting or the session that you've convened? Is the topic of interest? Is everyone willing to contribute and learn? And you don't always have to be online, understanding the distinction between synchronous and asynchronous work really helps a lot. So just be synchronous when you really have to, when you really have to be there face to face. Let's say for example, we need to do some prototype sketches: Everyone can just do this for 20 minutes without being online, and agree to come back after 20 minutes. And then we share and talk about it. That is asynchronous. Exploiting this understanding of synchronous versus asynchronous, I feel, is very critical for engagement and attention."
And there's two more things that, in my experience, help: When I do such sessions I like to keep schedules a little shorter than usual. Because my learning was that people are not going to be able to really decline all the meetings that they would have in the business as usual setting. And I'd rather start at nine, and already end at four o'clock, than going from eight to five. I even extend the lunch break, so people have chances to do their individual tasks before, in between and thereafter, and therefore they really don't have good excuses to be distracted in the session. They can't say "sorry I need to take this call, I need to drop out.", because we're only working four or five hours. And second: Within the schedules keep a more detailed time-boxing, as Rakesh said: Small bursts of work with enough space between things. And really stick to it. In on-site-sessions you can run a fluid schedule and adapt easily to shifting priorities, in online sessions I experienced it to be more important for their collaboration to be reliable in your time boxes and stick to those, than adjusting for individual requests being helpful.
Rakesh framed it differently once more saying:
"If done correctly and if done consciously, I feel remote sessions are far more productive than in person sessions. I just like to say, we have 30 minutes, and we can all focus on this thing for 30 minutes, and then it's done. And that's great. Everyone's happy about that."
One question that I'm always struggling to answer and am going to pose to you, is: What is a good ratio, if you're working in several digital rooms. How many people can one facilitator manage or how many groups can one facilitator manage?
"I would rather keep it small. I'm a big fan of small groups because I find them to be effective. Groups of three or four, not more than three groups or four groups are the maximum. Because I feel the number of communication channels increases rapidly when you're working remotely. And there are chances of people asking you something on chat or asking you directly. So, just managing it is all the more difficult. I usually try to go with no more than three small groups, each group would be not more than three people. That's my borderline .And I would even say it's possible to get people to do this without going into separate rooms, if you have a digital whiteboard like Miro or Mural. Just have different corners of the board, and you can still do the same thing. The advantage there is, that you as the facilitator can sort of drop by each group and see whether you can support somehow. And this really moves the team ahead as a whole. "
Never miss a post - join my mailing list
"Empathizing definitely happens at multiple levels. What you can do, is to really be mindful of the questions that they might have as a user because they may not have access to all the information that you've had, while you're working on this particular project. I try to share as much as possible about the context. And I even try to split those sessions when working on customer interviews or user testing sessions into two sessions. First, I have one part where I'm actually sharing more about the whole big picture, either through a video, or live. I'd first talk to them about where this all came from. And once this is clarified my feeling is that the users have a better mind space and they're able to move quickly into testing and can just focus on that. They are then free to tell you more about what they feel when they click this or when they don't click this.
But I think technology also plays a role here, because I've also been on the other side of user testing sessions. It can be frustrating when you're called and the video doesn't work when you're trying a prototype. If you're live with the test person doing the test and certain things are not moving the way they're supposed to, you as the user might be disappointed and think: "I'm just giving my precious time and things are not working." So it's always good for before you go into the interview or the test to try the tech first. Do a dry-run before you even go to a customer and try to iron out all possible issues. For me that does a lot in terms of empathizing. And say thank you. Say thank you. That's the smallest possible thing you can also do. If you have a budget, give something as a thank you. That can be as simple as a chocolate-bar or a small Amazon voucher. Because people really value that, and they remember that for a long time."
I doubled down on this question with Rakesh, because if you don't have a prototype yet but you're exploring that problem space for the first time, that limits your possibilities. If you are trying to explore what the challenge is; how to reframe that challenge more precisely and you don't actually work with digital interfaces, which obviously are easy to share, but are operating in a very physical context, how do you empathize remotely?
"Then I would really meet them, if possible, in their environment. This has a double whammy effect: It's great for me to understand and put myself in this environment and see, observe as a learner, what their environment looks like. And at the same time: That's where they're comfortable. It's always great to meet someone in an environment where they're comfortable. In such an environment they're able to open up a lot more, and they're able to share a bit more. So in the ideal case scenario, meet them in person there. If it's going to be virtual still see how you can both connect in their environment. Read up a little bit and understand their normal in a deeper sense, start from there. That shows them that this is someone who is at least interested and is genuinely trying rather than just saying: "Come here. Sit down. I want to pick your brain."
One version that colleagues of mine are working on and that is one way of getting around it is, remote user-journaling: They set up a small app in which they push questions to users. They can ask users to record a short video in their daily surroundings. Prime them on certain questions in the morning and come back on them in the evening.
Rakesh's response was: "If I'm the guy on the shop floor, and I don't even check my email that often, then I'm not sure how much or how effective this is. In this case I would probably go with more old school self-journaling, or self documentation, things like that. So I would need to know a bit more about whom I'm dealing with. I've done some things where we tried to do some digital recording or digital snapshots of a day's journey and I've had mixed results from that."
Moving on in the cycle, and I think that's worth noting, there were no questions on defining or framing problems. The questions I got from the LinkedIn Community directly jumped from empathize to ideate, and that's where we're going to be next. But I think it's really interesting that nobody called out that spot, Which to me means that defining and framing questions and challenges works great online.
"I think this goes in the direction of someone, who was asking how to run a world cafe online. These are the things for which you can use some kind of a digital aid. A digital aid is some shared digital space that is accessible by the team members, and where they are able to contribute in a very structured way. And it need not be fancy, like a Mural or a Miro, you can even just have a shared Google Doc that everybody's able to log into. You use that as the central point of attention, because from everything that I've seen with online ideation: You need a central point of focus. Otherwise it is very difficult. You need some kind of a digital tool in which people see what the others are doing. It helps because people realize that if others can work on this, they can also do these things. That's the feeling that you need in order to ideate and build on the ideas of others.
If you have a digital aid it helps immensely to have roles defined. There should be one facilitator who's able to take care of the space and the process rather than the content. And then that's half the job done."
The last question along the process turns to prototyping. How do you keep crafting things manually in the process? Because I think it's a vital part of getting things sorted. And I am not addressing the virtual prototyping here, but the physical prototype creation part of the process - but in a forced remote or virtual setting.
"There, I think, you need a shared understanding of what the central question is this prototype is going to answer. And the most effective thing that I've seen is to just throw that out there and tell people, the kind of output that you're expecting. You can say: I'm expecting a sketch, or send me a picture of [fill in the blank], and people then go into their zones of creating and that has always been beautiful to let them own the "how-do-I-do-this"-part, rather than also defining that. But having said that, it's difficult to share prototypes when you're working digitally. The simplest thing you can do is to go with sketches. You can pick individual questions or elements that you want to prototype, make a sketch out of that. Or have pictures or videos that you can share. The creation process can still be kept alive. For me the question is more about how you share that; how do you get that feedback? How do you make sure that the other people in your team are able to understand it, although you've created it the way that you wanted it."
I think it's a really interesting point that Rakesh made here, because he said: You need to get the question or the hypothesis that you want to test straight. And getting that right actually is enough guidance for the team to creatively solve the question of how you might prototype that. And that has been to some extent my experience as well that going online forces you, as a facilitator, to be more conscious of the single steps and the logic chain that you're trying to create through-out the workshop. The main difference is, that being in one room we kind of get a feeling for where we are going. And in a room you can start prototyping together, and since you are doing this with our hands together, any missing clarity is going to pop up rapidly and trigger the necessary discussions. However, if you transition this process into a collaborative remote setting: It is getting difficult to identify misunderstandings and the medium is therefore forcing you to be more precise. You really need to be able to pin down that question, really get your hypothesis straight
"For all you know: Sometimes it's the wrong question. You found out that it's the wrong question, which I find is good. The earlier you do that, the faster you can move onwards."
Concerning manual crafting. Is this part going to fall short in remote settings?
"It depends on the things that you're doing. So for example I've had instances where the prototype was a contract, you still had to craft it the way you would normally craft it. Or there's been instances where it was a physical product. And then you really had to figure out the mechanics, the function had to be clear. For prototyping you have to understand whether you are testing for form or function. These things needed to be clear and then I personally don't think it's entirely lost. I don't think it's entirely lost."
Speaking more general about formats, Design Sprints obviously do work online. But are there certain formats that you would distance yourself from when I'd asked you to run them online?
"For me, it depends on the team. So, the maturity levels of the team, let's say the collaboration index of the team. So, the more they're comfortable, the easier it is to do things online - sometimes I feel you need to start offline. By creating this human connection maybe do a kickoff together, maybe if we can first do the problem framing or the team alignment together in person, get a more solid foundation of trust, then it's far easier to do things remotely. I'm not averse to particular formats. But for me it always boils down to the people. Always. I'm always asking: Does this make sense for these people with their exposure, with their openness, or levels at which they've done other things before. What have they been exposed to? How can we work on that? That's always what I'm looking for.
A method or a framework or a tool is nothing if you know the people behind it don't benefit from it. So, for me, that's really front and center, and once that's taken care of, other things don't matter."
Thank you Rakesh for taking the time out of your busy day. I wish you all the best in your further sprints and hope to stay in close contact.
One thing Rakesh has been doing for quite some time now as the sprint doctor, is making sure that the teams he works with find their challenges early on and find some really cool solutions for those. He does also support them with techniques and frameworks to really work smoothly together. He has the tools tested and the frameworks at the ready, therefore I was even more grateful he was willing to share his knowledge with a wider audience.
The other thing that he has been working on are the Life-Sprints. The Life Sprint actually was something that came out of his work with the Google Design Sprint method. But with the Life Sprint Rakesh helps people to get unstuck with their career challenges. This is fully remote, people join "from their sofas" and enter a very structured process that guides them through their career challenges and gets them out of the pain zone as quickly as possible.
And I cannot recommend joining one of those lifesprints enough. I've been there and took tons of value out of that.
JOIN MY WEEKLY MAILS