There’s got to be a better way to work
6:25 am
Nita pulls herself out of bed, having snoozed her alarm five times already. Oh boy, she’s late! She shakes her son Abin awake. They barely have 30 odd minutes before they drive to school. Dang it - she has to drive. She’d much prefer to take the scooter, but it’s pouring outside. If only she could control the Indian monsoon.
Ok, 30 minutes. Freshen up, make some coffee and get Abin’s lunchbox ready. Drat! She forgot to order milk. Thank heavens there’s milk powder at home. She hustles to get a couple of sandwiches ready as she fries some eggs on the side so Abin can have breakfast.
7:45 am
That wasn’t the start Nita was hoping for. Life as a single mom is hard. They barely made it to school in time. She’d have liked to wake up early and stay on top of things, but she doesn’t feel like she got a good night’s sleep, anyway. Work doesn’t begin till noon. Maybe she can sleep now? Or maybe not. She’s got to cook, get ready, put the trash out, and get the dishes back in place. That won’t happen by itself, will it?
12:00 pm
Nita works a mid-day shift. Work at home in Bangalore begins at 12:00 and, with an hour’s break thrown in, ends at 10pm. She works for a client in Boulder, Colorado, and some of her American team mates are based out of Boise, Idaho. This is the only way she gets an hour to overlap with them for meetings. She tried getting 30 minutes of shut-eye before starting work, but she ended up just tossing and turning in bed. The day’s barely begun, and she feels exhausted.
2:30 pm
Time to pick up Abin. There goes 40 minutes of her break time. Lunch was already at breakneck speed - coffees and dinners will probably need to be at the worktable. Sigh.
5:00 pm
On some days, Nita wonders if she’s getting any work done at all. The last four hours have had two hours of meetings - one meeting to onboard a new team member, and another meeting to discuss the sprint planning meeting later this evening. As a designer, she’s trying to build some wireframes for a new feature the team’s set to deliver in an upcoming sprint. She tried to make some progress independently, but there wasn’t enough contiguous time or enough available information to get her started. Time to meet the team’s business analyst.
9:00 pm
Abin got back from cricket coaching; showered and warmed up dinner. He’s a good kid. Before heading to bed, he hugged Nita and kissed her goodnight. “Tomorrow will be an on-time start.”, he promised. Nita’s been powering her day with coffee. The team’s now in a sprint planning meeting with the folks in Boise and the client in Boulder. One more hour to motor through. Thank heavens for that coffee.
10:00 pm
Aargh! She’s not done yet. The client asked for some changes to the proposed iteration plan. Nita’s got to pull out wireframes for user stories that are kind of ready, but not quite. The team huddle is in 15 minutes.
11:00 pm
Finally, time to get some sleep. Uh oh! Hold on. She’s got to put the milk bag out, and double check the milk order. Abin wasn’t as good a boy as she thought, either. He didn’t clean the kitchen before heading to sleep. Time to roll up her sleeves and clean up.
She gets the job done, changes, brushes, flosses and gets into bed. Try as she might, she just can’t sleep. Too much caffeine in the system? Too much of that bright screen? Who knows? Her attention shifts to her phone. The team’s discussing the change in sprint plans. Maybe she should tune in until she feels sleepy.
Phew! That day, unreal as it may be, is commonplace for many remote working technologists working across continents. Nita’s character is fictional, but her story is real. Of course, work hours can differ depending on the time zones the team’s distributed across, but the context switches, the highly interrupted days are commonplace regardless of time zones.
In 2020, the global pandemic sped up the shift to remote work. To be sure, that was a change in the right direction. In a day and age where we have powerful computers in our pockets, great tools for online collaboration, and reasonably good internet connectivity in most places, it was strange to make people go through hours of commute to just be in a noisy office every day. People made considerable sacrifices in their personal lives to just have a career. For those with a single-minded devotion to that career, it was fine - but there are others who look for balance in their lives. And so, remote work came with the promise of restoring that balance. It gave organisations a way to tap into talent pools they hadn’t considered before, simply because they didn’t have offices in that area. If you can now work from anywhere, an organisation can employ you from anywhere. Knowledge workers are always more in demand than in supply, so being able to widen the talent pool gives employers a way to scale despite the constraints.
The purpose of this article isn’t to eulogise remote work, though. There are plenty of books and articles to do just that. The question I like to ask is about Nita - is there a better way to work? The shift to remote work in 2020 was so sudden that many organisations never had the time to consider if the same work practices that felt effective in an office are also relevant for remote work. As a result, you see many individuals, such as Nita, continue to make compromises to work life balance, their mental and physical health and their ability to do deep, meaningful work. There’s got to be a better way to work.
Starting with this article, I want to embark on a series of posts that articulate a new way of working, especially for software development teams. That way is to embrace “asynchronous collaboration”. What is it, you may ask? The best way to define it is to combine a few definitions I’ve heard from Lattice and Remote.com.
If that sounds quite different from the way you work today, let me take a few more minutes of your time to explain why you should consider making the shift to this way of working.
Software development is getting more complex
When I started my career in IT, the problems we solved for clients differed greatly from the problems we solve today. For example, very few clients expect us to build simple CRUD (create, read, update, delete) applications - low code platforms have disrupted that space. How about simple storefronts? Services like Shopify have disrupted that space by simplifying it for non-coders. With services such as managing large data centers - the hyper scalers such as Azure, GCP, and AWS have made it easy for in-house IT teams to manage infrastructure.
The work we do today is far more complex - we build platforms and data meshes, deep learning and neural networks. We modernise decades old legacy systems to give incumbents a way to compete with digital native disruptors. We explore new ways to develop the human-machine experience. It’s impossible to run these kinds of projects with:
an overdependence on meetings, conversations and tribal knowledge;
a lack of good written communication;
and without a commitment to deep, uninterrupted work.
Asynchronous collaboration comes with the promise to meet only when truly necessary, to make conversations productive and to give people time so they can actually work.
The promise of flexibility
I recently surveyed over 450 employees in a leading software development unit and asked them what they dislike about their work. The number one response from over 50% of the respondents - long hours. This is almost antithetical to the promise of remote work. Luke Thomas and Aisha Samake, in their book, The “Anywhere” operating system, outline this promise.
Indeed, only 14% of the people I surveyed wanted to go into an office every day. In fact, while two out of three people want to work “regular hours”; i.e. nine to five; one out of three people want flexibility. And these expectations are changing. Asynchronous work affords people that autonomy to work the hours that are most productive for them. More importantly, it lets managers and employers project a shared sense of trust, autonomy and empowerment.
Escaping the shallows
As a product manager and an aspiring designer, I was always at sea in an open office. If the constant white noise wasn’t bad enough, the fact that I was “right there” implicitly meant that I was available to be interrupted. I got little joy out of my working day, especially when I needed to get work done for the team and when I needed time head-down.
When we started working remotely, though, I could cut out the white noise. Suddenly, I had my corner office. Except, of course, it was a room in my house. What didn’t change were the interruptions. The across the table interruptions now became video meetings and all-day back-and-forth messages on our instant messaging platform. Like Nita, I’ve struggled to get time to do deep work, when my day’s cut up into little one hour chunks. Paul Graham noted this eloquently in his 2009 essay - maker’s schedule, manager’s schedule.
Asynchronous collaboration advocates for “meetings as the last resort, not the first option”. If your current collaboration practices need loads of meetings, I understand that’s going to sound radical. Similarly, asynchronous collaboration advocates for using communication tools thoughtfully. The sentiment I’d like you to empathise with is that interruptions have a cost - not just in terms of the time spent in the interruption, but also as a fallout impact on productivity. Mihaly Czikszentmihaly, in his bestselling book Flow - The Psychology of Optimal Experience, speaks of a state that most of us want to get to at work.
Here’s the killer though - while 97% of the people I surveyed claimed to care about “flow”; only 12.5% - i.e. one in eight people actually claimed to achieve it with regularity. Asynchronous work promises to give people a better chance at achieving flow.
The other aspect of deep work is the ability to have deep interactions with co-workers. In his landmark book, Thinking fast and slow, Daniel Kahneman outlines two systems of thinking. “System 1” is an intuitive and fast way of thinking. You call System 1 for the answer to your parents’ names, the result of 2+2, and for how you navigate your own home. Anything that needs slightly deep thought - double digit multiplication, for example, needs slower thinking. Kahneman calls that kind of thinking “System 2”. System 1, being as instinctive as it is, can help us decide at speed, but is also prone to biases and errors. An effective approach to work should combine both system 1 and system 2 thinking.
A culture that defaults to meetings as a way of working is constantly operating in the realm of system 1. There’s barely enough time to slow down, go a few levels deep and analyse things. You lionise responsiveness and presence, but deep work becomes the casualty. Asynchronous work prioritises good analysis and thinking. When you do meet, people have given enough thought to a topic, and are meeting for a specific time boxed purpose that needs intense collaboration. You can now make the deep work you’ve done so far; deeper.
A more inclusive workplace
The people I surveyed were all in India. Their unit was only serving clients in North America. Many people were straddling time zones with up to a thirteen hour time difference. You don’t need me to tell you that this is hard. And if something is hard for most people; it’s harder for historically under-represented groups. Take women in IT, for example. Even after years of conversations about the topic, women’s representation in IT is likely to be 33% in 2022. In technical roles, that goes down to 25%. For the group I surveyed, women were just 28% of the respondents. The leadership of that group only has 18% women. We don’t have the data for other historically discriminated groups, but it’s safe to assume that they find poor representation as well.
Working across time zones is hard, but even a tight schedule with loads of pre-scheduled meetings isn’t easy. It’s especially hard for women, who bear a disproportionate burden of household and childcare responsibilities in most societies. Now let’s imagine a workplace without arbitrary start and end times. Where people work in schedules that make sense for them. When we don’t have the pressure to cram all communication into those specific eight hours. Getting rid of those constraints can help more people find a way into the workplace. We can’t change society overnight. What we can change is the workplace - and that’s the promise of being asynchronous.
While we’re on the topic, consider the diverse personalities in the workplace. There are introverts who will rarely be the first to voice their opinions on a topic. There are people who’re non-native English speakers, who may be deep thinkers, but lack the confidence to articulate themselves. Asynchronous communication allows them to have the space to share their thoughts and ideas at a pace convenient for them. Modern writing tools allow non-native English speakers to correct their spelling and grammar. Introverts now don’t have to be the loudest voice in the room. If diversity is being invited to the party, and inclusion is being asked to dance; asynchronous work helps that inclusion.
In software engineering, there’s always a choice between waiting to be perfect and being wrong at speed. When everyone was in one office, sitting at one large table, people could unblock each other by ‘giving each other a shout’. Never mind the fact that the person who needed to unblock you might have lost their own flow. Still, you were one step close to being perfect. Using the same approach in a remote setup creates many problems. It’s very hard to keep track of who is free, who is busy and who you’re interrupting when you’re giving each other a shout. Remote.com speaks of the concept of ‘defaulting to action’ in such a situation. Sure, interrupting someone can help get your work close to perfection; but you can’t overlook the impact it has on the person who is unblocking you. Instead, you choose to be wrong at speed. It’s ok, if you have to backtrack at a later point, but it’s better than waiting to be unblocked.
Defaulting to action optimises for speed and throughput, but it also encourages thoughtful communication. For example, a well written user story may preempt the need for a story kick-off, where a developer, product owner and tester discuss its implementation and testing approach. A simple screen recording attached to a user story, can allow a developer to continue development, while giving the product owner and the tester a way to review the implementation, without interrupting what those two might be up to. Sure, the trio may need to meet up to iron out some sticking points - but the mantra of “meetings as the last resort, not the first option”, comes good here. If the developer does have to backtrack, it’s also feedback for the user story. The product owner can incorporate this learning into the next set of user stories they write. When in doubt, teams that adopt asynchronous communication just execute.
Asynchronous collaboration isn’t black magic. Getting time back to do deep work isn't a freebie. In return, people have to be clear communicators - mostly through writing. I’ll come to the specifics of this in future articles, though I understand that writing can be daunting for most people. This isn’t creative writing, though. It’s just plain English. Here’s how I characterise good writing for team communication.
It’s as short as it can be, but with enough reference to context that someone new to the team can understand.
The writing is free of jargon, and simple enough to understand.
The writer shows empathy for the reader. For example, if you expect questions, you answer them in the text you’re writing.
Many of us have earned our stripes in the agile world where we learned that we value “Working software over comprehensive documentation”. If you recoil at the thought of writing, I totally understand how you feel. The fact remains that the agile manifesto itself is over two decades old and at the time of its writing was reacting to a very different set of problems. Few agile projects were distributed, for example. Lest we forget, the manifesto also said, “... while there is value in the items on the right, we value the items on the left more.” I argue that with distributed projects where teams are working remotely, there’s even more value in some items on the right - particularly documentation, lightweight processes and enabling tools.
So yes, many of us will learn to write better. What I hope we’ll realise is as the adage goes,
The act of daily writing brings with it many advantages, including but not limited to the ones below.
An audit trail of decision records.
Reducing FOMO, because everyone can now know what’s happening in any part of the project. No need to attend a meeting to learn what happened in the last meeting!
As projects and organisations scale, tribal knowledge and a system of “he said, she said” don’t scale. Effective writing and thoughtful curation have a better chance at helping you scale, even as old people leave and new people join your team.
Like most practices, asynchronous collaboration isn’t a silver bullet. It won’t solve all your problems. Regardless, it’s safe to assume that every team that does any creative work will benefit from embracing asynchronous practices. How far you go with it will depend on your appetite for change and your team’s context. Over the next several articles, I’ll help you build a strategy to adopt asynchronous work for your team. Up next, are all the reasons this probably won’t work for you.