DigiScot Talk: Asynchronous working as part of a learning culture

Introduction

I work on the product team that focuses on young people -facing products. That includes the digital services we build ourselves and the off-the-shelf products like Zoom and Teams. Our team has about twenty people and we’ve never all been in the same meeting at the same time. We work asynchronously, which for us means being in-sync about the important things; the outcomes of the work, and not being tied to less important things like having to all work at the same time and in the same way.

We don’t have all the answers. We’re still learning how to make this work for everyone, but three of our priorities are how we learn and share knowledge more effectively, how we give people the freedom to work in ways that are best for them, and how we quickly respond to changes and new problems.

Learning, and integrating learning into the organisation

Our team (in fact, I think, everyone who works for any modern knowledge work organisation) has two jobs; learn, and integrate that learning into the organisation. This should be the goal for all modern knowledge workers who are creating new knowledge. If that knowledge stays in the head of one person it can’t be utilised effectively by the organisation. So having effective ways of sharing information is an essential aspect of async working.

Meetings are not that. They aren’t effective ways of sharing information. They are left over from a time before the internet when organisations didn’t have any other means of telling people stuff. Meetings and calls have their place, but they serve a social purpose rather than an information sharing one. They can help people feel connected, help with team cohesion, etc., so I’m not saying we need to never have meetings, but we need to clear on what purpose they serve. Meetings aren’t even great for discussion because they favour quick thinkers and don’t allow for equal input from slower reflective thinkers. And in any discussion it’s usually the loudest most persuasive voice that wins.

Writing and drawing instead of always talking and listening are under-utilised asynchronous tools for thinking and communicating. More asynchronous working gives us more opportunities for everyone to contribute and learn. It gives us time to be considered and reflective, deliberate and thoughtful. It prioritises depth of thinking and writing over the speed of thinking and talking.

Communicating, and pulling information when it works for you

Async communication work best when everyone gets to contribute at a time that works for them along with all the other work they’re doing, has time to develop their thoughts on the subject, and learn from what others think. Compare this to joining a video call with no agenda or preparation, and being expected to think effectively and make good decisions. It’s no wonder that so many meetings end with an action to arrange another meeting.

We still have way too meetings, but most of our discussions take place in Word documents. The body of the document contains what we’re talking about, and the discussion takes place in comments, and once something is agreed it’s written into the document. When someone sends an email the information in it is limited to those the email was sent to. That’s what email is good for; passing a fixed piece of information that doesn’t really require any discussion to a fixed group of people. But if we want people to contribute, to build on the information and improve it, and to learn as they do it, then putting the same information in a shared document and working on it together gives us better quality decisions and longer-lasting information which is available to anyone and for as far into the future as needed, which is hardly ever the case with meetings, calls and emails.

The challenge with communication is to create ‘pull’ systems where the information is available when someone needs it, and not ‘push’ systems which send information to people when they’re working on something else and so causing distraction and information-overload. All those products which send a notification email every time an update is made, or show how many chat messages you haven’t viewed yet are bad for really effective asynchronous working because they push themselves to you and demand your attention now regardless or whether you’re in the flow with something else.

Even though we write lots of documents, I’m always keen to guard against assuming that they have all the information in them. So I’m big on encouraging questions. When someone asks a question they are coming from a particular context which affects the answer they need and means the right information might not be in the document. When I reply to question, even if the answer could have been a single sentence, I’ll often try to explain about the background, why the decision was made, what implications or unknowns we’re aware of, all because keeping that information in my head doesn’t help anyone else learn. I’m sure some people find that really annoying and just want the short answer but we all have to make sacrifices for the goal of learning.

Working together, in small lightweight temporary teams within teams

Asynchronous working allows for different ways for teams to organise themselves and their work. We want to be synchronised around outcomes; what we want to achieve and when, but we want to try to remove as many dependencies as we can so that we’re able to respond to change without any drastic impact on the project.The 20-person strong team I’m part of is a cross-functional team, which means it’s made up of people with different skill sets, and is focused the one big project we’re working on. But sometimes something new comes up. A new problem to solve, something we didn’t know about before. It might be considered part of the project we’re working on, or it might not. We don’t want to distract everyone on the team, so we get together a small lightweight temporary project teams made up of people from within the larger team and outside of it to focus on solving the new problem.

One of those times was when we wanted to make it easier for young people using Microsoft Teams to ask for help. So we set up one of these lightweight temporary teams made up of someone from our safeguarding team, a designer, a developer and me. We started a Word doc, all added to it to get to a good enough understanding of the problem to solve, what constraints we faced, and what solutions could look like. We settled on the solution being an app that would live in Teams and have its own button in the Teams menu so that if someone had any questions they could click that button and the app would open and provide them with ways of getting help. So, even though our colleague from the safeguarding team had never worked this way before the rest of us were familiar enough to help her contribute effectively and we were able to design a solution within about 48 hours of picking up the work, and alongside other work we were doing. If we weren’t working asynchronously it have taken us longer than that to find time when everyone was available to have meeting to talk about the work before even doing any work.

Amy Edmondson, professor at Harvard, calls this way of working ‘Teaming’. She describes it as “teamwork on the fly. It involves coordinating and collaborating without the benefit of stable team structures,” It’s a skill that enables groups of people who aren’t part of a formal team and don’t have a history of working together to work effectively together for a short period of time. I think the asynchronous mindset of not having to be doing the same thing at the same time as someone else helps with adopting this way of working because it has a low overhead for organising people. All it takes is a document and writing clearly what we’re thinking about to get started.

