Working Asynchronously

In a time where remote work is much more normal, there is a give and take between what work can be done simultaneously and in tandem with others versus what needs to be accomplished with focused efforts on an individual basis. Caitlin Klink joins Matthew Heusser for this episode to discuss the benefits and advantages of gearing towards more asynchronous work and how enabling teams to leverage asynchronous work can help with productivity gains and better products for everyone.

Michael Larsen (INTRO):

Hello, and welcome to The Testing Show.

Episode 140.

Working Asynchronously.

This episode was recorded on Friday, July 28, 2023.

On today’s episode, Caitlin Klink joins Matthew Heusser to discuss the benefits and advantages of working asynchronously, by allowing for less “all in the room” efforts and how that can help provide better productivity and better products for everyone.

And with that, on with the show.

Matthew Heusser (00:00):
Thank you, Michael. This week it’s just going to be Matt and my guest, Caitlin Clink, who is a product consultant at En Dash Consulting, and we’re gonna hear a little bit about what En Dash is in a minute. We’re gonna talk about not just remote work, but asynchronous work today, which Caitlin has been doing for a couple of years now.

Caitlin Klink (00:25):
Yes.

Matthew Heusser (00:26):
So Caitlin has… I knew you were a teacher. I knew you had a degree in education, but you’ve got a master’s in curriculum and in instruction.

Caitlin Klink (00:36):
Yes.

Matthew Heusser (00:37):
From McDaniel College. Where’s McDaniel College?

Caitlin Klink (00:39):
It’s in western Maryland.

Matthew Heusser (00:41):
Okay. I don’t know McDaniel. I’m originally from Maryland myself. We met at the Agile and Beyond conference that was in Detroit and I found out Caitlin not only consults on asynchronous communication, but she was from Maryland, so that was just amazing. End Dash is located in,

Caitlin Klink (01:01):
En Dash is in Richmond, Virginia.

Matthew Heusser (01:02):
Okay.

Caitlin Klink (01:03):
So when I was hired I was full-time remote and I’m full-time remote still. So it’s been several years now and no one else from my team lives in Maryland. They all live in Virginia. So there’s not a brick and mortar for me to go to like once a week or anything like that.

Matthew Heusser (01:19):
Well, we’ll just have to forgive them for that. It’s okay. Let’s start. En Dash helps bridge technology gaps, right? So not so much on the testing side, but developing, delivering, and helping companies to be more… excel in their application of technology. Yeah. What’s En dash? What does En dash mean?

Caitlin Klink (01:43):
Yeah, I love the name that our founder kind of came up with. So an En dash is a type character. You usually find it between two years to show like a period of time. Something happened from 1942 to 1947. The dash in the middle of those two numbers, those two years is an en dash. It’s often used to show range or transition. That’s kind of the idea is that we are here to get the company, get our client from A to B with creative solutioning. Our services are mostly in the software development space and the product thinking. We have some specialists in accessible design. So we’re really passionate about good design is accessible design, asynchronous working patterns, working in a slightly different way than we had been used to

Matthew Heusser (02:34):
At the conference. Your talk was on asynchronous… remote and asynchronous, and remote, okay, I get. Asynchronous I kind of understand intuitively, but I had both, “What’s the big deal?” but also, “What the heck is it?” Let’s talk about value for a minute. Your argument is async is a better or more valuable way to communicate on software projects and what would that be? I guess that’s two questions.

Caitlin Klink (03:00):
. That’s okay. Yeah, I mean I think that you mentioned I was a teacher, I taught English, I’m a big term definition. So to define our terms, a lot of people kind of assume asynchronous is just remote by another name. But in actuality, asynchronous work is just work that doesn’t require immediate or simultaneous response and interaction. It’s work that happens outside of the dreaded, “Let’s hop on a call! moment. It’s work that happens outside of us all in the same physical or virtual room where asynchronous work doesn’t have to be remote work. You can execute asynchronous working patterns in a brick-and-mortar setting. It just often lends itself to remote work. Remote work should be largely asynchronous work and we can obviously dive into that later. But essentially asynchronous work is just work that doesn’t require a dialogue like you and I are having where it’s real-time coms.

