RDEL #93: What causes procrastination for software engineers?
Task vagueness, stress, and complexity drive delays. Procrastination can hurt team trust, but also boosted creativity.
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.
Software development is full of friction points—vague tickets, shifting priorities, and cognitively demanding tasks that are hard to start.But what causes those delays, and what can teams do to mitigate the impact without killing momentum? This week we ask: Why do developers procrastinate—and how can teams mitigate its negative impacts?
The context
Procrastination is often chalked up to laziness or poor time management—but in software development, the story is more complex. Engineering tasks are cognitively demanding, often under-defined, and deeply collaborative. Developers regularly face shifting requirements, unclear ownership, and dependencies on others, all of which make it easier to delay starting and harder to make steady progress.
Yet procrastination in this context isn’t always harmful. Developers sometimes delay work to gain clarity, avoid unnecessary rework, or even generate better solutions under deadline pressure. Understanding this nuance is critical—because when procrastination does become a pattern, it can affect everything from team trust to delivery velocity to individual well-being.
The research
To understand how and why developers procrastinate, researchers conducted semi-structured interviews with 15 professional software engineers across seven organizations. Participants varied in seniority and domain (from startups to enterprise), and each interview was analyzed using thematic coding. The team identified not only when procrastination happens, but also why, how it’s perceived, and what helps.
Key findings included:
Procrastination negatively impacts productivity—but not always.
Researchers identified 15 negative effects and 8 positive effects, grouped across the five SPACE productivity dimensions. For example:
Emotional distress was the most commonly reported effect, with 100% of participants referencing it as a negative effect.
Reduced individual performance was cited by 86% of participants, often due to low-quality code or missed deadlines .
Strained team culture and reduced trust were reported by 93% of participants, affecting collaboration and peer perception .
Yet, 80% also reported at least one positive effect—such as improved mood, creativity, or near-deadline efficiency .
Three types of procrastination were identified:
Task Aversion: Delaying low-interest or misaligned tasks.
Task Avoidance: Driven by stress, fear of failure, or overwhelm.
Strategic Delay: Intentional postponement to work better under pressure .
The top triggers of procrastination were task-related:
100% of developers cited low-interest tasks as a key trigger. Other frequent causes included task vagueness (reported by 67%), unclear importance (73%), and high task complexity (60%).
87% referenced personal factors like low energy, stress, or imposter syndrome.
73% pointed to external triggers such as communication breakdowns or frequent distractions.
Procrastination often goes unseen. Developers rarely share that they’re procrastinating, even when delays ripple through teams. This makes detection and support difficult for managers.
The application
Procrastination isn’t just a personal productivity issue—it’s a signal. Developers delay work for task-related, emotional, and environmental reasons. When left unaddressed, it undermines delivery and team trust. But when managed thoughtfully, it can be redirected into momentum.
This study surfaced 14 concrete strategies developers use to mitigate procrastination. Engineering leaders can help normalize and scale those strategies across teams—not by eliminating procrastination entirely, but by reducing its harm and making recovery easier.
Here’s how:
Make tasks easier to start.
Encourage teams to break down vague or complex work into smaller, clearly scoped pieces. Use working sessions or async comments to clarify goals early and reduce fear of failure.
Build safe, visible mechanisms to surface delays.
Normalize early communication about when someone is stuck, overwhelmed, or behind. Regular async updates or health check-ins can prevent private delays from becoming public blockers.
Support productive delay, not avoidance.
Some developers work better closer to deadlines—but they still need structure. Techniques like artificial deadlines, short planning windows, and regular demos can create productive pressure without stress spirals.
The goal isn’t to “fix” procrastination—it’s to create environments where teams can recognize it early, respond collaboratively, and protect sustainable progress.
—
Happy Research Tuesday!
Lizzie
Really love the reframing of procrastination as a natural byproduct of the kind of work that engineers often do. You're managing for inevitable behaviors, not bad actors. Ex: I don't think I've ever seen an IC who was happy to be procrastinating.