First draft of the async-first manifesto explained
Summary
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.
A few days back I took a crack at writing a manifesto for async-first collaboration. By now, many people have seen the document. Several people have shared feedback and admittedly the draft needs a few more iterations before we all feel comfortable with it. It’s no secret that the agile manifesto inspires this document. I’d like the async-first manifesto to complement the agile manifesto. The difference between the two manifestos is that the async-first manifesto (AFM) assumes that most teams will be distributed. Remote work is no longer an edge case.
In this post, I want to describe my thoughts when I wrote up the first draft of value statements for this new manifesto. But before I dive into the details, I’ll take the liberty to explain some design characteristics I hope the AFM can adhere to, when we finalise its contents.
Aspirational attributes for the manifesto
Short: The beauty of the agile manifesto is how economical it is, with words. That economy translates into a memorable document that most people can recite, off the top of their head. The more memorable a set of values, the more likely it is that you can live by them and evangelise them. So I’d like the AFM to have 5 value statements or less.
Durable: The agile manifesto is relevant even today - over two decades since the authors published it. That’s a testament to its durability. The AFM should be equally durable. The values we espouse in this document should ideally outlive our work careers.
Extensible: The authors of the agile manifesto wrote the document for software development in particular. Yet it inspires many other fields of work. If you set aside the principles of the manifesto, you’ll notice that the values are extensible - since they’re not prescriptive. This extensibility allows us to upgrade the “state-of-the art” with time. While the AFM shouldn’t be everything to everyone, I hope it can inform all kinds of knowledge work. Values should encourage people to think, instead of providing a prescription.
The rest of this post is an invitation to collaborate on crafting the AFM. However, I hope we keep the above design characteristics in mind as we work together. With this said, let me explain the current draft in a bit more detail. Fair warning, this post may be invalid in a future iteration of the manifesto. Also, if I write enough of these posts, a future reader may generate an archaeology of the thought process that went into the document. Okie dokie. Let’s dive in.
How we work over where we work
Before the pandemic, many individuals, teams and companies believed they could not do their work remotely. We’ve learned by now that most knowledge work jobs can happen from anywhere. The benefits are immense — inclusion, access to talent, work-life balance, business continuity, resilience — you name it. But in recent months we’ve seen a tussle between executives and employees, where executives advocate for a return to office (RTO), while employees prefer to work remotely.
The executives argue that many company activities, such as building cohesion, sharing knowledge, coaching and mentoring are hard to do when employees are remote. Many employees and remote work veterans argue that this belies a lack of maturity with distributed work practices and systems. Most people, however, agree that the era of five days in the office is behind us. So regardless of our work arrangements, someone will always be “remote”, in relation to us - be it an immediate team member, a colleague in another department or a client or customer or stakeholder. Indeed, this “relative remoteness” means that regardless of one’s work location, one must be proficient with remote-working skills.
Considering the above observations, it makes sense to focus more on how we work, than where we work. This website has enough content about why a highly interrupted, meeting-centric way of working is detrimental to knowledge work. So I won’t flog a dead horse here. The bottom line is that our work practices should be transferable across many location strategies.
Predictable rigour over occasional heroics
This statement is the one I’m most unsure about. Indeed, this is also a statement that some collaborators have suggested changes to. Here’s what I thought when I first wrote the line.
On successful teams, there’s more than meets the eye
The agile manifesto states we value “Individuals and interactions over processes and tools”. It’s a laudable and tricky statement in equal measure. Consider a sports team for example. Much like software, the situations a sports team faces at run-time are unpredictable. Indeed, the teams that consistently win, seem like their players are in a magical symphony with each other. On some days, you’ll have a standout player who single-handedly wins their team a match. Of course, individuals and interactions matter. But this is only the tip of the iceberg. Every modern sports leader will tell you that their process drives their results. Great sports teams follow a process - day in and day out. They pride themselves on doing boring, predictable things well.
MS Dhoni
“The process is more important than the results. And if you take care of the process, you will get the results.”
But why go as far as a sport? How about looking at remote work OGs? GitLab swears by its value of “efficiency” and they say “Boring is efficient”. Similarly, DHH of 37signals talks about managing the process - they have a predictable rigour through their Shape Up framework. In DHH’s words, “processes help dramatically reduce the amount of managerial supervision needed”.
On distributed teams, predictable rigour brings a sense of calm. Trust the process and the results will come -more often than not. It reduces the thrashing that teams may experience when solving problems. You can avoid what Cal Newport calls the hyperactive hivemind. You may still need the occasional heroics, but you don’t rely on them.
Intentional actions over accidental success
The right-hand side of this value statement needs work. It makes the left-hand side visibly more desirable, and that doesn’t make for a great manifesto statement. With that acknowledgement in mind, let me explain the rationale for the statement.
Leaders who still extol the virtues of in-office work will often use words like “magic”, “secret sauce”, and “x-factor” to describe the experience. They argue that simply the act of being in an office somehow magically fosters innovation, mentoring, coaching, team camaraderie and serendipitous knowledge sharing. It’s almost as if you do nothing else, but get people into a specific location. Luck, chance, accident and serendipity can’t be reliable ways to achieve outcomes. I couldn’t say it more eloquently than Simon Holmes.
“If the water cooler is so important for creativity and solving big problems, why would you leave it to chance based on who is thirsty in the office at the same time?”
Most experienced remote work practitioners and leaders will tell you that you don’t leave things to chance when your team or company is distributed. You must be intentional about how you achieve any business outcome. Even the phenomenon of “serendipity” that we speak about so much in corporate circles, must result from intentional design. If you can’t be bothered to think things through and be intentional about them, maybe those business outcomes aren’t important enough. Coming to that conclusion is an intentional action too!
Note: As I’ve thought more about this statement in the manifesto and revisited the feedback I’ve got, I feel like it may be a restatement of “Predictable rigour over occasional heroics”. Tell me if you think the same.
Focus and flow over always-on availability
Like the first line of the manifesto, this line has almost universal agreement. Practitioners get this. It’s one thing to be the person who responds to every email and every chat message within minutes or even seconds. One can also be the person who jumps onto a meeting with little notice. Who doesn’t love that person? But it’s also almost a guarantee that the same person can’t do deep, cognitively demanding work. Surely not without a cost to their personal lives.
The recent DevEx paper states that a state of flow is crucial to productivity. The paper reiterates what Paul Graham said about makers’ schedules, way back in 2009.
“But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.”
Graham’s perspective is not alone. We must examine it in the light of Anders Ericsson’s work where he stated elite performers engage in 4-5 hours of deliberate practice each day. Deliberate practice is hard. It needs focus.
Add to this the idea of enjoying the work you do. This isn’t deliberate practice, but it’s about being in a “state of flow”, where one is so involved in an activity that nothing else seems to matter. Top performers also spend many hours each day in a state of flow.
If we agree that most people in a development team are makers, then those people need the ability to focus. They also need states of flow. Responsiveness is important, but it can’t be at the cost of flow and deliberate practice. Team practices and expectations from the workplace should recognise this productivity tradeoff.
New possibilities over what worked in the past
Just because something worked in the past, doesn’t mean we can’t do something better today. It’s hard to argue with that perspective on most things work-related. The question is, how does this sentiment relate to asynchronous collaboration?
We’re at an interesting precipice when negotiating what the present and future of work must look like. The “past” of work is one of overwhelming synchronicity. Starting from the industrial age, the idea of organised work is that of getting people into the same place at the same time. While we’ve improved work conditions since, the fundamental premise of location and time dependence has remained unchallenged. Until the pandemic. Or so we think.
The pandemic helped us realise that location-independent work was not just possible, but could be productive too. We soon discovered it was not that simple. Most remote work was a copy of what we did in an office, enabled by tools like Zoom or Slack. To this day, many distributed teams employ the pattern I call “office in the cloud”. We assume that the office “worked” and so should its adaptation on the internet.
For a moment let’s ignore the problems of the office. With a new medium, with new tools, why can’t we imagine new patterns for work? How can we achieve even better outcomes by embracing these new possibilities? Our past successes can give us a benchmark to beat. Once we have that benchmark, we can employ what we learn with every new iteration of collaboration techniques and technology, to set new, even higher benchmarks.
So the idea is to challenge the, “But we’ve always done it this way,” mindset. Not only in 2023. But even a few decades later. We may have to challenge a few holy cows. That’ll take courage!
So that’s the rationale for each line of the current AFM draft. I recognise there are some tensions we must address. For example, as my colleague Satish Viswanathan says, exploring new possibilities may stop us from achieving predictable rigour. How do we accommodate a diversity of work styles, ask Nagarjun Kandukuru and April Johnson. What about transparency and openness? Are the second and third lines saying the same thing in different ways? How can we make this manifesto even more specific to asynchronous collaboration, as Max Ludwig suggested?
We must also take inspiration from the agile manifesto. The items on the right side can’t represent a strawman to beat. They should have value as well. Just not as much as the items on the left.
These are all interesting questions. Thankfully, we have the luxury of time. We can slow down and collect inputs. No rush. But now that you understand what I was thinking, you can use the context to suggest improvements to the manifesto draft. And to make some decisions!