Matthew Heusser (03:54):
So would you agree? I think that the Agile movement and a lot of the movements around that time really emphasized face-to-face, really emphasized the value of real-time feedback, which is synchronous. That would be, I ask you a question, you give me an answer. You give me an answer, but I can tell by the look on your face that there’s something more going on there and that allows me to… your tone of voice, that allows me to sort of dive in and dissect and figure out what your resistance is or what’s… I was talking to someone yesterday and he just changed in his mannerisms. I think I said something that he took seriously and it was a joke. Wouldn’t asynchronous, don’t we lose all that? I thought async was bad!

Caitlin Klink (04:41):
. It’s not really good or bad. I agree, I think the original Agile movement got a lot of traction because you had these huge, I know SAFE is debatable, but like the big PI planning sessions where everybody’s in the same room and we have sticky notes on walls and we’re moving them across and these Kanban boards on a whiteboard with Post-its and that was great and it worked really well for the moment. I would argue that we’re in a different moment. I don’t think it’s super controversial to say that remote work is here to stay, pretty much industry-wide in some form and fashion. Obviously, companies are trying to strike a balance of what the right level of remote is. Regardless, you may not have the opportunity to have all of your staff in one place like that as frequently as maybe you did 15, 10, even five years ago because of the fact that we’re working in a different way and you can’t necessarily walk across the office to knock on someone else’s cube to ask them a question. It’s time to maybe start to reimagine the way we can leverage asynchronous communication patterns. It’s not like an all-or-nothing type of situation. It’s more of where can we start to move the needle a little bit towards an asynchronous first mindset and stop the obstacle meeting culture and the challenges that this new meetings culture has brought.

Matthew Heusser (06:01):
Well, I can definitely see that. I know that when I worked at a company, meeting culture-specific, you could often get away with not really doing anything because you were waiting on the meeting to resolve issue number seven and they would usually paper over that with multitasking, and multi-projecting. So you’ve have seven projects that are not really making any progress, but it’s all because you’re waiting on an answer from somebody else and you have one meeting a week to try to resolve it. And really all you would do in that meeting was hand the problem to the project manager and walk away. So it might take two or three weeks to get it resolved. You could ask the right person the right question and they get the answer to you in an hour ’cause they’re away from their desk. That’s definitely an improvement over that.

(06:44):
Likewise, when we started the real-time feedback, you gotta talk to someone in real-time and see face-to-face, da, da, da da. That was in response to here’s the 500-page requirements document. I don’t want to have to talk to you. Maybe not 500, maybe a hundred, maybe 80. We would get this piece of paper and it was all designed so that we would prevent communication. And of course, English, being a vague, ambiguous language, all of our human languages that are not scientific languages are vague and ambiguous. When we got the document, we couldn’t ask the document. What do you mean by that? The face to face…

Caitlin Klink (07:22):
Right? So enter status meetings, enter status meetings to solve that problem because…

Matthew Heusser (07:26):
Which were not often enough and ended up causing delays. And you’re saying asynchronous has faster feedback than the status meetings, but disconnects the need to actually schedule something. ’cause in a meeting culture you might take five business days to get the seven people you need in one room.

Caitlin Klink (07:50):
Absolutely. And I think that ideally meeting culture is not necessarily all bad, either. Asynchronous isn’t necessarily inherently better because it needs guardrails. And so what you see in a lot of organizations, it’s like they’ve just implemented maybe like a chat tool and it’s all of the worst things of synchronous and asynchronous communication. It’s all of the bad of all of the things. And the idea here is that if you’re going to move towards a more asynchronous way of working and fewer meetings, you do so with intentionality. And I think that’s the key that a lot of people maybe skip because a lot of us are working remotely because of a really reactionary thing, right? This global pandemic hit and everybody went home and then we sort of had to figure out, okay, well let’s just make this work. I would say we’re past the make it work moment and now it’s time to really take a critical lens at the way that we’re working.

