Barriers to Flow
Boring tasks, unrealistic deadlines, last-minute priority changes, and insufficient tools all make it harder for developers to experience flow while working.
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.
This week I read Exploring barriers that prevent employees from experiencing flow in the software industry by researchers at the University of Jyvaskyla in Finland. This study examined the barriers that prevent software developers from experiencing flow in their work.
My summary of the paper
Developers, similar to other knowledge workers, can enter "flow,” where they are in a state of absorption and enjoyment while working. Developers benefit from frequent experiences of flow both in terms of satisfaction and productivity, however not all organizations provide environments that are conducive for entering a flow state.
Prior work on this topic has investigated it from specific angles, such as whether the amount of focus time is a good metric for predicting flow. The researchers here sought to gain a broader understanding of flow and the factors affecting it.
This study was conducted using the Critical Incident Technique (CIT) which offers a method for collecting self-reported critical incidents that have significantly negatively or positively affected an individual’s activities. In this study, participants answered open-ended and closed-ended questions about their experiences with flow and what prevented them from experiencing flow. Open-ended questions were coded through an iterative process, then sorted into categories. The study was conducted with 700 hundred developers at some of the largest software companies in Finland.
Here’s what the study found:
The top barriers to flow
The researchers identified 21 barriers to entering flow states. These barriers were grouped into three categories: situational, personal, and interpersonal barriers.
1. Work does not present enough challenges is the most prominent barrier to experiencing flow. This refers to developers working on tasks that are too easy, boring, or mundane: tasks that do not require strong commitment, or that lack learning experiences and creativity.
Interestingly, work presents too much of a challenge was also among the top barriers to flow. In these cases, developers referred to tasks that were hard to resolve or complex, that required skills or experience to solve that the developer did not have, or where there was a steep learning curve.
2. Interruptions and distractions surfaced as the second-most prominent barrier. These include physical and virtual interruptions (e.g. colleagues’ questions at the office, emails, and chat), distractions (e.g. background noise and a busy environment), task and context switching between tasks, and the frequency of meetings (having “too many meetings” or “unnecessary meetings”). It’s worth noting that interruptions themselves are not necessarily considered negative — it’s having too many of them that’s a challenge.
3. Time-related challenges relate to feeling pressure due to overly restricted or unrealistic timetables, facing unexpected changes, waiting for others’ input, and getting stuck in a task. A prominent barrier within this theme was facing unexpected challenges, which includes last-minute or changing priorities. Waiting for others was also a frequent challenge: developers said this leads to unnecessary idleness that inhibits flow (for example, having to wait for a response from a colleague).
4. Negative UX refers to both non user-friendly tools as well as poor code quality. As for tools, developers reported challenges such as experiencing technical difficulties, and working with tools that have limited features, are cumbersome to use, or that don’t deliver the outcome they envisioned. Developers also reported challenges related to poor code quality, such as bugs, entropy, and legacy code, as barriers to flow.
5. Insufficient resources is a lack of staff, budget, or proper tools. Most often, this was surfaced as being too short-staffed to manage the workload, or having insufficient technical resources. This theme also includes inadequate documentation.
Overall, most of the top barriers to flow are situational. This suggests the importance of the developers’ work environment on their ability to do focused work.
Final thoughts
Usually when teams don’t have enough time for focused work, they look to interruptions or meetings to see if they can make changes. This paper suggests alternative areas to explore: are tools causing challenges? Do teams have the necessary skills to complete work, or conversely, is their work challenging enough?
Apart from providing strategies for improvement, this paper is also useful because it connects certain problems to a higher-level outcome many leaders care about. Teams facing the challenges identified may use this paper to justify or advocate for changes.
That’s it for this week! If you’re interested in reading a guide for running an internal survey to identify problems impacting developer productivity, send me a connection request with the note “guide.”
Subscribe here if you haven’t already:
-Abi