Sumeet Gayathri Moghe on async-first and knowledge management

Sumeet Gayathri Moghe is an agile enthusiast, a product manager, and a design nerd at Thoughtworks. Over the past few decades, he has worked with various clients, developing software products and helping them improve their engineering effectiveness. When he's not developing software in front of the screen, he's often behind the camera, photographing wildlife or a nature scene.

A few months ago, I came across Sumeet's work: his blog, his book The Async-First Playbook, the async-first manifesto, his stories of "Humans of remote work", etc.

I realised I wanted to help spread his work: because of the relevance of the topics, because of the clear way he communicates his experiences and recommendations, and because of the generosity and passion with which he does it.

After confirming his participation as a speaker at Social Now 2024: Realising the value of your digital workplace, it is my pleasure to share a fantastic interview he granted me: an interview about asynchronous work, knowledge management, and digital collaboration support platforms.

Before, a short note on what is asynchronous work, namely Sumeet's async-first approach to work.

In a simplistic way, async-first is a way of working which looks at meetings as the last resort to communicate and collaborate, privileging written channels and embracing "slow" reactions and responses.

???? Esta entrevista está disponível em português no portal KMOL.

Why do we not see more widespread practices of asynchronous work in organisations? Is it resistance, fear or are they simply unsure of how to do it?

To me, the reason is a bit deeper than either of those. It’s never enough to simply say, “Let’s do away with meetings”. This is a change in ways of working, and that change must happen at the team level. Teams must commit to certain disciplines and processes. For that, the team must first see value in shifting from their existing working methods. That’ll drive the team’s intrinsic motivation for the shift.

Second, any change in ways of working will have some impact on productivity. After all, people will have to practise some new skills (reading, writing, distraction blocking for deep work) consciously. The business must be ready to absorb this temporary dip in productivity.

And finally, every team has an existing set of processes, practices and rituals. Leaders must be ready to dive into the details of each practice and think about what the asynchronous alternative can be. Without this detail orientation, it’s hard to adopt asynchronous collaboration productively.

The challenge I see is that team buy-in, business buy-in and practice alignment don’t happen in sync with each other (pun intended). And that’s why we don’t see widespread adoption of async-first collaboration. Or at best, we see poor implementation of this collaboration paradigm.

Which two arguments would you use to defend asynchronous work to a board member?

To be honest, I’ve rarely had to defend asynchronous collaboration with board members or executives of tech companies. Pretty much all of them know that creative people shouldn’t default to meetings as the first option.

That said, few leaders are willing to invest in this shift, even if they admit it’s important. At a bare minimum, it means changing the way they communicate, and how their teams collaborate. And this isn’t a trivial change at a time which is admittedly hard for tech companies.

There are courageous leaders, however, who see this as an important investment to come out winners at the end of the recessionary period. And two arguments resonate with them.

The average tech employee spends 80-90 days in meetings each year. These same employees report that two-thirds of these meetings are a waste of time. Imagine how much more productive their workforce could be, if they could get rid of those wasteful meetings.

Tech is a people business at its core. And tech talent is scarce. When the war for talent heats up again, which it inevitably will, companies that can hire from anywhere, and that allow their workers flexible work hours, will attract more of the top talent.

Would you use the same for a team manager??

Yes, but also there are different considerations for a manager. I’d ask them to think about whether they’re building an inclusive team, where all kinds of talented people can contribute, regardless of their neurodivergence, race, gender, fluency with English or experience. Slowing down, to communicate asynchronously, allows all these people to bring their perspectives to the team.?

The other thing managers care about is building high-performing teams. Asynchronous work, being writing-driven as it is, helps the team build up its shared knowledge. That in turn gives you the foundation to bring new people onto your team or minimise the impact when someone leaves your team. When you make knowledge explicit, you make better decisions. Decentralising decision-making is a key principle of asynchronous collaboration. As a manager, if you create an environment for people to be more decisive, those decisions will inevitably lead to more progress on the team’s goals.?

And let’s not ignore the kick that everyone gets out of deep work - the kind of work that asynchronous collaboration frees us up to do. People have a stronger sense of accomplishment and satisfaction when they work this way. But let’s not ignore that managers, too, benefit from being able to work this way.?

What would you recommend a team member to do if she is keen to promote asynchronous work practices in her team (having to convince the team manager in the process)? In other words, what are the logical steps to push asynchronous work practises bottom-up?

Don’t do this alone!

The first step is to enlist the support of your teammates because any way of working is effective when everyone buys in. If your colleagues see value in this way of working, you can convince your manager to get you some breathing room from the business. Meanwhile, you must start looking at each of your synchronous practices and rituals and find the ones that are most suitable to replace with an asynchronous alternative.

In one of your posts, you write “Get everyone to contribute to one system without restriction”. How do you reconcile this with the need to cater to different types of work, different team preferences when it comes to collaboration and communication, and the fact that there aren’t many digital tools which respond well to all use cases?

There’s a practicality we must acknowledge. Your company can’t subscribe to every tool there is on the planet. And there’ll always be a better tool out there, not just for your workstyle and preferences, but also for certain use cases. It’s a battle the average team cannot fight, especially in a large company. So at least in the short term, it’s best to work with the ubiquitous tools that your company provides.

The good news is that the pandemic-induced remote work revolution forced many companies to invest in a decent toolset. And frankly, you don’t need fancy tools to work effectively in distributed teams. The standard team tools are fairly mature - collaborative documentation, whiteboards, instant messaging, code repositories, task boards, and conferencing. I argue that many teams don’t max out their team tools even today. So at the team level, I’d start by squeezing every last bit of functionality from the tools your company already provides.?

