Silo-ball, Async Fixation, and Deep Work Obsession
An emerging set of anti-patterns in the age of remote work
Zoom fatigue.
Most of us will have heard of the term by now. Typically, it’s described as the fatigue one feels after a day of non-stop video calls (Zoom being just one of many group video calling tools that are now available).
What causes this phenomenon? Some contend that being on camera for long periods of time can feel performative, reduce mobility, and increase cognitive load; this has led to many companies adopting camera-optional video calls.
However, consider that Software Engineers and other product development practitioners have been complaining about excessive meetings long before the COVID-19 pandemic and the subsequent ubiquity of remote work. In fact, I’d hazard to guess that this complaint stretches back to the start of Agile software development. Among other changes, Agile brought about radically new ways of working where software programmers began to collaborate more closely with other product development disciplines than before.
My prior two posts — Fend-for-yourself-onboarding and The Hero — each covered a fairly straightforward product team anti-pattern. By contrast, this post covers a set of three anti-patterns that are more nuanced and thus trickier to avoid, identify, and address.
Silo-ball
The term “silo-ball” illustrates the practice of “lobbing back” tickets from a downstream lane of a Kanban board to an upstream one. While doing so is sometimes unavoidable, indiscriminate adherence to this practice can be harmful to the team.
For example, if a Software Engineer requires only a few minutes of a Designer’s time to consult them on a particular UX behaviour, then moving the associated ticket back to the “Design” lane undermines the team’s productivity. This is because the cycle time on the ticket has now increased by an indefinite amount — progress has stalled on the work until the Designer picks the ticket up to offer their feedback. Once they do, they again move their ticket back to the “Engineering” lane, where it sits for an indefinite period until a Software Engineer picks it back up again.
Further, if the team gets comfortable with this practice, then team members specialize in working inside one lane only, rejecting involvement in any work outside of their lane. Collaboration plummets as the lanes harden into silos and disciplines are boxed into roles. Ultimately, this leads to a team that cannot respond to change in a rapid and effective manner, due to the rigid dependencies that form across silos and roles.
Instead of moving a ticket backwards on the Kanban board, a team member can resolve their blocker by jumping on a call with their teammate and conducting an impromptu cross-disciplinary pairing session. Given the knowledge asymmetry (i.e. different disciplines), I’d recommend strong-style pairing for such a scenario.
Backward ticket movements on a Kanban board are sometimes inevitable. Nonetheless, a product team should recognize the significant increases in cycle time and reductions in collaboration that they can cause.
Async fixation
What drives the behaviours that lead to “silo-ball”? 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, when compared to in-person interaction. More specifically, we proactively avoid Zoom fatigue by rejecting both video and audio calls altogether. Thus, the commonly-prescribed treatment to Zoom fatigue is to move as much work as possible to asynchronous collaboration. Being “async-fixated” means that we take asynchronous work to its extremes — beyond the realm of 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.
How does “async fixation” look like? We replace as many recurring meetings with async approaches as possible:
“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 through 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 a good thing. 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.”
Leads to significant delays in cycle time as the PR is shuttled back from reviewer to author and back again (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 who have 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. Sometimes, over-reliance on asynchronous chat tools can 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, there’s another reason for async fixation that is far more compelling and insidious.
I’ve been listening to Deep Work (on audiobook) lately. While a great book, there is an implicit assumption running through the entire book — 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 solo deep 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 solo deep 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, as opposed to being at the mercy of them. Here are some ways in which this can be achieved:
Effective pair programming sessions are deep work sessions. It takes some practice to get in 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 be maintain a flow state resiliently as follows: one person from the pair can field any synchronous requests while the other person continues to code. The interrupter now 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
Whether it’s “silo-ball”, “async fixation”, or “deep work obsession”, all lead to the same result over time: a team operating as a waterfall, with each team member closed off from the other in their own silo-sanctuary, where they measure their own effectiveness based on how long they can stay focussed and uninterrupted instead of whether they are creating anything of value.
Having said that, we can have the best of both worlds. We can leverage the freedom that remote work affords to carve out larger periods of deep work (both as solo and as group practitioners). We can also leverage synchronous communication in thoughtful ways to level-up on collaboration while reducing a wasteful upward creep in cycle times.
My advice to software product practitioners is this: embrace remote work and optimize for deep work, but don’t neglect synchronous co-creation that enables short cycle times and tight feedback loops. Because at the end of the day, it’s the latter that ensures that we’re building valuable, working software for our customers.
I love this post! It nails 2 of the 3 issues I've been grappling with since the beginning of the pandemic and remote work. They are async fixation and deep work obsession. You've validated my hunch that pair programming is actually a deep work session. Also, I wanted to point out that async fixation has the negative aspect of reducing a sense of connected-ness on the team.
"Just add a comment to the PR and I'll get to it" - this couldn't have come at a better time! Struggling with some PR issues on the team and I have a feeling async fixation may be playing a role..