(08:46):
And a lot of us grew up with AOL instant messenger and Slack, Microsoft Teams, they’re not instant message tools. They’re collaboration tools, they’re communication tools, but they don’t have to be instant message. A Slack doesn’t mean drop everything and respond. And so I think that’s kind of the piece that gets missed. And a lot of people who argue that you can’t get anything done if you’re not on a call. I think that what’s missing in those cultures is, for lack of a better word, rules, policies, how are we going to leverage these different mediums we have to collaborate with one another outside of all being on the same call or in the same physical room.

Matthew Heusser (09:24):
Yeah and it’s kind of odd. I think that’s necessary. So a couple things occur to me. One is we just keep adding more tools. So yes, if you read Peopleware, which was, I don’t know, 40 years ago now, they complained about their ringing phone as the interruption. Well now we have the ringing phone and then we got email. Some people use Confluence as a communication tool. You have Slack, you have your cell phone text messages, you have Telegram on your phone, you have, you have, you have, you have, sometimes you need focus time and there’s always another different way of interacting. We don’t often have any kind of significant guidelines for who should use what when that’s anything close to evidence-based. If you’re lucky, some executive just sort of makes a command and I’m not sure that’s really lucky.

Caitlin Klink (10:17):
Right.

Matthew Heusser (10:18):
But what really I liked about your talk is this is the kind of thing that anybody in any role can just start doing. You can just start using Slack in a more effective way to improve communication, which will improve outcomes. So you don’t need a policy, you don’t need top-down from now on. All communication will be asynchronous to start implementing some of the ideas that we’re gonna talk about in a minute. That’s super exciting to me.

Caitlin Klink (10:46):
Yeah, absolutely. I would say that the more buy-in you have, it’s with anything else, right? The more buy-in you have from the top so to speak, like the more successful this will be. But certainly if the only place you can affect any change in your organization is your own work or maybe your team’s work even that can start to give you some benefits. Like for example, the client that I’m on right now, while they may not be like super asynchronous and I might not be able to influence that change across their organization, the way I interact with my team members within my own company by leveraging asynchronous practices there is sort of saves me a whole bunch of statusy meetings within our own staff. We don’t have a weekly staff meeting at my company. There’s not a need for it. So we don’t have that.

(11:30):
We use Slack to have those types of conversations or we use notion to organize the interactions that maybe we need. Yes, agreed. Anyone can start to make some changes in the way that they work and hope that it inspires others. So you will experience more success if it’s more of an enterprise-wide type of thing. But yeah, it doesn’t have to be like a formal policy. It can just be, “Hey, this is how our team is gonna work for, do it in an Agile way. Like we’re gonna try this out for a sprint or a month and we’re gonna retro on it and see did it bring us good results? What are the things we like? What is working and what are the things we don’t wanna do anymore? And is there something we wanna try?” I think it’s just another way to start looking at continuous improvement.

Matthew Heusser (12:12):
Well, I did miss something when I did Caitlin’s introduction that I think is important. So while her company does studio work, which is all aspects of software delivery and they don’t really consult on testing, someone’s gotta do it. Correct me if I’m wrong. Not only are you part of the practice lead for testing at En Dash, you’re doing the testing work, it’s a small company, but you’ve figured out ways to do it in an asynchronous way. You have figured out how, ’cause we’re all doing asynchronous at our company, you’ve figured out how to use threads and messaging to communicate your status to developers to implement fixes and get feedback, which I don’t hear about very much. Did I get that right?

