RDEL #86: What barriers prevent engineers from achieving "flow"?
Common barriers that keep engineers from achieving flow are categorized as situational, personal, or interpersonal barriers.
Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership, and apply the latest research in the field to drive to an answer.
Flow - or deep focus - is one of the most powerful predictors of high performance in software teams. Teams that regularly experience it can deliver more value, faster, and with greater satisfaction. But most engineers rarely experience it. This week we ask: What prevents engineers from reaching a state of flow—and how can engineering leaders remove those barriers?
The context
In recent years, software engineering teams have become increasingly aware of the importance of focus. Engineers often cite long blocks of uninterrupted time as essential for doing their best work. The concept of flow—a psychological state where a person is fully immersed and energized by their work—has become a touchstone for high-performing teams. Flow leads to deeper problem solving, faster progress, and a sense of intrinsic motivation.
Still, flow remains elusive for many developers. They’re often pulled in multiple directions—responding to pings, sitting in back-to-back meetings, or navigating confusing requirements. The result is fragmented attention and shallow work. To achieve a flow state, teams need a clear understanding of what’s getting in the way.
The research
Researchers studied data from 130 software industry employees to identify and categorize the barriers that impact software engineers’ ability to get into a “flow state”. Participants described situations that disrupted their flow at work, which researchers then analyzed using qualitative coding to group recurring themes and quantify the most common barriers.
Key barriers to achieving flow include:—
Situational Barriers:
Interruptions and distractions impacted 23% of respondents.
Time-related issues impacted 14% of respondents. This included tight deadlines, changing requirements, and unnecessary idle time.
Negative user experiences with development tools impacted 13% of respondents .
In this case, engineers were shifting focus from the main tasks to resolving secondary issues.
Personal Barriers:
Work not presenting enough of a challenge was the most common cause of not achieving flow, with 24% of respondents experiencing this.
On the other hand, 11% mentioning tasks were too challenging. Additionally, 4% of respondents noted the lack of learning opportunities and excessively steep learning curves as detrimental to flow experiences.
Interpersonal Barriers:
Poor management was mentioned by 3% of respondents
Poor team dynamics impacted 3% of respondents
Lack of communication impacted 3%
The application
This study reinforces a key concept: developer flow doesn’t just “happen”, especially not as complexity of organization grows. It’s the result of intentional choices in how we structure work, manage time, support learning, and reduce friction. While some barriers—like personal motivation—are harder to address directly, many of the most common obstacles are within a leader’s control.
Here’s how engineering leaders can put these insights into practice:
Protect engineers from interruptions and shallow work.
Minimize unnecessary meetings, batch requests, and empower teams to push back on low-priority pings that disrupt deep work.Shape the right level of challenge.
Match tasks to individuals’ skill levels: too easy leads to boredom; too hard leads to frustration. Use regular 1:1s and retros to identify where developers feel underutilized or overwhelmed.Fix tool pain before adding new process.
Engineers can’t get into flow if they’re stuck troubleshooting dev environments or dealing with flaky tests. Invest in stability, automation, and faster feedback loops in the dev pipeline.Strengthen communication and team support.
Regularly ask your team where collaboration is breaking down—and act on it.
When teams achieve flow, it is a multiplier for their overall performance. Teams that experience it regularly ship better software, with more satisfaction, and less burnout.
—
May this week bring you ample opportunities to achieve a state of flow. Happy Research Tuesday!
Lizzie