At the heart of the issue of post-COVID “back to office” is trust, or lack thereof, from management and the sense of disempowerment by the employees. Fair enough, nothing beats face-to-face interaction and there is valid cause for making in-office work back the norm.
So as leaders, what can we do to lessen the stigma of “back to office” and help our people feel that they’re not necessarily “giving up the freedom of how to work” they discovered during COVID times? The key is asynchronous communication and its effective use in balance with synchronous communication.
Here’s a replay of the session.
※ Join our next Mental Model Dōjō community session (free) from here: https://agile-od.com/community-events ※
It’s October 2023. Covid lockdown was only a while ago, and it already feels like a distant memory. Remember full-remote working? Well, with many companies making back-to-office mandatory, those are long gone days for a lot of people.
There’s a lot of resentment with “back-to-office”. Fair enough, nothing beats face-to-face interaction and management has valid reasoning to call us back into office. But at the heart of the issue is the sense of disempowerment; the feeling that we’re stripped away of our agency. It feels like we’re not trusted on how to work.
So today’s topic is, as leaders and managers, how might we lessen the stigma of back-to-office and help our people feel that they’re not necessarily “giving up the freedom of how to work”? The key is in asynchronous communication, and its effective use in balance with synchronous communication.
Okay, let’s first start with the basics, what is synchronous communication, and what is asynchronous communication.
Synchronous communication happens in real time. It can happen in a same physical space setting, or over various communication devices. The key attribute is that synchronous communication requires the other party’s immediate attention.
So, face-to-face conversations, phone calls, video calls, meetings as in both physical and virtual meeting rooms, and even chat messaging that you’re doing in real time, these are all examples of synchronous communication that we do everyday.
Asynchronous communication is done in non-real time, i.e. it happens over a period of time. In asynchronous communication, the recipient of the communication can respond to the communication in non-real time. This is a very important distinction because, as soon as the communicator “requires” the recipient to respond immediately, then it becomes synchronous communication.
Asynchronous communication is not a modern invention at all. E-mail, fax, snail mail like the ones you write on paper, put them in an envelope and send them out (they’re called letters by the way), these are all classic forms of asynchronous communication. Bulletin boards like the ones you post giving away your toaster, and lost my cat, those too.
And then we have the tech enabled ones like the digital message boards such as Slack and MS Teams; the whole bunch of business dashboards such as ERPs, i.e. Enterprise Resource Planning tools which is a giant industry itself with SAP, Oracle and so on, CRMs, which is Customer Relationship Management tools such as Hubspot, and then for us agile professionals, Jira, Kanban boards and so on, these are all examples of the many modern tools we use for asynchronous communication. Cloud drives like OneDrive and Google Drive, and I’m not sure how many people still use it but like DropBox, the sync and share functions of these storage solutions are also a major tool for asynchronous communication that everyone regularly uses.
Now chat messaging, like WhatsApp, this is a funny creature, as it can be both real time and non-real time. So messaging done non-real time, this is another form of asynchronous communication
A unique attribute of asynchronous communication is that it requires tools and setting up processes.
Even classic asynchronous communication tools required set-up; you need two fax machines to send and receive faxes, to send snail mail you need the postal service and even a letter box to receive the post mail, and so on.
Now one important thing to be aware of is that, the requirement for tools and setting up the processes for asynchronous communication, includes, getting the other party to agree and abide to the setup and process.
So there’s an adoption hurdle to asynchronous communication. Facebook tried to sell a business version of Facebook Messenger called “workplace”. I had a client organization adopt it and was forced to use it for team communication. Guess what happened? The important and “real” messages happened outside on WhatsApp.
So if digital asynchronous communication tools are setup for the teams but no effort is made to help people agree and buy-in to use that platform, adoption will be incomplete. And if adoption is incomplete, then the information captured and shared there would be incomplete too.
This highlights an important benefit of asynchronous communication: that is, natural, good quality, record keeping. If the asynchronous communication that the team is using is functioning well, then information is captured and shared effectively. This is a real big benefit of asynchronous communication.
So far we talked about synchronous and asynchronous communication. Now I’d like to bring the attention to synchronous and asynchronous “work”.
Synchronous work when we work with others, as in pairs, trios, in a group or team, in real time. To do synchronous work, we need to be in the same place at the same time. The place can be both in a physical or virtual space, that part doesn’t matter.
Asynchronous work is when we do solo work, the solo portion of group or teamwork or work you are doing with another partner. As we do our independent work in our own time and place, in this case we don’t need to do the work in the same time and place with others.
Meanwhile, we will need a way to capture and share our work. This is a clean characteristic of asynchronous working.
And guess what, lo and behold, agile embraces asynchronous and synchronous work ingeniously by design. This doesn’t come as a surprise as agile is a serious attempt at making teamwork work, and good teamwork come from a balance of effective synchronous and asynchronous work.
For example, Agile Scrum and Design Thinking as a practice separates thinking and doing time; which is what David Marquet calls blue and red time.
In Scrum, we start with thinking time, i.e. blue work, with Sprint Planning, and then concentrate on red work, i.e. doing time, during the Sprint, and then finally come back with thinking time to inspect and reflect the work with the Sprint Review and Retro.
In Design Thinking, we empathize with the user, define the problem and ideate the solution, all generally blue time, before red time with prototyping and testing, and then we go back to thinking time to improve with iteration. Build, measure, learn, repeat.
Let’s take a closer look at blue and red time in Agile Scrum and its relationship with synchronous and asynchronous work.
The three mandatory blue times in Scrum, i.e. Sprint Planning, Sprint Review and Retro, are timeboxed events for synchronous work as a team. This is an acknowledgment that team members do need to synchronously communicate with each other when deciding, and decision making is a key word here, on what to do, how to do, and aligning and learning, again more keywords here, in this case we can summarize it as generating shared understanding, of what we did and how’d it go.
So these sync times are necessary and Scrum builds that into the design of teamwork. And the genius here is to make these sync events happen at regular timings and in a timeboxed way – putting discipline here is a management technique.
Then during red time, i.e. doing work time, the design of Scrum is to give as much liberty to the team on when to work synchronously and asynchronously. The only synchronous working requirement in day-to-day work here is the 15 minutes daily standup. Other than that, it’s up to the team for who, when and how to do synchronous work.
Finally, in Scrum we almost always use Kanban boards. That’s because it’s a powerful tool to stay organized despite heavy reliance on asynchronous work. Kanban is a persistent, visualized information sharing tool that uses a pull-system of work, making it easy to coordinate asynchronous teamwork where things are literally “obvious”, because you can see yours and others’ work, and efficiently highlighting areas of work where synchronous communication is needed. Pretty genius, right!
So agile teams are lucky because consciously or not they get to enjoy productive teamwork with a good balance of synchronous and asynchronous styles of working.
But not all teams are agile, and sad things happen when leaders and managers aren’t conscious of the difference between synchronous and asynchronous work. So let me bring up this slide again and ask two important reflection questions.
First, I mentioned that for asynchronous work, people do not need to be in the same time and place to do their individual work. Therefore question: What happens when people are asked to do asynchronous work in a synchronous setting? So, the scene where you’re in office, sitting side-by-side with your colleagues, quietly doing your own work.
Here are some things that participants in the dōjō session shared.
- Why am I here. I could do this from home. I’m more productive working from elsewhere, like a coffee shop.
- Stop monitoring me. I feel untrusted. It feels like I’m treated like a kid in school, told to stay in my seat.
- I hate being distracted. Don’t talk to me. Can’t you see I have my headphones on?
And how’s this situation for the manager? Do they like it? No, right? They resent monitoring people too. And especially, as I mentioned that effective asynchronous communication requires tools to capture and share work, what happens when managers manage the team’s asynchronous work without the right asynchronous tools?
Doing asynchronous work in a synchronous setting is exhausting for both the worker and the manager.
Final big question on the whole back-to-office phenomena. What is the problem of forced synchronous work, and what do we do?
Forced synchronous work is a manifestation of the fundamental, even before Covid times, mistrust between worker and employer. We still drag the factory model of organizations from 1920s Taylorism. Organizations still treat people as machine parts under the illusion of efficient management with instructive leadership, i.e. we need to tell people what to do and we need to monitor and control them so that they do the work. It’s very inhumane because it’s strips people of their agency. No wonder people feel strong resentment with back-to-office and forced synchronous work.
So what do we do? At the individual manager level, awareness of the difference between synchronous and asynchronous communication and working is an important starting point, and setting up your team for effective asynchronous working is going to be very helpful.
But back-to-office itself is largely an organizational problem, and onus is on leadership. Almost all back-to-office directives that I’ve seen are not asks but an order, so the worker sadly has no say in the matter, again aiding to the feeling of powerlessness. So leaders, do something about it.
Here’s what I suggest. We live in the age of Diversity, Equity and Inclusion, right? Emotional intelligence and psychological safety, that’s officially endorsed in one form or another as leadership values in most organizations, correct? If so, let’s be true to those words.
Consider a better handling of back-to-office as a practice of DEI and Emotional Intelligence.
An inclusive, dialogical process of involving people in the why, what and how of back-to-office will go a long way addressing the sense of resentment and powerlessness. So yes, do it in a “Fair Process”.