Caitlin Klink (12:54):
Yeah, I mean basically for the app that we develop presently, you know we have ideas and things like that, but the app that we’re actively developing, we have a dedicated Slack thread to that app development and our developers can post. So like it starts from ideation. I’m a product consultant technically. So I start by helping define intent. So as we are building out the features, each feature maybe has its own thread and then we have back and forth. Once the development is done, we use Jira for development. But once the development is done and we’re ready to start testing issues that come up, I also can use Slack to do those things. So basically if I’m testing feature ABC, let’s say. I will post that feature ABC will be my posts in the Slack channel and then I’ll thread whatever my question is, whatever my evidence is, and whatever my results were.

(13:45):
And then my developers can respond to me within that same thread. So we don’t have to remember or go back and search through email what was the interaction, and where did this thing leave off? Like it’s all right there, documented real time in Slack. And so in that channel you’ll see threads of the issue and then maybe there’s 20 comments in that thread where we’re resolving that it doesn’t stop us from moving on to the next one. Maybe I tested that first one. I post my results and I move on to the next thing to test. Or if I find a bug I can post it in the Slack channel and the developers can respond back to that and we can have that back and forth about what is the actual intent? Is this truly a bug? Is this M V P, etc.? But all of that documentation is posted right there in the same place.

(14:30):
So anyone on the team who’s working on the app can see it. And there’s not like a lot of noise where if I post that, I don’t expect like an immediate response. I’m not blocked, I’m just giving my feedback and then moving on to the next thing. And anyone can just quickly go to where they’re added or start at the top and work their way through my questions kind of at their leisure. If I’m working with somebody in a different time zone that doesn’t block me, I can do my testing and then leave my results for the developer that’s coming online maybe in four hours.

Matthew Heusser (15:00):
So there’s a couple of interesting features of that. One is that Slack, unless you pay for it, the messages go away after 30 or 45 days or something like most tools are like that, which I think is actually a feature. If you have a thread that hasn’t been updated in 45 days and it’s fixed,

Caitlin Klink (15:17):
We don’t need that ,

Matthew Heusser (15:18):
There’s this argument to be made that we can mine that for data maybe. Or if it hasn’t been fixed, we can take it outside that tracking system. If you wanna mine it for data, take it outside that tracking system. When I look at bug trackers and other tracking systems, I just see a lot of cruft. So maybe going away is a feature, but I wanna make sure I understand you ’cause I think I heard it a couple of different ways. One way is every thread is a bug you find.

Caitlin Klink (15:45):
Mm-hmm

Matthew Heusser (15:45):
But it sounds like you’re doing more than that. Maybe every thread is a feature or, and maybe it depends on how you’re structuring testing this week, but tell me about how you structure testing.

Caitlin Klink (15:55):
So I mean it really depends. It depends on what phase we’re in. And so depending on the size of your organization, you can choose to sort of organize and leverage Slack in different ways. For us, we’re super small so everything goes in that same standup Slack thread. But if you are a larger organization and maybe you wanna have a Slack channel for each sort of phase of testing. So at the beginning of the project where we’re defining the different features that we want, maybe I can communicate intent, user login as a feature. Maybe that ultimately translates to a Jira Epic. But when we’re in ideation, maybe we start brainstorming before the meeting. This is not to say that there should never be any meetings ever. That’s not the suggestion. It’s just looking for places where you can start to do things outside of that meeting.

(16:38):
So leading up to the first meeting where we’re saying this is the MVP bucket, these are the features we’re gonna develop, maybe we organize on, say, this feature and then I put all the information in there and we have some back and forth. As we move through it and features are ready to be tested. You can circle back to that again and you can say, I’m testing this feature, this is what happened, this is how it worked. And then if I’m in my preliminary stages, not in production, I’m not calling those bugs at that point. Maybe there was a miscommunication about intent, ’cause I know bug can be like a triggering word sometimes. Perhaps I encountered something that I wouldn’t have expected. We’re not in production. I’ll put all of that under that feature test that I’m working on.. versus if we’ve relief maybe an MVP or we have testing once we’re in prod or we are doing external users and I want to communicate with my developers about bugs that users are finding. In that situation, I would again go back to that same Slack where I didn’t label it with bug.

