
Employing Differences
A conversation about exploring the collaborative space between individuals, hosted by Karen Gimnig and Paul Tevis.
Employing Differences
Employing Differences, Episode 175: Can we do this asynchronously?
"We need to be enough in alignment that when we get back together, we're not surprised at where we landed. Or at least, we're not badly surprised at where we landed."
Karen & Paul talk about collaborating when you can't work together.
Karen: [00:00:06] Welcome to Employing Differences, a conversation about exploring the collaborative space between individuals.
Paul: [00:00:13] I'm Paul Tevis.
Karen: [00:00:14] And I'm Karen Gimnig.
Paul: [00:00:17] Each episode, we start with a question and we see where it takes us. This week's question is, "Can we do this asynchronously?"
Karen: [00:00:26] This is the thing that I think has been around for a long time, but it showed up a lot more with covid and getting on Zoom, and hybrid work, and all those kinds of things. But this idea of collaborative work that happens without having actual time together in the same room, and often without even having time together on a Zoom call.
Karen: [00:00:45] And as you all can tell, Paul and I do the podcast collaboratively, very synchronously, very much together. We get on Zoom, we record things. And we were talking, as we were setting up this episode, about projects that we've done, or are doing with partners, and in very collaborative ways, but asynchronously. Where we weren't together for all, or even most of the work, of the project. And so the question is for any given project, "Is this a thing we can do asynchronously? And what would make that work?"
Paul: [00:01:20] I think it's the what would make that work. That's the important part. I think there are- and I'll put my standard disclaimer up front here. There is a lot of work, I think, that often we try to do asynchronously, without considering what we would need to do in order to make it work. And that there are- I mean I worked in software for a large number of years, where one of the things that we were big proponents of in a lot of places that I worked was pair programming or ensemble programming. Where you have multiple people at the keyboard at the same time, working together on the thing, in a very synchronous way.
Paul: [00:01:54] And sort of at the other end of the spectrum, we often see work that comes into teams, that are teams in name only, because really they're collections of individuals who do stuff. And they're not really collaborating. Everybody gets their own thing. They go off and do their own piece, they throw it over the wall. And so one of the questions that we would often run into is this question of like, we have this thing that really does require multiple people's perspectives and skills.
Paul: [00:02:19] That's where we actually need collaboration, not just coordination. And we know that oftentimes the most effective way to do that, is to have all of those brains on the problem at the same time, to work synchronously. And that's not always possible.
Paul: [00:02:35] So one of the things that we would dig into is, hey, given the constraint, given the fact that we can't all be together on a Zoom call at the same time, for various reasons, whatever it is, what are the things that we need to do so that we can work effectively when we're not together?
Paul: [00:02:55] So that we're still collaborative, so that we are still incorporating those perspectives, and we are still using each other's skills and leveraging those sorts of things. So that it really is a collaboration, not just one person working on a thing and bringing it back.
Paul: [00:03:09] What something my friend Tim Ottinger has talked about with Scatter Gather, that we're actually collaborating on these sorts of things. And I think that's really what we're trying to dig into here, is 'How do we do that? What do we need to do in order to make that work well?'
Karen: [00:03:22] And I'll add one more piece about when this might come up, which is even if we have theoretically the ability to get on Zoom, the work itself might benefit from individual uninterrupted brain time. Like, brains work differently when they're not staring at a Zoom screen. Brains work differently when they're not interrupted by other people's ideas in the moment. So also just the sort of thinking that we want to go into, it can be both.
Karen: [00:03:48] Something that benefits from some stretches of time where individuals are uninterrupted, and not staring at a Zoom screen, possibly not staring at a screen at all, depending on what the work is. I did a lot of my collaborative work sitting on the beach with a notebook! So, you know, if those are the things that also benefits from the input of different people's ideas and different perspectives, all of that.
Karen: [00:04:12] So whatever is the reason that we're doing it asynchronously, what does it take for that to work well? And then can we do this asynchronously, I think is, can we do the things that it would take for it to work? Well, if we can, it'll probably work.
Karen: [00:04:26] And I'll jump on with what I think the first thing is, which is to start together synchronously. The idea that we can really collaborate 100% asynchronously maybe, but I'm pretty skeptical about that.
Karen: [00:04:40] What I think is more likely to work is that we can start by getting together, and defining the work. Defining the work relationships, getting clear about the what we sort of call the relationship container. What are the ways in which we work? What do you need to know about me? What do I need to know about you? And are we trying to get to the same place, and are we willing to travel generally the same road to get there, or at least a crossing road? You know, if we're going to be on two roads, they need to be able to cross each other and align with each other if we're going to be on totally two parallel tracks.
Karen: [00:05:14] Yeah, collaboration, it doesn't work that way. There has to be touch points. So the first thing is creating this really strong foundation around expectations, around goals. Around possibly even broad strokes of the content we're trying to create, whatever that is, those kinds of things. There may be an outline of the work, an ordering of the work, all those kinds of things.
Karen: [00:05:35] We want to get really good alignment about so that when we go separately, we don't then come back together and have me going, "Paul, where'd you go? How did you end up over there? What happened? I don't get this!" We need to be enough in alignment that when we get back together, we're not surprised at where we landed. Or at least, we're not badly surprised at where we landed.
Paul: [00:05:56] Yeah, I agree that there is a lot of 'We need to know that we're pointing in roughly the same direction'. That we have some sort of compass that's telling us that we're going to the same place, or at least headed in the same sort of route. Even though, because we are different people, we will take different paths to get there.
Paul: [00:06:14] And then in fact, we also need to embrace that part. We need to be ready for all of those things that we came up with at the very beginning, to be overturned by whatever emerges from collaboration. So I sometimes say that this is the plan from which we will deviate. I think it's really important to start with a plan. Because then we can sort of come back around and say, you know, when, you know, let's say we are, where one of the things that I've done, for example, is with some of my other business partners. We're building a class. And so we've kind of outlined 'Here's the you know, what we think the class is going to be about. This is the learning objectives, it's going to cover these sorts of things.'.
Paul: [00:06:51] And then one of us will usually take a piece of it and go, 'All right, let me sketch out what I think this would look like. These are the activities. This is the way we would structure that and we'll take somebody else will go the other direction and do another thing with it when we come back together.' We should be able to go, "Okay. Yeah. That is about what we thought it was going to be". Or we should be able to go, "Oh, you know what we said at the beginning was we thought this module was going to work this way, but as I was working through it and thinking about the things that we had talked about, I realized there's this other piece that's still there."
Paul: [00:07:22] Collaboration and any of these sorts of things is a creative act where we can't predict exactly what's going to come out. And so we need to be ready for that. And so we need to not cling too rigidly to that original plan, that foundation. And we need to be ready for what will emerge. But I do find it useful to at least have a plan so that when we come back, we can decide - Do we go back to the plan? Do we stick to the plan? Or we do we move in this new direction that the work has seemed to bring forward?
Karen: [00:07:53] Yeah. And I think what you're pointing to there is there is a way in which we got to be very careful with ego. That collaboration depends upon feedback, going back and forth. And some of that feedback, if you're doing it right, will be, "Yeah, I disagree with you. I don't like the piece that you did. I think you went about it the wrong way" or, you know, "Not the way that's going to serve the project" or "I would like to do it a different way" or that kind of thing.
Karen: [00:08:20] And in so much of life, when that language comes at us, the reasonable thing to do is to feel attacked and defensive. And collaboration- especially, asynchronous collaboration, will not work if that kind of feedback lands that way.
Karen: [00:08:39] Like, what we need is for that kind of feedback to land in a way that says, "Okay, good, we're working together." Okay, that's, you know, it doesn't threaten me, it doesn't threaten the relationship. It doesn't threaten the project- unless it does, in which case you're better off to have figured it out than not. But, you know, it doesn't mean anything other than there's a place where we're thinking about things differently, and we'll need to work on that.
Karen: [00:09:04] And the place where I've had the very best success with asynchronous work was when Yana Ludwig and I were writing our book together. And she's an amazing model of collaboration, which is if you can find that, that's also a great piece of the asynchronous thing, is to find somebody who's already really good at this.
Karen: [00:09:21] But I remember her over and over again, as a difference would show up between us, and she'd say, "Oh, good!" And she'd get all excited and go write it down as a thing that we were going to have rich conversation about. And I try to emulate that. That if we run into those differences, if there's any part of me that's going, "Oh, no! Danger, danger, danger!" I got to deal with that. Because if we're going to be able to do the synchronous work, I need to foster the part of me that says, "Ooh! Something rich, something interesting. Something to be curious about."
Paul: [00:09:51] I think one of the keys to that is recognizing that when you're working asynchronously, if you really are collaborating, then even the part that you did on your own is not yours. Exclusively. Recognizing that even if I put these words down, that they don't belong just to me, that they actually belong to us. Because then then it makes it way easier for me to take that feedback. Because it allows me to take my ego out of it.
Paul: [00:10:19] Of course, the longer it is that I work, without actually showing you the work that I've done, without getting feedback, the more easy it is for me to identify with that. To go, "This is my piece." And now, now I can feel attacked, you know, around it.
Paul: [00:10:35] And so I think that is often one of the challenges of working asynchronously, is it's not just that we have to be synchronous at the beginning to sort of set the foundation for it. But we do need to make sure that we're not going too long without sort of sharing what it is that we've been doing, without incorporating the other person's perspectives into it, that may be different than our own. That we're not hiding these things away for too long.
Paul: [00:11:00] And yes, there are absolutely times when, 'Look, I just need to spend an afternoon. Getting this stuff down on paper, you know, by myself. I need these chunks of time where I may need to work on my own, but I need to not default to that for too long, even if we're not working asynchronously around that stuff.' 'If I can be sharing, here's what I've been doing, here's the direction I'm going.' 'I'm not ready for feedback necessarily on this yet' or things like that. But I want you to be aware so that you're sort of, you know, you're still in it, even if we're not talking about it, rather than just go into my cave and disappear for a while. So that's, that's one of the, one of the challenges that I run into doing this type of work.
Karen: [00:11:43] Yeah, I think that's super important and that's very much how Yana and I did it. I think was successful was we worked in a single Google doc. And whether you're a Google Docs person, or whether you use some other space, having the work be very much shared in a space where both can see it. And I did a good bit of drafting with pen and paper because that's how I work. But then I tried to get it, you know, I would do however much I did and then cycle it back up. So even if we weren't getting together, we did regularly and I think that's a good idea. Even aside from that, we were able to use the comments, feature or editing features and we developed norms, too, around that.
Karen: [00:12:24] So when I was reading her work, if I noticed a grammatical error, or a spelling thing, or something like that, I just changed it. I didn't track changes, you know, I just fixed it. Because we had that trust.
Karen: [00:12:38] If I was changing her language in any significant way, we did it in suggesting mode. And most of the time she went through and just 'accepted', 'accepted', 'accepted' and anything that she wasn't sure about, she left. And then we could talk about it. And then if there was something that I really disagreed with, or wanted to go in a different direction, then I used the Comment feature for that. So that's one model. I think the elements of that are what I would say you need. Whether or not you want to use Google Docs, or whether it's a document for that matter that you're working on.
Karen: [00:13:08] But having ways, either that you can asynchronously be giving feedback along with times that you get together, or getting together often enough that before anybody has gone off and done dozens of hours of work without a check in, that that back and forth is happening. And we do have the technological tools that for most projects you can have some asynchronous back and forth. And as long as there's enough checking- and I would say early in a project, especially if it's the first time you've done this with this particular person or group of people, you probably want to check in more often.
Karen: [00:13:45] I mean, you might want to start off with 'let's get together once a week or even once a day'. If you're, you know, if it's something you're working on all day, every day as your primary thing. And then through the project, the frequency of actually getting together can probably fall off because the trust and the systems, that are with the asynchronous check-in, get better.
Karen: [00:14:06] And the need for any check in gets better. Just because if we've already done the first five chapters and we've gotten used to, 'okay, I know what's likely to come up or not'. I know you know where we're aligned. If I go off and write five more chapters by myself, the odds that I get way off track, pretty small. Whereas if I'd done that for the first five, I would predict that there will be a lot more editing necessary.
Paul: [00:14:30] Yeah, it's really the confidence that either or any of you, because you know, this is true of more than a pairwise relationship as well. What you really want is the confidence that the work that any one of you is doing, is reflective of what the group is actually trying to achieve. That it's in line with what it is you're trying to do. And so, yeah, absolutely.
Paul: [00:14:50] I have that experience as well, is that and I'm always nervous at the beginning of a project when we're starting to work collaboratively on something. Like, I might want to do quite a bit of checking or even even work together on a couple of things where we really are both at the keyboard, you know, doing things. We're doing stuff synchronously, until I feel confident that we can work in longer stretches apart. And still have it come out as something that is collaborative.
Paul: [00:15:18] Because that really is the thing that I'm wanting in this, is not to just feel like these are the individual pieces that different people did and we stitched it together. And it's not a coherent whole, right, that it really does feel like that it is a product of the relationship. That it is more than what would have happened if one person was doing it by themselves.
Paul: [00:15:38] That it is that feedback, and that interplay between the different perspectives, and the different ideas that makes it something that's exciting to me. And it's one of the things that I really enjoy about doing this show with you, Karen, is that I mean, we say at the beginning, "We start with a question and see where it takes us". We don't know where this is going to go. We sometimes have some ideas, but in the middle of an episode, one of us will say something that the other one goes, "Oh, I hadn't thought about that before!" And we go off into something that's richer than would have been if it were just the. Two of us, each individually doing our own thing. And it's that kind of magic that I think we can capture even in an asynchronous way, provided we do the type of work necessary to make it happen.
Karen: [00:16:20] I think that's absolutely true! And the one other piece I just want to toss in here is that occasionally we're going to find that as this thing is coming out of the relationship, there is some piece of it where we just aren't going to agree with each other. Where my background, or my perspective, or my piece is just different. And what are we going to do about that? How are we going to work with that?
Karen: [00:16:44] So for Yana and I, working on the book, we just agreed that we do some sort of asides in the text where one of us might write our own piece. And we made a point. We were writing a book about collaboration, and cooperative culture. And so it was an absolutely excellent opportunity to say this is a place where we disagree. See, we did this thing together and we have disagreement, and that's still okay at our relationship is still okay. So it worked for us in that way.
Karen: [00:17:10] If you're writing a computer program, that might not work that way. But have a conversation about "If we get stuck, how are we going to get unstuck? How do we deal with persistent differences?" Because if you don't do that, I think the danger that you run is that somebody has to win and somebody has to lose. And you don't want that.
Karen: [00:17:31] You don't want the sense that somebody had to give in. You want the sense that you're still working toward the collaborative goal. And so if that goal is a cohesive program that all fits together, yes, there will be some give and take, but you don't want it to feel like winning and losing.
Paul: [00:17:48] My watchword for all of this stuff is always resentment. Am I finding myself being resentful that, "Oh, I couldn't say the thing that I wanted to say in this space"? Or "Is the other person resentful because we had to agree, we had to have the party line on things." And I think that's also just a useful cue when we're talking about those check-ins and getting feedback right.
Paul: [00:18:08] It's like, are we resentful of the feedback that we're getting? Or are we resentful of our feedback not being listened to? Because that's really a sign that we need to step back and sort of strengthen the container of relationship that we're working in, and just talk through again, how do we want to handle that when we disagree? How do we want to resolve that?
Karen: [00:18:25] So just to track, "What does it take to work well asynchronously?" The first thing is a really good foundation, which probably comes from asynchronous meeting. From getting together, and talking through the goals, the direction, the intent, the norms of collaboration and outline of the project. Probably a structure of who's going to do what and what's the pacing going to be.
Karen: [00:18:48] And you know some things about how is the work going to get done, all those kinds of things. You don't want to rush through that. You want to make sure that those are collaboratively decided on and that there's the sense of collaboration right off the bat.
Karen: [00:19:01] And then as you go off in your sort of separate places early on, you want to do smaller chunks, get back together and check in with each other more often. It can spread out over time as you build that working relationship and build the confidence of it.
Karen: [00:19:16] But keep in mind always that even if I am working on my own, I am working on a joint thing that is intended to reflect and to belong to the relationship. And so what I'm putting into it when I'm not in the presence of my collaborative partners, is going to get influenced by those other people at some point and some things they're going to just love what I did and some things they're not.
Karen: [00:19:42] And I need to be ready to set aside my attachment to pieces, and be able to really have that conversation where there's disagreement. And let go if there's a better idea or a different direction, or the project's headed off somewhere else.
Karen: [00:19:55] So be prepared for where the roads that we're on sort of diverge and make sure that there are opportunities for intersection again. And then being really cautious about resentment that may show up when there are differences, really show up with a ton of curiosity, and as little ego as you can manage.
Karen: [00:20:15] And check in with each other and make sure that when you're working through those differences, you have a way to go about it. That results in everyone still being heard and whole. And not getting into those resentful places. So that the end product is a model of collaboration and bringing in the best of what everybody has to offer and even more than the best of any one individual. But that magic that happens when real collaboration happens. And we're just really pointing to the value, both for convenience of being able to work asynchronously and also for the benefits of individual focused work, and the collaborative different gifts, and energies going into it.
Paul: [00:20:58] Well, that's going to do it for us today. Until next time, I'm Paul Tevis.
Karen: [00:21:01] And I'm Karen Gimnig. And this has been Employing Differences.