Company-level tools are a bit more tricky. You see, at the team level, you can’t opt out of using a certain tool. It’s almost mandatory for your work. But tools at the company level - e.g. knowledge management platforms - are optional. This is where people who pick the tool stack for company-wide knowledge sharing and community building, must pay attention to user experience. You won’t satisfy everyone, but the standard activities - contribution, connecting with others, search, curation, question and answer - must meet a high bar of usability.

What tools comprise your toolkit for collaborating with your distributed team?

As a consultant, I swap teams more often than most people, but on the software development teams I work in, here are the most common tools.

1. Confluence, for organising team knowledge?
2. Workspace by Google for collaborative documents and email
3. Slack for instant messaging
4. Jira as the team’s task board/ work management tool
5. Mural as the collaborative whiteboard
6. Zoom as the conferencing tool
7. GitHub as the code repository

That, of course, is the basic stack. On certain teams, we swap out certain tools for other alternatives. E.g. we may swap out Confluence for Notion, Almanac or Google Sites. On a team that doesn’t build software, we may use Trello instead of Jira. A Microsoft shop may use a combination of Sharepoint, Office 365 and Teams. Mural may give way to Miro or Apple Freeform. So I have to adapt to the digital landscape of my clients.?

Is there a bit of functionality that you miss in any of them?

Of course, some tools are better than others at a few things. But at the fundamental level, most team collaboration tools are fairly similar to each other. In my job, there’s no point fretting over what my favourite tool is. Ubiquity beats sophistication. Tools that everyone has access to and those that everyone understands, are always more powerful than the latest, shiniest new toy out there.

I believe that asynchronous work practices are a great contributor towards knowledge management (KM). Do you agree?

Of course. The fundamental practice behind asynchronous collaboration is writing. You have to work in an artefact-driven manner. This means that you’re creating knowledge in the flow of work. So yes, teams that practise asynchronous collaboration, create the foundational behaviours for better knowledge sharing.

Having said this, I see many teams miss the important act of curation. It’s not enough to simply generate lots of artefacts and documents. People must keep pruning and organising these artefacts, the most important information is searchable and navigable. In other words, the speed of knowledge retrieval is just as important as the ease and efficiency of knowledge creation.

Which of the many benefits of adopting asynchronous practices are more in line with KM goals?

When I speak to practitioners, I advocate for asynchronous collaboration as a “create once, share many times” way of working. The idea is that once you’ve created an effective artefact, you can remove yourself from the process of sharing the content of the artefact. You amplify your impact as an individual contributor for your team or company. And isn’t that also the goal of knowledge management?

"When you make knowledge explicit, you make better decisions."

Imagine this scenario. An organisation is struggling to tap into its pool of knowledge. They have many documents, spread across multiple systems, in various formats, and multiple versions of the same documents, some of them outdated. What would be your recommendation to this organisation: invest in KM or AI??

This is “literally” a million-dollar question because you can spend millions of dollars to solve this problem the wrong way and your company will be none the wiser. There’s a false belief many of us have arrived at, that AI will somehow make sense of our unstructured company artefacts. I fear that without the right preparation, introducing AI tools will lead to a “garbage in, garbage out” knowledge solution.?

Companies who want to leverage AI for knowledge retrieval should first spend some time curating their existing artefacts. In large organisations, this can happen at three levels.

1. Teams - they are responsible for their team handbooks which curate everything an individual must know to be a productive team member.
2. Communities of practice are groups of people with similar interests across the company. They must organise the most relevant and current information that relates to their practice or expertise.?
3. Corporate - this information doesn’t change often but needs regular upkeep all the same. Imagine things like the organisation structure, policies, values, company financials and press releases.?

When we decentralise curation at these three levels, we create a knowledge infrastructure that’s conducive to AI-led innovation. As large language models and tooling mature, I’m confident that we’ll see many opportunities to supercharge knowledge creation, retrieval and sharing soon.

How would you finish this sentence: “Asynchronous work practices are more likely to succeed in organisations that …”

… recognise that most knowledge working teams will be distributed by default and they embrace distributed work as a way to scale their business.

Without being stereotypical but recognising that there are significant cultural differences, do you think that Western cultures are more or less open to asynchronous work? Why?

It’s hard for me to comment on this, but I don’t think any culture is more or less open to certain ways of working. There’s a term called “collaborative pacing” that Douglas Rushkoff defined in his book - “Present Shock: When Everything Happens Now”. The idea is that “groups of humans may converge toward strict patterns of behaviour without ever explicitly deciding that the new behaviours make sense.” One person behaves a certain way, another follows and before you know it, a pattern appears.

Western or Eastern, people get used to certain ways of working. Some of these ways of working can be ideology-driven. For example, in the agile community, some people still believe that “face-to-face communication is the most efficient and effective method to convey information in a team”. If you’ve become overtly religious about such ideologies (and there are plenty of them), disbelieving can be hard work. So people choose to stick with the ideology and ignore its flaws.

If people have worked a certain way for many years, any new way of working will force them out of their comfort zone. If the promise of the new way of working is not significantly more alluring than the current way of working, many people will resist change. This is why team buy-in is so crucial to any improvement in changing ways of working.

Let’s also not forget that no one wants to shoulder the blame if a new way of working leads to a drop in productivity. Even if that dip is temporary. Regardless of geography and culture, if there isn’t safety to experiment, most people will stick with the status quo. Asynchronous work offers many benefits, but many of them are too far into the future. People value their immediate safety more than the benefits they may accrue later.?

I’d like to think that given the right level of psychological safety, many knowledge-working teams are frustrated enough with “Zoom fatigue” and the constant hustle that comes with it, that they’ll choose asynchronous collaboration. I’d love to see if this openness varies by age, culture or geography.