(17:33):
You could use naming convention. You could say “feature:” and then what it is and then “bug:”. We also at times on my team have used Slack reactions to indicate what kind of thread this is. So maybe we have a certain decision needed. So we use a check mark to say, “We need someone to decide this.” Maybe it’s a bug. So we use a bug reaction to say, “This is something that is a big deal.” You can also communicate priority of items that you want developers to address using those Slack reactions as well.

Matthew Heusser (18:02):
Wow. One way to do it that occurs to me, one way to interpret your words is, you know, we usually distinguish between testing a feature where you might have more high volume feedback of, “Is it supposed to look like this? I don’t know what about that? What if you did this?” versus release candidate testing or what’s some times called regression testing. And that might just be bug, bug, the bug, bug bug. Because a lot of those, how it’s supposed to work have already been ironed out.

Caitlin Klink (18:29):
Correct.

Matthew Heusser (18:29):
But I imagine that some people listening to this, if they can conceptualize it, ’cause it’s a lot, we are on a strange planet

Caitlin Klink (18:38):

Matthew Heusser (18:38):
Perhaps an Earth habitable atmosphere. But everything is different and weird. Like maybe you’re used to living in a rainforest and you’re like, “Well you could live in the desert, it’s fine, you just need a well and you need to do something about the sun. It’s cold at night but it’s hot during the day.” It’s like, “Wow, this is so different.”

Caitlin Klink (18:58):
Yeah.

Matthew Heusser (18:58):
I could see how this could work. And we’ve been through this a couple of times in software. We’ve been through, “Where’s my requirements document, where’s my project? I need to know the day you’re gonna finish it before it even gets started.” Which actually I would argue is more appropriate for an Agile project. I told the director once she said that to me and I said, “Well you don’t even know what we’re building. So I tell you what, I guarantee this thing will be done by the first week in October.

(19:27):
’cause I dunno what it is, but we’re gonna iterate on it every two weeks and by the first week of October we’ll have something you can ship to the customer. I guarantee it.” She was like, “No.” Okay, so you reserve the right to inject scope at any time and you want me to commit to the thing, we don’t know what it is yet. You need to know it’s gonna be all done by October 1st, even though we don’t know what that… I’ve seen those kinds of paradigm-busting conversations and

Caitlin Klink (19:50):
Sure.

Matthew Heusser (19:51):
I would ask the audience if they think this is a little odd, you don’t have a picture for it yet. Give us a little more time to explain it. Maybe listen to it twice and see the world could be done this way. What of these practices might be helpful for us right now? Because most people in our audience are probably using Microsoft Teams or Slack or something like it already. How can we make more effective use of this? Can you explain to me the difference? You said in an async culture you have “ask a question, get an answer, not immediate” and probably less meetings but not none. Can you elaborate on that a little bit more?

Caitlin Klink (20:30):
Yeah, absolutely. One of the things that I tell companies who are trying to embrace this is that there are lots of entry points into how to start moving towards an asynchronous culture because Slack is, like I said, I think it’s the worst and best thing that’s happened to us as employees and as workers. But there are other ways to enter into this. And so it could be that you take a look at the calendar, so not no meetings, but are there meetings that we can start to eliminate? Do we need to have standup every day? Can we consider doing an asynchronous standup once or twice a week? Can we consider posting in Slack or using Confluence or something like that to communicate our updates? Is that possible? Is there a way to carve out half a day once or twice a week to have heads downtime on the calendars?