Asynchronous teaming also has an interesting side-effect. The people who work in those teams, they spread knowledge from one temporary team to another, which helps to increase learning for everyone. It creates a network of knowledge transfer. It uses Stanford professor Mark Granovetter’s idea about the strength of weak ties. Where we talk about how not being in offices means we miss out of those informal coffee-break chats, creating a these network where everyone talks to people that they wouldn’t have if they only worked within formalised team boundaries means people, maybe it can help.

Asynchronous working at its best leads to a learning culture where two things are true: One, people know stuff that is beneficial for them to know, that isn’t necessarily part of their formal job title, and they don’t know how they came to know it. And two, learning and knowledge sharing are regarded as an implicitly beneficial activity as much as the producing of outputs of work. We’re still working on achieving both of those, but if you’re interested in trying asynchronous working I’d say the three things to try out are:

  • Make writing and drawing the default ways to communicate before meetings (not as well as).
  • Focus on sharing knowledge and learning rather than coordinating people and work.
  • Pick a small problem and get a group of people who wouldn’t normally work together to solve it.

Resources

Weeknotes #243

This week I did:

Roadmapping

I’ve been working on a developing a process for coordinating a product roadmap and delivery plan with the operations of the teams running the training courses for young people. I haven’t quite got the strategy figured out yet but as it shapes up the biggest challenge is going to continue to be how change and adapt quickly to deliver a good enough product just in time for the course delivery.

We discussed the difference between an operating model which explains how things usually work and a support model that explains how to respond when things go wrong, so now we just need to build out those models and make them work in practice.

Why did the chicken cross the road?

I started collaborating with an old friend on writing a children’s book to answer the question, Why did the chicken cross the road? I hand-coded the website in a couple of hours (it loads in 68ms and gets 99 performance grade) and want to use it to try out ideas around ways of writing a book iteratively. The plan is to not have a plan, but to explore and figure where the project goes at each step. At the moment it’s meant to be a read-along story with an adult reading to the child and the child pressing the buttons (which is why the website needs to fast, to avoid frustration), but it might evolve into a story for older children, or into a game, or something we haven’t even imagined yet.

Digital creativity exam

I did my Digital Creativity exam, which finishes the module and means I only have one module and my dissertation left. I really enjoy studying, even though it takes lots of time I get a lot out of the pressure it applies.

Prototyping

This week’s Service Design course was about prototyping. We talked about rapid prototyping of digital services which involves building only enough to test your idea, and then going right back to make an improved version once you’ve gotten the feedback you need. Quite timely, I think, as it’s pretty much the approach we’re taking with Why Did The Chicken Cross The Road.

Upgraded my office

I bought a wireless keyboard which means I can have my laptop monitor up at eye height rather than looking down and getting neck and back ache. If I was still writing about being a Digital Nomad I think I’d use this to talk about how people adapt their surroundings to fit their needs and what that means when your immediate environment is more limiting and changes regularly.


I read:

Human-Centered Design Considered Harmful

Donald Norma from NN Group writes about how Human-Centred Design can be harmful when it causes designers to create for a single idealised user and so excluded others. I’ve been thinking (a little) about how the approach of designing for the extreme user and so including everyone else might work in practice. And when I say design I don’t mean ‘what a web page looks like’ (although that is part of it also), I mean how we design systems and structures and organisations to work for everyone.

Computers and Creativity

This wonderful essay by Molly Mielke, a product designer at Notion, asks the question, “How can we push digital creative tools to their full potential as co-creators, thus harnessing the full power of creative thought and computational actualization to enable human innovation?” This idea is interesting to me as I’ve been studying digital media and how it affects creativity.

Welcome to the Experience Economy

The experience economy is where commercial activities move to beyond commodities, products and services. Pine says that the difference between service and experience is how the customer regards their time. When they are accessing a service they want it to be convenient so they spend as little on it as possible. But when they engage in experiences the customer wants to make the most of their time, and will pay more for it. I wonder if the same thinking could be applied to how charities approach how services are delivered?

Speed as a habit

I believe in speed. For the advantage it offers in almost all situations, and for the tendency towards taking action and getting fast feedback that it brings. In this article is Dave Girouard talks about how, “All else being equal, the fastest company in any market will win“. Speed of decision-making is the main topic the article covers, including some of those anxieties we tell ourselves exist as reasons not to make decisions, things like dependencies, perfect knowledge, and understanding impact, all things that apply if the default decision is to not make a different decision anyhow, we just choose to ignore it.

Abandoned

I’m fascinated by places like this old canal. Places that are from a previous time, abandoned by people and gradually taken over by nature. They remind me of how temporary we and all our works are, and that nature carries on regardless.

210325

What went well?

Did some thinking about our goals for the next and future phases of work.

More revision.

Pretty much the same as yesterday

What didn’t go so well?

Didn’t get out for a walk, and revision is going more slowly than I’d like.

What could I do differently in the future?

Not have so many things to do.

210324

What went well?

Did some thinking about our goals for the next and future phases of work, and worked on understanding identity verification (it’s pretty complicated).

More revision.

What didn’t go so well?

Didn’t get out for a walk, and revision is going more slowly than I’d like.

What could I do differently in the future?

210323

What went well?

Worked on setting things up for effective planning and roadmapping in the near future.

More revision.

What didn’t go so well?

Didn’t get out for a walk.

What could I do differently in the future?

Nothing much.

210322

What went well?

Lots of focused time at work.

Got some revision done.

What didn’t go so well?

Nothing in particular

What could I do differently in the future?

Not much.

210321

What went well?

Mostly revision all day.

But I went for a walk and got a stiles.style to over 200 stiles.

And I did another Recently Read Twitter thread.

What didn’t go so well?

Would have liked to have got more revision done, but I did quite a lot of reading.

What could I do differently in the future?

Not much