#48: How to design remote work
It's literally trivial.
I’m Vaughn Tan; this is another of my weekly attempts to make sense of the state of not-knowing. The first issue explains what the newsletter is about; you can see all the issues here.
My first book, The Uncertainty Mindset is a behind-the-scenes look at cutting-edge high-end cuisine … and what it can teach us about designing organizations to be more adaptable and innovative. You can get it here. If you like it, help me out by leaving a review somewhere. Book events are coming soon—tell me what you’d like to see and sign up for notifications here.
Hello again, patient reader:
tl;dr: Why aren’t more businesses intentionally designing remote work so that it builds effective, tight-knit, innovative, adaptable teams when it is frankly and literally trivial to do so?
In coronatime, like toothpaste being squeezed about in a sealed tube, my online interactions have grown in number and deepened even as offline meetings and interactions have become inconvenient, difficult, or impossible. This is a meta-observation, as this week’s issue about building effective and innovative remote teams is brought to you by an online interaction (on WhatsApp) with James Cham, whom I wouldn’t have met had the pandemic not occurred.
Prompted by a Twitter thread, he messaged to ask if and how the unconventional methods of organizing innovation teams I describe in my book, The Uncertainty Mindset, apply to remote work.
Before I get into that, a quick recapitulation. The book argues that teams become closer, more adaptable, and more effective when
Employee roles are left explicitly open-ended instead of fully and clearly defined—what I call open-ended roles. These roles are, unlike normal static job descriptions, inherently malleable and squishy. They’re designed to change over time if the demands on the team change, and to be changed if the employee’s skills and inclinations evolve. Businesses facing uncertain demands or business environments need more employees with open-ended roles.
Employees are continually put in situations where they can adjust their roles through low-stakes microtests—what I call negotiated joining. These low-stakes microtests look just like everyday work … because that’s what they are. Showing that you can make a correct sauce Hollandaise is a microtest, as is drafting a contract that gets both parties to agreement quickly. Any work that results in work product that can be evaluated by other team members can be a microtest if everyone in the team treats it as such.
Combining malleability with numerous opportunities to reshape each role makes team roles change and adapt over time to fit the team’s changing needs and what each member wants to do and can show s/he is good at.
Microtests are sort of a proof of work in the context of defining and changing roles within a team. No one’s role is assigned purely as a matter of assertion or because they went to a fancy school. Instead they win that role by investing effort and demonstrating capability, showing everyone else on the team that they can do it when they pass a microtest. This sounds brutal, very red in tooth and claw, but each test is usually so trivial that overall the testing doesn’t feel like a big deal.
In practice (and I’ve seen this in numerous settings including R&D kitchens, software development teams, workshop teams, and startups) microtesting done well and frequently is actually so low-level that it becomes ambient. It fades into the background. As this happens, the interpersonal ties between team members become denser and stronger because everyone is continually testing and observing evidence of everyone else’s capabilities and inclinations in a non-hostile way.
Another advantage is that role changes no longer need to be carefully communicated to the team because they aren’t chunky and major. Instead, role change happens continually and in small, low-stakes ways, and team members participate in the process of changing roles. Changing roles is no longer about the big, showy strategic reorganization announcement; instead it is woven into the fabric of everyday team work life.
For these reasons, teams organized like this have constellations of roles which can (and do) flex quickly to adapt to changing needs and the teams become close-knit and highly effective at doing what they need to do. This is what businesses and governments need in coronatime.
James’s question in a nutshell: Can this quite counterintuitive approach to organizing teams work when team members are all working from home in their pajamas, seeing each other only on Zoom? In my view, the answer is largely YES if we’re talking about teams of thoughtworkers.
Thoughtwork is massively advantaged (relatively) in our crash transition to remote work because its work product can be more easily and completely evaluated remotely. This is relevant here because, practically, this approach to organizing teams depends on two design characteristics of work:
Making as much work as possible something which all team members treat as a way to demonstrate and assess interest and ability. This especially applies to what appears to be trivial work, so that microtesting becomes so much a part of everyday work life that people stop focusing on it. Leaders and managers can do this by setting expectations explicitly up front, and by
Making evaluation of work product central to as much of team work life as possible, by having team members look at, comment on, and evaluate each others’ work product. Again, this especially includes seemingly trivial work product. Leaders and managers can do this by making evaluations of work product routine, easy, and low-stakes—anything from the manager asking (perhaps on email or in Slack) for comments on his/her work, to setting up periodic scheduled group video calls during which anyone can present work-in-progress for comments. The goal is to normalize asking for and getting frequent, low-level feedback.
Where the work product is a plate of food or a clay model of a new car part, being remote is an obstacle—often insurmountable—to having the rest of the team evaluate the work product. But where the work product doesn’t have to be a physical object—a slide deck, a piece of writing, an idea for structuring a deal—remote work poses almost no obstacle to connecting an individual’s work with the work product, and making the work product available for other team members to evaluate. The two design characteristics I highlighted above are therefore relatively easy to implement in remote thoughtwork.
The maybe unintuitive insight here is that this stuff happens more often the more trivial, apparently pointless interactions there are between team members.
I’m part of building a new team at the moment. One concretely useful thing I’ve found early in learning how to work together remotely is the value of tolerating (and even encouraging) long, apparently inefficient Zoom calls where everyone sort of crawls over an agenda slightly distracted by other work but periodically engaging with each other.
Apparently inefficient work like this is something teams and leaders have to accept, especially early in their time working together remotely. It appears inefficient because the ostensive purpose (i.e., whatever is on the agenda) seems to take a long time relative to how much gets done—but is effective because the actually important purpose (team development through microtesting and role-negotiation) is happening in the background. This repeats a motif in these newsletters that building capacity usually requires accepting what appears to be massive inefficiency (see, for instance #8 and #23).
For thoughtworkers and the organizations that employ them, there are enormous advantages to going remote by default and working in-person only opportunistically. But I should be clear that I don’t mean that in-person work has suddenly become useless for thoughtwork. What I’m trying to say is that working face-to-face isn’t necessary for building effective, adaptable, and innovative thoughtwork teams as long as
Roles are intentionally and explicitly left open-ended and malleable instead static and fully defined.
Remote work is intentionally designed to include replacements for trivial interactions common in in-person work—even if this seems apparently inefficient.
Remote work and trivial interactions are intentionally designed to be opportunities for role-negotiation through microtesting and evaluation of microtests.
So … why aren’t more businesses intentionally designing remote work to build effective, tight-knit, innovative, adaptable teams?
🤔
In the land of this wonderful dream. (As you can see from the pictures above, I’m currently in a dreamy landscape characterized by coniferous forests and eroded volcanoes.)
(Upcoming) bonuses:
On October 6, I’ll give a webinar about how the hospitality industry can become more resilient to what seems to be an inevitable avalanche of uncertainty in the months ahead.
On October 22, I’ll be giving a talk about The Uncertainty Mindset and about how to prepare for uncertainty and respond to it with grace and innovation. You can find the IO Summit schedule and get a free ticket here.
Photos from the field: Until Issue #52, each week I’ll post a few photos of everyday work in culinary R&D teams selected from the thousands I took during fieldwork for the book.
Figuring out how to grow stuff at Amaja (2011).
A late night pre-launch ThinkFoodTank all-hands in Las Vegas (2010).
A prototype of dubious quality at The Cooking Lab (2012).
By the way: This newsletter is hard to categorize and probably not for everyone—but if you know weirdos and unconventional thinkers who might enjoy it, please share it with them.
Find me on the web at www.vaughntan.org, on Twitter @vaughn_tan, on Instagram @vaughn.tan, or by email at <uncertaintymindset@vaughntan.org>. You can also find out more about my book at www.uncertaintymindset.org.