(21:20):
Are there meetings that we can start to slowly eliminate? It’s not no meetings, but it’s, “Do I actually have to do this on a call?” Think about the times where you hear somebody say, “Well, we can’t do that until so and so is here” or “We can’t make that decision until everyone is in the room.” What is the X in those? What’s the thing that we can’t do with everyone? Is that really true? Is there a way for us to leverage another tool that we are already paying for? It’s not just Slack or Teams. Jira is a way to communicate asynchronously. Email is a way to collaborate asynchronously. Google Docs, Mural, Jamboard, any of those whiteboard tools. There is a lot of potential to collaborate and communicate asynchronously in all of those tools. And so it’s not just a matter of, “Okay, I’m gonna use Slack a little bit differently and now I don’t have to have any meetings anymore.”

(22:11):
It’s more about, holistically, we are depending on everybody being in the room to collaborate. But can you think of a meeting or can you think of a week where you went all week long in every meeting without multitasking? If someone’s camera is off during a meeting and they’re not participating and they’re on mute the whole time, am I really collaborating with them? I’m not sure the answer there. So it’s a matter of starting to think a little bit differently about how we collaborate. Putting in some intentionality behind, like you said, all the tools that we have. We don’t need to meet to build a mural board. You’re gonna take this part, I’m gonna take this part and then I’ll have mine done by Wednesday. If you have yours done by Wednesday, then we’ll review and we’ll pull up on Friday if we have any questions. Rather than we meet Monday for a half an hour, Wednesday again for an hour and a half and then Friday again for an hour. It doesn’t have to be that way necessarily. Sometimes you might need to just have a working session. There’s nothing wrong with that. It’s not to say that active real-time collaboration is wrong or bad. It’s more that we maybe rely on it as the only way to collaborate and it’s not.

Matthew Heusser (23:16):
Well. Yeah. And also just standups, I can’t tell you how many, and maybe it’s because I’m a doctor, I get called to heal the sick.

Caitlin Klink (23:24):
Mm-hmm.

Matthew Heusser (23:24):
Consultant. I can’t tell you how many standups I’ve been to that are like, “Yesterday I worked on Jira 12345, Jira 12347, Jira 12396, and Jira 12399. Today I’m gonna work on Jira 12400, JIRA 12402, Jira 12403. No blockers.”

Caitlin Klink (23:44):
Right?

Matthew Heusser (23:46):
Nobody learned anything. Nobody learned anything at all from that conversation. Like what are we doing? This is just a ridiculous waste of time. You know, in consulting we talk ’em to, to tell a compelling story about what they’re working on and how they can actually use help. But one company I worked with, everybody put their status on a wiki and if you really read that wiki before the meeting, ’cause nobody ever did, I should say when we started the process.

Caitlin Klink (24:15):
Mm-hmm

Matthew Heusser (24:16):
But if you really read that wiki, what did you really need to meet for? Someone says they need help with the FUBAR module and you go, “Oh, I worked on FUBAR last week, I know all about how to blizz bar bling.” Well just contact that person directly and offer to help ’em out. So…

Caitlin Klink (24:34):
Right.

Matthew Heusser (24:34):
The value of the standup was supposed to be that it would accelerate the sprint, turn it like a crank because we’re going to help each other and we were gonna learn.

Caitlin Klink (24:42):
Right.

Matthew Heusser (24:43):
So if that’s not happening, it’s just a big old waste of time. And two, are there other ways to get to it? I could see how that could be a Google Doc or something at least a couple days a week, especially if you have testing. Sometimes we’re still organized as test teams and we’re all working dotted line to other projects and the stuff we have doesn’t really have much to do with each other. I guess that’s an organizational design problem, but you can still shift the focus of your communication toward the work that matters toward the delivery of the software.

Caitlin Klink (25:19):
Yeah. Right. Yeah, absolutely. And I mean you can leverage to use that example, I’ve worked in organizations where the testers were on a separate team and not a part of the dev teams and they supported multiple dev teams at a time. And so one of the things that I’ve done with teams like that is on our Jira board, we sort of have a status for ready for testing like in qa and that will send an email that says, “Hey Matt, I’m ready for you to test this story” and if I’ve done what I’m supposed to do in the story, all of the information that you need, Matt, is in that story with it. You see the acceptance criteria, it’s clearly written and you can just pick that story up and test. You and I don’t need to get on a call for you to test the work I’ve done.

