Hello. All righty, everyone. My name is Joe Nash and I don't have access to my keyboard. There we go. My name is Joe Nash and I'm here to talk to you today about Principles for Asynchronous Working. I myself have been remote and asynchronous since 2013 at a variety of companies that do -- that where I worked remote and asynchronously for different reasons. At some of those, it was because I was traveling a lot, at others, I was part of a globally distributed team. And at others, it was just because of the fact it was a remote-first company. And because in more recent times, we are increasingly remote and asynchronous. Thanks to the ongoing global situation. This is increasingly a way of working that we need to adapt and excel in. I'm here to share what I think are useful lessons in working asynchronously that I hope will serve you well in your working life. So, start by talking a little bit about space and time
And what I want to talk about here is the difference between remote and asynchronous. What do we mean when we say we're working asynchronously? Remote, that's physical location. Not working in the same place. All working from home, but still in London or New York, all in the same city. We just don't share an office. And that imposes differences on the way we might work and collaborate with each other. But it is a far thing to working in time separation where we're not working at the same time. When I say not working at the same time, I could mean something like working in completely different time zones. I'm here in the Netherlands, and you might be a country and we're physical distance and time, but maybe not the same hours. You might clock off at 3:00 to pick up your kids. I'm not online at 10:00 to walk the dog. That's another fact of life that is time separation. It's that we're here to talk about - asynchronicity.
Working asynchronous tends to support working remote. But when people say they work remote, they don't necessarily mean they work asynchronously. It's important to keep that distinction in mind. If you're applying to a job that says it's remote-first, do they mean they're asynchronous or just that they don't have an office? Talking about asynchronicity today.-here's some JavaScript. Excuse me for me putting JavaScript on your screen. Why is asynchronous programming important? Why do we think about asynchronicity in our code when we write code and do technical things why care about asynchronicity? Asynchronous operations do not block other operations. When we do is something asynchronously, other threads in the program can continue to happen and execute and deliver their work. And that is the same principle when we're working asynchronously. We care about working asynchronously because we don't want to block people in day to day work. We want everyone to be equipped with everything they need to do their work and deliver. And we have everything we need to do our work and deliver. How people might be blocked in day-to-day work is getting to the root of how to effectively work asynchronously. The question I want you to ask yourself right now. What do you need to do your day-to-day work?
What is it that when you sit down at your desk, what do I need to do my work? Some things that I think are important. You may not have these answers. But we need four things, context, permission, and materials. That's three, not four. Context, permission and materials. What comes under context? We need to know things like who is working on a project? You know, who is involved with this particular piece of work on delivering? What is the work I'm delivering? What is being done? What is the history of that project? When does it need to be delivered by? You need to know when your deadlines are. Why am I working on the thing I'm working on? How is this to be produced? How am I meant to be working on it? What has worked and tried in the past? What do I need to keep in mind as I'm going through the implementation of what I'm working on? Then we need this vague topic, permission, but you can equally call this trust. You need to know that you are trusted to execute on the work. And this is really important asynchronously because you are often working independently because you're not in the same time zone as someone else, or because you're not working at the same time as someone else, you can't constantly say, hey, is this right? Am I doing this correctly? Is this what you had in mind? You need trust. It's one of the most important and empowering aspects offing your asynchronously. And along with that comes that right. That you're trusted to execute the work, but that you have the authority to make changes on the fly. If something changes in the project, can't wait for your boss or someone else to have the authority. consensus is part of this. It's important to providing both trust and authority. If you're not sure that you have consensus, if everyone involved is not in alignment, with the company alignment, if everyone on the project is not in agreement on how the project is being executed, it's hard to derive trust and authority and then precedent is useful for this. Knowing what has happened in the past and what decisions have been made in the past help inform the decisions in the future. Precedent can lead to trust and authority. And finally, you need the materials. Any past artifacts, might be existing code. Might be assets. Assets and also things like Templates in the case of documents. Things that, you know, have been developed through the institutional knowledge of the company, right? Things that have been -- that you can build upon to deliver your own work.
And all of these things, you may not necessarily think of when you're working day-to-day. Might exist around you, permeate the company. They're a blocker if they're not that. If you are the only one working and don't have the right to make a decision change, it's a blocker. If you are the only one working and there's as asset and you don't know where it belongs, or don't know how something is implemented, that's a blocker. We want to make sure these are available for everyone working all the time. Where do you gelt this information? Where do you find those when you're doing your work? Where do you go to look for the history and the context surrounding the project? Where do you go to find out what the group has agreed upon and what the consensus on the direction of the project is? If your team members are offline and you're the only one working, how do you find this information? And more importantly, how do you provide this information. Going about your work, you are generating the artifacts and the institutional knowledge of your company. That's needed by someone else, your virtual colleague, when they woke up and you go offline. Or someone long after you have left the company and they have to pick up your work. How to make it available and communicate things like trust and consensus so you can be non-blocking? If you don't already knows answer to that, we're gonna get into some best practices for doing with it with some quickfire best practices. Things I call principles. These have kind of been reverse engineered, they have authoritative-looking titles.
What's worked at previous remote-first companies. Some had very successful asynchronous cultures that were very particular to the history of that company and so it's hard to replicate. I've tried to choose the best bits that worked for those companies, but that might be relevant for you no matter how your company works or is formed today.
So, let's go through some best practices and talk about how you can be non-blocking and how you can encourage your colleagues to be non-blocking.
So, my first and most favorite one is put a URL on it. Another way to explain this, if it doesn't have a URL, it didn't happen. What we're trying to do here is encourage everyone to take information, to take things that are generated spontaneously or to take spoken word and to record it somewhere where it can be shared, right? If something has a URL, it can be shared and it can be found. And that's super-important because it first of all enforces documentation. If you have a conversation, that's just a conversation. But when you write it down somewhere, it now has a URL. So, by ensuring that everything that happens, every decision that is made has a URL, you are naturally enforcing documentation. As I mentioned, it facilitates sharing, it's far easier for people to get hold of stuff if you are producing things in a way that provides for easy sharing. Even Slack messages are a example. You can link to Slack messages and link to the Slack thread and say here's the discussion that happened last week. Google documents, GitHub issues, all of these things facilitate sharing through the existence of URLs. It builds the web, builds the institutional knowledge. As you put URLs on things, you can reference the documents. Connect documents together and build through this tree of referencing. Someone opens the project brief or a GitHub issue you have been working on, they see the things you are referencing and know where to look for the context, for the consensus. They have this web of institutional knowledge that is available because everyone is putting a URL in it.
This is just straight up quoted from a GitHuber, Ben Batler will talk about at the end, but if you answer the question more than once, write it down. This is in general good practice for life. If you are asked a question by a colleague, something is repeatedly asked in a Slack channel, stick it in a Google Doc, share it. A way to make sure any institutional knowledge with you is distributed around the company and seasoned siloed in you. This is a useful heuristic for working out how you can make sure the artifacts you are generating are available to everyone. By asking yourself constantly, where are the search boxes? In my company, where do people search for things Google Drive? Slack? GitHub search bar? You should be search aware whenever you create something. This is particularly true if you're using tools that other people in your company don't necessarily use.
If you're producing Airtable sheets or Mira boards, how does someone without a login to those services find the knowledge that you have created in that document? So, always be checking whenever you're using anything, hey, how might other people expect to find this? Where might they look for it? If they don't it exists, if someone doesn't know a document exists but suspect the knowledge exists somewhere, where might they find or search for the document? This also links into how does someone who is not even aware that someone at your company does your job, how would they find it? What terms might they search for to say, hey, I wonder if someone at this company is looking after XYZ? What terms do they search for? What terms does someone not on the inside will search. Make sure that's found in search bars. And that leads to what's important in the search engine. Unfortunately, we use Google Drive, a piece of software made by a search company that forgot how to use search engines. Sometimes we know software makes it difficult to do things and we need to shape our documents in a way so that the information we want to be exposed does get exposed to the search engine. This is setting obvious or weird titles and having very particular title formats. Making use of metadata in some ways. Understanding the software that you're using and how it influences how people find knowledge is really important.
And then one is another really key one. Which is defaulting to open over private places. And I'm sorry, this is a direct call out for all of you who spin up a Slack DM with five or six people whenever you want to discuss something. Thinking about the search bars and where to get knowledge, we want to default to open spaces, open channels. They are discoverable and acceptable. There's a lot of psychological safety in DM, creating a direct message thread. But we want the knowledge to not disappear whether that DM is archived. Create a channel rather than a Slack DM. It feels messy and un-neat, but that information is shared with everyone in the Slack search bar if it's public.
Default to open where possible. Some company have a higher permissive environment where you can't have the open settings. If you can, default to open whenever possible so everyone can find the knowledge and not have to ask for it. If you are someone who defaults to private communication or lockdown documents to avoid drive by feedback, which is more common for some demographics. I am a fan of the 30-60-90, look that up. I'm looking for 30% feedback or 60% feedback or 90% feedback and then I link to the framework. It lets people know in that document, there's certain types of feedback I'm just not interested in right now. It helps me know if someone stumbles on to the work, I'm not going to be beset by drive by comments.
And then obviously, if you're defaulting to open, be aware of personal user and confidential data. Don't go sticking a spreadsheet with all of your customer's data on the most permissive settings and accidently leaking it. This is a better strategy for team discussions or for project designs, this kind of thing, than it is for certain types of data.
On the topic of psychological safety. Overcommunicate and overcompensate is just a -- a key one whenever you're using text-based communications. First of all, you don't want to assume that the reader know what is you're talking about. If you drop into a Slack channel and continue a conservation that's happening elsewhere. That user may be at a different time, coming from a different task. Basically the conversation isn't continuous. Assume that time has passed. Try to add context when possible so anyone reading it can understand what's going on without having to have been there. Right? If someone is context switching, it's hard to keep up with the conversation. Overcompensate for tone. This is something that is found to be true. When I joined a company in the past, someone said to me that -- this is a remote-first company. Someone said it's much easier to understand when you have heard their voice. This is rung true for me. I have worked with a colleague, for the first year of working with the colleague, I thought they hated me, were angry. They seemed really terse. Like I was annoying them. We weren't getting on well. I met that person, they were a great colleague. Really great person, sensitive, caring. They worked hard to make sure everyone on the team had what they needed.
and being able to read what they were saying in their voice suddenly shifted basically the way I felt about everything I had in the past. If you are working with someone you haven't met face to face. Overcompensate. Do they know how you speak? Emoji-bomb it. Lean into it. If there are feelings, if you anticipate there are feelings attached to the message, straight up say that. Hey, I appreciate this is out of the blue or may be scary. Here is why I'm asking. That kind of thing.
Now, all of the things I've said are really hard work. It's a lot of extra thought every time you send a communication. It's a lot to, a lot to think about. So, but there are some tools out there that generate all of this kind of for free. So, try to look for tools where this stuff comes as a byproduct. So, for example -- whoops, sorry. GitHub issues is actually a system that does this really well. When you're communicating in a GitHub issue and go and change some code, that change gets brought into the conversation and could be tagged into the conversation in time. So, every who used it can see the conversation about the code and then they also actually see the change happening and then they see the conversation continue. There are other tools really good at this, and some tools really bad at this. Again, Google Drive is unfortunately a tool that's really bad at this. Comments in Google documents are where context goes to die. Like if you anything as a Google document comment, it will disappear into the ether. Try to look for tools that produce good, discoverable knowledge and it will make your life a bit easier as you go.
And then finally, no one is async unless even is async. If you have a team that's working really hard to be async and then some members of that team go off and have a face-to-face meeting and they don't document it, suddenly that knowledge is lost. Someone has to have a synchronous meeting to get that knowledge and get it on track. It all crumbles and falls apart. It's fragile. And part of making sure that system stays resilient is to play finders keepers. If you find some knowledge that's undocumented, if you find something, if one day you're working and you don't have something you need, congratulations, you're now responsible for making sure that knowledge is discoverable for everyone else. You need to be the keeper of that knowledge and share it with the rest of the team and take something that's synchronous to being asynchronous. And it means challenging the defaults. Trying to make sure everyone stays asynchronous is really important. As Naomi kind of covered in her talk. There's lots of benefits to meeting properly and to not meeting at all. You know? If you're doing updates, there's lots of reasons why not meeting can be better for lots of teams and lots of contexts. And sometimes keeping the team async means you stand up and say, do we need this meeting or should this be a document? That can be uncomfortable and should be shared. If you're finding that is falling on certain members of the team, that needs to be challenged as well. But unfortunately, it's very necessary. Of and kinds of the summary is write it down. I love this quote from Leslie Lamport, LaTeX, writing is nature's way of telling us lousy our thinking is. If you're someone who doesn't excel at written communication or find writing your ideas down really hard, this isn't a call-out of you. What this is saying is sitting down and actually expressing our ideas to ourselves, whether that be in writing or video or audio, is something that a lot -- is a process that a lot of us don't do before we book a meeting, right? We tend to have an idea and want to bat that back and forth with someone. But often actually making a moment to ourselves and preparing and thinking about it reveals lots of problems that we would have kind of exported on to something else. This is a great thing about asynchronous working, you develop a skill for rubber ducking yourself. For revealing where your problems lie and revealing problems and shifting to a much more coherent way of expressing your ideas. I'm writing it down, again looking for things that are indexable and searchable. Writing is hard. Don't be afraid to record a video or audio. Kevin is a great one at using audio transcription to send messages and things. And if you are sending audio or video, remember, it needs to be indexable and searchable. So, you want to get your thoughts together before you record that video. So, it produces a good transcript. And make sure the transcripts are shared in the places where the search bars are so people can find that content via search and not have to watch a whole video to get the context. A record on its own is not sufficient.
I'm running short on time. Quick five challenges, things you will run into. Where is the source of truth? If you had one place in your company where all the knowledge lives, where is that place? Chances are, eight places behind eight logins. That's a nightmare. Go to as few sources of truth as possible. Which tool? Does everyone have a to it? It's really key. Who is the owner of knowledge? This is important for knowledge forming out of date? And how do you find the teams exist? Again, where are the search bars? Documenting how you work with someone is a really important part of asynchronous working. This cuts down on those aimless meet and greet sync meetings. A practice from GitHub that I miss is having a README. A team API, who is this team? What do they do? How can you work with them? When ask yourself, sync or async, watch Naomi's talk, whether this needs to be a meeting. If that fails, you can always jump to the wonderful blog boast by Ben Batler, why-async at ben.batler.com. If there's one thing you screenshot, screenshot this slide. Ben is a fantastic documentarian of GitHub's culture. And GitHub, for all of its faults has a fantastic remote and asynchronous culture. And Ben has years of information about how GitHub communicates asynchronously. And this more recent blog post it probably one of the best for inclusivity and work culture benefits of working async that you will ever find.
If you have colleagues in doubt about the benefits of working async, or you yourself are not convinced, highly recommend you read this post and then dig into Ben's other content and start to use that when you question whether to meet synchronously or asynchronously. I'm Joe Nash, happy working when other people aren't.