Product Delivery Team Anti-patterns – Async Fixation

Estimated Reading Time: 7 minutes

Continuing the Product Delivery Team Anti-patterns Series, Paul Sobocinski, Director of Engineering covers the async fixation anti-pattern in this edition and how it straddles a fine line with async collaboration.

This blog post was originally published on Paul’s blog, Coder Spikes.

What behaviours lead to “silo-ball” (the anti-pattern covered in the prior article)? What’s stopping us from jumping on that 5-minute call with our colleague? Why do we instead ask them to look at it as soon as they “have a moment” to do so — essentially pushing it to the end of their personal queue of to-dos?

A reason could be the unappealing nature of video calls compared to in-person interaction. It seems we proactively avoid Zoom fatigue by rejecting both video and audio calls altogether. Thus, the commonly-prescribed treatment for it is to move as much work as possible to asynchronous collaboration. Unfortunately, being “async-fixated” means that we take asynchronous work to its extremes – far beyond common sense. A company that embraces async work unequivocally is in danger of finding itself at such an extreme since its employees can justify their unreasonable behaviour as part of the company culture.

What does “async fixation” look like? A little something like this:

• “Why have a daily standup over Zoom if we can just auto-create a Slack thread that asks the same questions? That is arguably better anyway because it saves a historical record of the responses.”
• “Why can’t we create an EasyRetro board and have team members populate it throughout the week? That way, if they can’t make it to the retro, at least their observations and opinions are captured. That’ll also shorten the actual retro, as most of the collaboration can happen asynchronously.”

There is some merit to these approaches. Doing pre-work leads to more efficient and effective meetings, so any encouragement around defining and completing prep work is good. At the same time, however, too much pre-work can lead to anchoring bias around an initial topic, especially when retrospectives are involved.

Avoiding synchronous interaction at all costs, however, is counter-productive and harmful. Some examples:

“Just add a comment in the PR, and I’ll get to it.”
This leads to significant delays in cycle time as the PR is shuttled back and forth from the reviewer to the author (see the diagram below for a visualization of this).

“Just start a Slack thread and see what people say.”
Biases respondents to those with easily-expressible and vocal opinions on the matter; respondents with nuanced opinions that take more effort to articulate are less likely to contribute.

“Just start a Google Doc and share it with everyone.”
Anchors the discussion to the first version of the document so only incremental changes are suggested and made.

Some ideas, comments, or questions are difficult to phrase. Sometimes your co-worker needs to talk through their thoughts with you. Over-reliance on asynchronous chat tools can sometimes lead to a rabbit hole of questions on a Slack thread that can instantly become moot via a 2-minute real-time conversation.

Deep Work Obsession

Besides Zoom fatigue, another reason for async fixation is far more compelling and insidious.

I recently listened to Deep Work on audiobook. While a great book, there is an implicit assumption running through it — that deep work is done alone and that it’s on you as an individual to figure out how to eliminate distractions so that you can effectively practise it.

Don’t get me wrong. I’m an avid believer in deep work and have practised it solo for certain tasks (for example, writing this post). However, as product practitioners, we should not take deep work as the aspirational pinnacle of productivity.

You may be asking — why not? What happens when we optimize a product team around deep solo work? Wouldn’t we get an explosion of profound insights or an accelerated delivery of features and bug fixes through large swaths of thoughtfully-written code?

Unfortunately, the answer is no. While we may gain some novel ideas or sophisticated code via deep solo work, we lose the short feedback loops that validate customer value via continuous delivery of working software. In other words, we lose agility.

That said, deep work need not be abandoned or even compromised to preserve agility. Deep work in groups can be resilient to interruptions instead of being at their mercy. Here are some ways in which this can be achieved:

• Effective pair programming sessions result in deep work sessions. It takes practice to get into a flow state with your pairing partner, but it is possible.

• A team that adopts pair programming with regular pair rotations eliminates the need for pull requests (PRs). Eliminating PRs usually means eliminating the predominant distraction on most product teams.

• A pair of programmers can maintain a flow state resiliently as follows: one person from the pair can field any synchronous requests while the other continues to code. The interrupter gets their answer sooner and doesn’t need to put their own task on hold.

• The team can choose to work as an ensemble, with one work-in-progress task at a time. In this way, the interruptions simply become part of the work.

Conclusion

Since moving to a remote-oriented work environment, I have seen many organizations become susceptible to an attitude of async fixation amongst their knowledge workers. This attitude leads to onboarding practices where new joiners are coerced to “fend for themselves” as interruptions and calls are discouraged. I described this phenomenon in detail in the first post of the series.

It also creates an environment that may encourage heroes. Remote work means that our work laptops are always at hand, so cracking them open after hours for that “quick fix” becomes especially tempting. I covered why this is such a concern in the second post of the series.

Heroics on their own are not harmful. However, along with an attitude of async fixation, they can lead to detrimental behaviours and systems on teams that lead to silos in knowledge and expertise, which in turn increase cycle times, harming the effectiveness of teams. The third post of the series dives deeper into this anti-pattern. 

The answer to these problems is not to return to outdated ways of working that involve ushering employees back to the office against their will. We can’t do something we’ve already done to solve something we’ve never encountered. That’s why it’s important to remember that remote work has created more opportunities than challenges, and the challenges it has created are all surmountable. 

I hope this series has given you a starting point in addressing them.

Paul Sobocinski

Director of Engineering, Practice

As a Practice Director, Paul is responsible for elevating the technical excellence of the Software Engineering practices at Connected and beyond. He does so through coaching, writing, public speaking, and of course, coding.

Paul is currently interested in fostering professional growth through skills-based learning, with a particular focus on pair programming, test-driven development, and emergent design.

More Posts