(26:02):
It’s all contained right there. And you’ve gotten an email that gives you the green light so I can just, I don’t have to ping you, I don’t have to add noise to your notifications, I just send you an email and then you are ready to test that thing. Another thing that helps facilitate that type of engagement is including testers in the grooming on the front end where possible, if the testers are a part of grooming out what the work is and they understand the product from the beginning later on down the road, they don’t necessarily need to get on the call with a developer to hear, “How is this supposed to work? What am I looking for again?” And that really helps, especially in areas like finance where it’s super specialized and the people who do that work, it’s like a lot of SME knowledge transfer that has to happen if the testers are part of the conversation where the business stakeholder is communicating that to the developers, they already know what the point of that work item is and so they can just pick it up when the developer has done their piece.

Matthew Heusser (27:01):
Exactly. So talk to us about more of the advantages of async. What I see is some managers recommending it to their teams, they’re listening to this and I see some individuals trying it. Why should we do it? What if what we’re doing now is working for us?

Caitlin Klink (27:16):
I think that the biggest thing that asynchronous working patterns offer us is a reduction of context switching. When I land as a consultant in a new team, whether I’m a scrum master, product owner, Agile coach, whatever the title is, one of the things I like to do pretty early on is get calendar analysis. And if I have software developers, especially in a whole bunch of meetings throughout the day and you know the same holds true for testers to test something, you really need a dedicated block of time to walk through that item end to end. It’s hard to do testing with 10 minutes here and 15 minutes there, like half an hour. The value of asynchronous work is that you start to reduce that context switching and we don’t have our developers and our testers moving from meeting to meeting to meeting throughout the day. Rather they have chunks of time within the day where they can expect a distraction free work environment.

(28:11):
So that’s a huge one. I think that one is, I would say context switching is so destructive and invasive for most people. It’s a really hard thing to overcome. And so especially with the nature of the work of software development and testing as well, it can be really destructive. And so moving towards an asynchronous pattern where you know every day you have two or three hours of uninterrupted heads-down time to do the work that you have been assigned to do, all of a sudden your working environment improves drastically. Your focus is better. You’re probably able to catch things sooner, you’re able to test things more thoroughly. Maybe you can start to eliminate further rounds of testing down the road because you didn’t have to do half of the test and then go to a meeting and then finish it up later.

Matthew Heusser (29:01):
I think that’s really important. When we say asynchronous synchronous is I send a message, you send a message back, asynchronous might be I send a message, I do not expect an immediate response. What you are saying is if we’re doing that, then I’m not gonna be interrupted, and I can set my status to “heads down from one to 3:00 PM Eastern, contact me after.” And people can, when they send their question, they can say, “Send this at 3:01 PM Eastern”, whatever.

Caitlin Klink (29:28):
Correct.

Matthew Heusser (29:29):
And one of the things you mentioned was No Talk Friday, we’re not even asking questions at all. We’re gonna be heads down and working on Fridays. If you look in the literature about testing as role, there’s a lot of, I’m blocked because the web server isn’t up. I’m blocked because the deploy didn’t work. I’m blocked because I can’t log in. I can log in, but I’m blocked because the user interface support that it’s supposed to be this story isn’t there because they bingo’d the merge in Git and get and the whole, I can’t do the thing. So I’ve gotta ask and ask and ask and ask. And a good tester with experience is so good that they actually facilitate the conversation to help the software get built faster and may maybe even preempt some of the problems. Maybe they’re, whatever, lots of ways that they can add value there, but when I hear no talk Friday, that just means they’re gonna be blocked for a day. No?

