The “whiteboard effect” refers to a deep work phenomenon that occurs when two or more people problem solve together in spells of intense focus. The presence of this effect doesn’t mean, however, that we must always be in whiteboard mode.

The async-first manifesto is a work-in-progress. This post explains the five values of the first draft. This should help everyone who wishes to help shape the draft, understand the initial thought process.

Advocates of in-person work often say they need to get their teams together for brainstorming sessions. This is a waste of time. The effectiveness of brainstorming is a corporate myth.

Well intentioned, busy people want to be collaborative. But they often end up as bottlenecks. I argue that busy people must change their model of collaboration.

We continue exploring the seven deadly sins of knowledge management in this week’s post. I explained three of them to you last week. Here are four more.

In a massively distributed world of work, effective knowledge management is a superpower for your people. On this site, we’re already discussed many things you must do, to foster knowledge sharing. This post is the first, in a two part series about things you shouldn’t do.

If decisions are the fuel for high-performing teams, a permissions culture is its kryptonite. In this post I discuss three areas you must focus on, so your team can maintain a high decision velocity.

With the right systems and the right people in community management and curation roles, you can brew the perfect storm of “organised serendipity”. I daresay, that this can often work better than the proverbial water cooler meeting.

In this post, we’ll discuss how you can enhance your knowledge ecosystem by building on your existing collaboration stack. I’ll also go over how to create the right team of people to govern, curate and nurture that platform.

The approach of creating stocks of well structured, organisational knowledge has its limitations. In this post, I argue that you should invest in solutions that create flows and streams of knowledge while stocks move to a supporting act.

Remote work would have renewed your organisation’s interest in knowledge management. Considering one can’t walk up to co-workers for a quick clarification, could we instead ask the system for an answer? In an asynchronous, remote-first culture, a solid knowledge strategy can be a productivity power up.

In this article and a few subsequent ones, I want to share my thoughts about creating a knowledge ecosystem that keeps pace with your people’s know-how.

As team size increases, communication becomes more complex. Small teams will eventually bring in new people. Such is life. Team size aside, you’ll find that complex decisions lend themselves better to the written word. Moreover, there are limits to what people can remember, so it makes sense to commit things to writing. If we’re designing continuously, we’re also communicating about it all the time. In today’s post, I want to share three asynchronous techniques to communicate about design.

Sometimes we give a free pass to any activity that seems collaborative. Before you know it, you’ve built half a dozen gate checks to deliver a single user story. Each of those “collaborative” gate-checks doesn’t just create interruptions and context switches. It also leaves an attention residue - your mind continues to think about the interruption even when you’ve switched to the task on hand. In this article we examine the ad-hoc “huddle” through a series of questions, so we can find out how much we really need them.

Like the pebble trail in the story of Hansel and Gretel, our projects need audit trails for us to keep track of changes, communicate on a daily basis, and to onboard and align people. We discuss the five most important trails in this article. In the context of distributed teams these represent communication and documentation in the flow of work.

To me, async agile is non-binary. The value of being more async is also in making the truly valuable synchronous activities more productive and fun. Pair programming is amongst the most frequent synchronous activities that agile teams, especially those that follow extreme programming (XP), practice. How do we weave this into a remote-native way of work?

Chat is an essential part of your toolset. The trouble is in the “instant” of “instant messaging”. To be “instant”, you need to monitor chat all day. Not only does that build interruptions into your way of working, it can be mentally exhausting to keep up with all the channels your team and company have created. So in today’s post I want to share a few ways you and your team can use this set of communication tools effectively and support a more productive, async-first way of working.

In today’s post, we’ll dive into the agile sprint - a time-box of approximately two weeks, when development teams work on a set of user stories they’ve prioritised to deliver. We’ll examine two synchronous collaboration practices - story kick-offs and dev-box tests or desk checks and how we can adapt them to a remote-native; async-first way of working.

Let’s look at the categories of collaborative tools most software development teams will need. Many of these will seem familiar to you already, and that’s a good thing. You just need to use the tools effectively. I’ve broken down the list into three categories - must haves, good to haves and optional extras.