Three work patterns that don't work for remote teams
Summary
Copy-pasting office-centric practices rarely works for remote and distributed teams. Three such practices suck, when you attempt them remotely.
Shadowing and observing. There’s no way to do this consistently and reliably online. Instead, employ FAQs, checklists, onboarding documentation and pairing.
On-demand huddling. Such ad-hoc meetings cause interruptions to flow. Instead delegate decision making to the lowest level by organising teams into short-lived pods that own features or capabilities. Adopt a bias for action. When you must seek wider input, slow things down, instead of preferring knee-jerk reactions.
Wholly synchronous training. Such programs are ineffective regardless of your location strategy. Instead, choose a training approach where you blend synchronous and asynchronous activities. Space out learning events to aid retention and to combat the forgetting curve.
Don’t try to replicate old practices to the new medium of remote work. Instead think about how this new medium can help you achieve your goals more effectively if you were to reimagine your practices.
And, I’m back. As I told you in the last post, there’s a parallel universe in which I’m a wildlife photographer. I spent a couple of weeks in my favourite place in the world - the Maasai Mara. I had the rub of the green going my way during this trip, and my friends and guides, Simon and Alex, were also on top of their game. Amongst the many epic sightings, was one of this leopard dragging its kill right in front of us. It’s an experience I’ll cherish for years to come.
A highlight from my time off
Anyway, that’s as much of a life update as you may tolerate. For those of you who’re curious, I’ll add images to my photography website in due course.
When I came back to work this week, I was delighted to see a couple of updates by remote work researchers Nick Bloom and Brian Elliott. Their data reveals a few findings, albeit limited to the US.
Labour productivity skyrocketed as office occupancy fell in early 2020.
As office occupancy has increased, post-pandemic, companies have struggled to improve on those productivity gains.
That said, as office occupancy has plateaued over the last quarter, productivity is increasing again.
Nick Bloom predicts a Nike Swoosh-like curve, to show how he believes fully remote work will become more prevalent.
While I read all this, I continue to experience dismay as I see well-intentioned leaders grapple with distributed work as a new medium. The common theme I notice is comparing location-independent work, to work patterns we used to deploy in offices. As I’ve noted earlier, trying to force-fit old patterns into a new medium seldom yields meaningful results. It’s like trying to fly an aircraft using the same skills you used when rowing a boat!
In today’s post, I want to share with you three office patterns that I think are ineffective when you work remotely. I’ll also share alternatives to each of these practices, so you can build a remote native workplace.
Shadowing and observing
“Shadowing” used to be a common onboarding practice when teams and companies worked out of offices. The idea is simple. Pair a recruit with an experienced employee and let the newbie observe everything the old hand does at work. The new employee follows the experienced practitioner into every meeting and they observe each task. The new hire is practically the experienced person’s “shadow”. After the shadowing period is over, the new hires can be on their own, having learned from their observations. In theory, they should be able to perform their tasks with little or no supervision. It often helps build trust and connection between the two people in question, so that’s a bonus.
While this practice works reasonably well in person, it usually fails when teams are remote. It’s impossible to follow someone like a shadow unless they’re on a perpetual call with you, narrating their every single move to you. Even when in-person, shadowing can be an inconsistent exercise. It all depends on how invested the person you’re shadowing is in getting you up to speed.
Remote teams are inherently unsuitable for shadowing. With some care and diligence though, you can create a far superior onboarding experience. Here are some alternatives that I suggest.
Document any knowledge that one must pick up during the onboarding process. You can use videos, courseware and brief documents for the purpose and you can host them on a wiki or a learning platform, depending on the content.
Preserve the new hire’s dumb questions budget by creating an FAQ page. That way you’ll answer the most common questions, without making it intimidating for the new hire. They may still have questions, by the way. Some of these questions could be contextual and you can address them one-on-one. But if you hear some questions that you expect other new hires may also have, you can add them to the FAQ. This will enrich the onboarding experience iteratively.
Use pairing as a teaching pattern. Pair programming is a core XP practice. Not only does it help solve complex problems, but it also can be a way to familiarise a new team member with a codebase. This is an effective way to introduce new hires to your coding conventions and other development practices. By following a ping-pong, or ball-and-board pattern, you can invite the new hire to not just observe, but also practise what they’re learning. Pairing isn’t only for developers. It can work for every role; in tech or otherwise. I find pairing as a far more effective way to coach people than having them just observe me.
On-demand huddling
The “huddle” is a common, ad hoc collaboration pattern that knowledge-working teams use to gather around a whiteboard to solve a problem. Let’s say a pair of developers is facing a problem they want others to weigh in on. They shout out to everyone else for help. Before long, the team gets together and brainstorms a solution to the problem. The practice is so popular that Slack has a feature to simulate it.
I’ve always found huddles to be a disruptive practice. Here’s why.
They are interrupting, by nature. Finding solutions to problems is important, but they shouldn’t come at the expense of disrupting other people’s sense of cognitive flow. Flow, as we know, is one of the three pillars of an excellent developer experience.
While the pair of developers who encountered the problem have a deep understanding of it, everyone else has to first understand the problem in a short time, and then match it to their repository of solutions. Everyone can’t handle this cognitive load effectively, so huddles can often lead to knee-jerk solutions rather than well-thought-out solutions.
Frequent huddles can be a symptom of a few inherent dysfunctions.
People in the team may not experience autonomy and safety. The lack of safety leads to a lack of confidence to be decisive. This is when people seek the safety of the team to decide rather than risk their reputations by deciding themselves.
Team knowledge may not be easy to access. If a lot of knowledge is tacit, then the only way to tap into it is by bringing the entire group together into a meeting.
A high quality developer experience benefits from a flow state and low cognitive load
If huddles are disruptive in person, they’re even more disruptive when remote. In a remote team, huddles are another kind of meeting. We have enough meetings and interruptions already. Do we need more? Instead, I suggest reducing the blast radius of decision-making in your team.
Decisions are the fuel for high-performing teams. Differentiate between reversible and irreversible decisions in your team. Accelerate reversible decisions, by encouraging people to first document them using decision records and then execute them without fear. The higher your decision velocity, the more progress your team will make.
Organise your team into small, short-lived, but empowered pods that can make decisions about a capability or a feature. Pods can be 2-4 people strong. Encourage them to default to action. Nominate a first-amongst-equals or a directly responsible individual (DRI) in each pod, who can break the tie when everyone else can’t reach a consensus.
Document your team knowledge - including internal and external APIs, frameworks and patterns - so people can use this knowledge to fuel their decisions. That way a huddle doesn’t remain the only way to “pick people’s brains”.
There will inevitably be situations where you still experience the need for broader input. In such situations, I recommend a more deliberate approach. Slow things down. Write the context of the problem you’re trying to solve. Share it with the people whose input you’re seeking. Give them the time to wrap their heads around this problem and to share their comments asynchronously. Once everyone has digested the background information, you can meet to make the final decision. This is a slower approach than the ad hoc huddle, but the quality of decisions you make will help pay for the speed you give up.
Fully synchronous training
In fully in-person cultures, it’s not uncommon to see training programs where people join with little or no exposure to the topic of training. Be it a lecture, brainstorming, or a hands-on exercise, designers of such training programs plan most learning to happen in the physical classroom.
I’m biased against such programs because they are highly ineffective. They cram in too much learning in a short time. They’re also at odds with the way most people learn and remember things. As the psychologist Hermann Ebbinghaus told us back in the day, we forget things rapidly after we learn them. Heck, we forget 50% of what we learn, within 20 minutes of learning it.
The forgetting curve - our recall of knowledge and skills drops dramatically after a learning event
More importantly, we learn best when we have a deep desire to learn. Training programs where one tries to teach everything possible within the space of a one or two-day workshop put all the onus of facilitating learning on a designer or a trainer. Instead, I suggest sharing this onus with learners.
Effective training programs embrace the spacing phenomenon - introducing learning materials over time, as part of a learning pathway. Even if you conduct an in-person training session, it should be a part of a sequence of learning activities. Many of these learning activities ought to be self-service, so the learners can proceed with them at a pace that suits them. I assure you I’m not spouting some new-age, corporate hippie mumbo-jumbo. In his 2011 TED talk, educational innovator Sal Khan explained why his cousins preferred him on YouTube rather than in person.
“When you think about it from their point of view, it makes a ton of sense. You have this situation where now they can pause and repeat their cousin, without feeling like they're wasting my time. If they have to review something that they should have learned a couple of weeks ago, or maybe a couple of years ago, they don't have to be embarrassed and ask their cousin. They can just watch those videos; if they're bored, they can go ahead. They can watch at their own time and pace. Probably the least-appreciated aspect of this is the notion that the very first time that you're trying to get your brain around a new concept, the very last thing you need is another human being saying, "Do you understand this?" And that's what was happening with the interaction with my cousins before, and now they can just do it in the intimacy of their own room.”
Any training program that follows a fully synchronous pattern, either in a classroom or on Zoom, is doomed to be a waste of time. They also reveal an insecure, paternalistic mindset - one that suspects that people will not take charge of their learning. And if we can’t trust people to learn by themselves, we must take things into our own hands, shouldn’t we? I argue otherwise! If people don’t want to learn, no amount of training theatre will convince them to learn. We’re better off trusting people to seek the learning experiences they care for, and to share the responsibility of facilitating learning, with them.
The three examples of patterns I’ve shared in this article are not exhaustive. Several office-bound patterns are ridiculously ineffective for remote teams and companies. The broader takeaway for us is that we needn’t mimic the office when we design our digital workplaces. Many patterns work only in an in-person setting. Others were ineffective in the first place, office or not. Remote work is still a new medium. Let’s unshackle the way we think about work and find novel patterns that are native to this new medium.