Caitlin Klink (30:26):
It doesn’t have to be that way. I think no talk Friday is an easy way to just say, “We’re just gonna jam everything into Monday through Thursday and just like have all the meetings then”. There is some value in like a focus Friday where maybe you don’t have meetings on a Friday that are generated from a project manager or product owner or something along those lines. But for me, I think the maybe more optimal engagement model is it’s not a no talk Friday, it’s a no meetings Friday. But that doesn’t mean if I know you, Matt, are testing a feature that I wrote that I should expect that you might need to interact with me. Now you would need to have empathy for me knowing that I might not respond to you right away because I’m exercising my focus Friday, but it doesn’t mean I won’t respond to you at all.

(31:14):
I’ve seen more of the focus Friday where there’s no meetings rather than a no talk. I think that the idea is not no communication, it’s the idea is to start to decrease the pressure of, “Oh my gosh, I just got a message. I have to respond to it right now.” Not everything is an emergency and you can leave your coworkers on read if you will for a little while and let them respond back to you. That’s an okay thing to have happen. It’s not, “Don’t talk to me at all because I’m working.” It’s, “I’m working and I will get back to you when I’m out of this focus time.” I would argue that a more impactful way to implement asynchronous working patterns is not just to pick a day of the week and say don’t interact with each other this day. It’s more like every day we’re gonna have an hour or two where we say no meetings happen and everyone is heads-down.

(32:02):
If you get blocked within the first 15 minutes of that two-hour period, well, if you truly have nothing else that you can go to and you’re truly completely blocked, then you can send a Slack message and mark it urgent. There are things that are gonna come up, emergencies happen. I mean, not all the time. It’s not an emergency room, so it’s not constant emergencies, but things come up that need immediate attention. You just have escalation policies in place for if you are in a place where you need somebody immediately, maybe there’s a Slack thread for urgent messages and one person mans that thread each focus time. Maybe that’s the way you go about it.

Matthew Heusser (32:37):
Yeah, that makes a ton of sense. So it’s not either or. It’s more like guidelines. There will be times where we try to let people stay more heads down and obviously if you are completely and totally blocked, you can mention it, but we’re trying to be more focused. I can definitely see that working well. We use different words, but that’s closer to some of the more high-functioning organizations I’ve worked with. There was an idea called thread-based testing, thread-based, session-based test management. It was Jon Bach, you can Google it. Using Slack as an enabler of that I think could be really a nifty way. We didn’t really have Slack when that came out. Didn’t get a lot of attention at the time and now the tools have caught up with it. So using Slack in the asynchronous metaphor I think could be a really neat way. I’d love to talk about it more, but I think we’ve taken up enough of your time. Before we go, do you have either a place people can go for more or have a parting thought that puts all this together for you?

Caitlin Klink (33:41):
Yeah, we have a blog and then in terms of a parting thought, a lot of us are working remote and like things about it, but I would argue that with without some asynchronous working patterns in place, people who are working remote without that haven’t really truly been able to appreciate the full flexibility and power that remote work can bring to work life balance and flexible schedule. Remote is pretty much here to say. I would argue the more that companies can start to think about ways to collaborate and communicate, leveraging asynchronous working patterns better for everyone, for productivity, for employee satisfaction, you name it.

Matthew Heusser (34:20):
With that, thanks everyone for listening. You make the show possible. We’d love to hear from you and thank you Caitlin for spending the time and being our guest today.

Caitlin Klink (34:29):
Thank you for having me. This was awesome.

Michael Larsen (OUTRO):
That concludes this episode of the Testing Show. We also want to encourage you, our listeners to give us a rating and a review on Apple Podcasts. Those ratings and reviews help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel as a way to communicate about the show. Talk to us about what you like and what you’d like to hear. And also to help us shape future shows, please email us at [email protected] and we will send you an invite to join the group.

The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on the testing show or if you would like to be a guest on the podcast, please email us at [email protected]