---
type: "article"
title: "Distracting software engineers is much more harmful than you think"
newsletter: "manager.dev"
newsletter_handle: "managerdev"
newsletter_url: "https://usecommune.com/n/managerdev"
author: "Anton Zaides (@antonz23)"
published: "2024-04-30T06:01:56.000Z"
canonical_url: "https://usecommune.com/n/managerdev/a/distracting-software-engineers-is-much-more-harmful-than-you"
markdown_url: "https://usecommune.com/n/managerdev/a/distracting-software-engineers-is-much-more-harmful-than-you.md"
chat_url: "https://usecommune.com/n/managerdev/a/distracting-software-engineers-is-much-more-harmful-than-you/chat"
source_url: "https://newsletter.manager.dev/p/the-biggest-problem-in-todays-work"
body_source: "imported"
likes: 0
replies: 0
body_words: 1566
---

# Distracting software engineers is much more harmful than you think

I always knew that distractions in the workplace are harmful, but only after reading ***Deep Work*** by *Cal Newport*, did I understand how severe the problem is!

Our work culture changed mainly for the better after COVID-19, but there were also some negative changes - like [an increase of 13.5%](https://www.notta.ai/en/blog/meeting-statistics?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think) in the amount of meetings per employee.

So why meetings and distractions are so terrible? And what can you do about it?

Today I’m going to cover:

1. **What** is Deep Work
2. **Why** it is so **critical**
3. So what’s **the big problem?**
4. How can you **create deep work time** for your employees
5. How to become **better at deep work** - mastering the distractions

# So what is deep work?

The term was coined by Cal Newport, in the great ***Deep Work: Rules for Focused Success in a Distracted World***book.

Deep work is the kind of work that requires a big part of your brain power and usually gives some unique value. It can’t be done while distracted! **If you can do a task during a Zoom call, it means it’s NOT deep work.**

**Shallow Work** is the opposite - things you can do without engaging 100% of your brain. Things like answering Slack messages/emails, reviewing a document, and so on.

Software engineering used to be a haven for people who enjoy deep work. There is a reason why some people still think that software engineers work alone with their headphones in the basement.

Nowadays, it’s becoming very hard to get those ‘Deep Work’ times.

# Why Deep Work is so critical

Working Deeply, is the only way to achieve the famous ‘flow’ state - AKA being in the zone.

[In a 10-year study conducted by McKinsey](https://hbr.org/2014/05/create-a-work-environment-that-fosters-flow?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think), people reported being **FIVE** times more productive in flow - meaning that **if we could increase the time we spend in flow by 15-20%, overall workplace productivity would almost double.**

*[There is a scientific explanation for that](https://hbr.org/2017/07/stop-the-meeting-madness?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think#:~:text=71%25%20said%20meetings%20are%20unproductive,organization%20approach%20meetings%20is%20possible.)**- that involves the releases of norepinephrine, dopamine, endorphins, anandamide, and serotonin. All five affect performance.*

More deep work time won’t only improve the performance of your engineers but also:

- Will help them make **fewer mistakes**, as they’ll be less distracted.
- Support their **work-life balance** - they’ll get more work done in less time, so more free time will be left.
- **Improve their skills** - only during those focused times the toughest challenges can be solved, and the biggest improvements to skills happen.

# So what’s the problem?

Remote work should have been an answer to this - no commute, fewer distractions. In reality, only the first part is true.

Since 2020, in addition to the 13.5% increase in total meetings, there has also been [a rise of 60% in remote meetings](https://www.cfo.com/news/remote-meetings-up-60-since-2020-weekly-stat/654749/?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think). The unsurprising part is that [92% of people say they multitask](https://www.flowtrace.co/collaboration-blog/50-meeting-statistics?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think) during those meetings - and I would guess the number is 100% for software engineers.

There are 2 main problems with that:

### 1. Work that should be Deep, becomes Shallow

Remember the simple test we discussed above? If you can do it in a Zoom meeting == it’s shallow work.

A great example is reviewing a PR. If you have a busy day filled with meetings, when would be the best time to review it?

During the meetings of course… But **reviewing a big pull request should be deep work!**Same for bug fixes, or writing design documents.

Doing those tasks during a meeting starts a horrible flywheel:

- The quality of the work gets poorer so more problems arise → more meetings are scheduled to address them.
- People are being distracted during meetings so no good decisions are taken → more meetings are scheduled…

And it’s not the fault of your multitasking engineers - it’s the fault of your meeting culture.

### 2. Engineers are not reaching the flow state

> [It takes 15 minutes just to get going and only by the 45-minute mark](https://www.locationrebel.com/flow-state/?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think#:~:text=The%20science%20shows%20us%20that,disturb%20you%20until%20after%20lunch.) (!) you will hit your peak.
>
> Every time you’re distracted, that clock resets thanks to [context switching](https://reclaim.ai/blog/context-switching?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think). And since the average employee is interrupted [31.6 times/day](https://reclaim.ai/blog/task-management-trends-report?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think), that means they’re getting pulled out of their task work every 15 minutes, making it impossibly difficult to attain a productive flow state.

Do you understand the severity of the problem? 31(!!!) distractions in a day!

It was not just the time in meetings that is lost. Every distraction sets you back 15-45 minutes, leaving you by the end of the day with just 1-2 hours of productive time in the BEST case scenario.

I love this analogy, borrowed from [this Reddit comment](https://www.reddit.com/r/programming/comments/1bbcoec/comment/ku9i16h/?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think):

![No alt text provided for this image](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/202c9e46-963e-4ad6-8057-0bb23d9038d2/3458f0f4-d1fb-449e-86f5-e9d5e74463bc_812x645.jpg?t=1773825852)

> Imagine developers are like miners. digging is our job. Every time you have a meeting, we need to pack our things, and get to the entrance of the mine on time.
>
> After the meeting is finished, we need to walk alllll the way back to where we were working, assuming we even remember the right path...
>
> So if you want us to get you some diamonds, LET US WORK IN PEACE.

In[the famous “Maker’s Schedule, Manager’s Schedule”](https://paulgraham.com/makersschedule.html?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think), Paul Graham wrote:

> When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

**Software engineers need at least 4-5 hours of uninterrupted time a day, and it’s our job as managers to provide it.**

# How can we create deep work time

### Improve the meeting culture at your company

It’s not that hard to fix - you ‘just’ need to get all the managers to commit to basic rules:

1. Meetings should be **effective** - obvious right? But still rare… Have a clear agenda, and clear outcomes.
2. Have a **fixed daily time for meetings** - and leave big chunks of ‘no-meetings’ time. You can either do no-meeting days, or no-meeting hours, it depends on your organization. That’s what worked for :

![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/16ade022-ca8d-416c-b831-d534dafdefa0/397f6afc-28d1-48d9-aa5f-7fe7cc01d0d8_736x227.jpg?t=1773825853)

1. **Invite only people who are really needed** - this is something that remote work is bad at - it has become too easy to just invite everyone. People think to themselves: “Worst case, they’ll multitask, and be available in case they are needed”. This is an awful approach! Remember - you cannot achieve a flow state while multitasking.
2. **Go async where you can** - a big percentage of meetings can be Slack threads, or emails.

### Set an example

Once you get the meetings under control, you can deal with the other interruptions.

The best way to create a good culture is to cherish your own deep work time, and make sure your team respects it. I have to admit that I’m still struggling with this one - I schedule focus time in my calendar, and put on my headphones, but I still sometimes check Slack and answer when interrupted.

I know this sets a bad example for my team - deep work time should be sacred, and people should know it’s completely acceptable to not be available in Slack for a couple of hours.

# H**ow do you become better at deep work?**

So the meetings are under control, and nobody bothers you. Turns out deep work is STILL a hard skill to master.

To work deeply is to focus every bit of brain power on solving a problem. Newport’s research shows that **modern life changed our brains.**Test yourself - how long can you work without reaching for your phone, or visiting some website?

No distractions means – no emails, no Slack, no WhatsApp, no Instagram, no notifications!

We need to **teach our brains how to be patient again.**When starting a deep work period, Newport suggests setting a target, **something feasible but hard to achieve**.

For example - let’s say want to practice, and set aside 60 minutes for deep work, to work on a specific programming task.

After 20 minutes, you get stuck, but you have your ‘non-deep’ time (where you can talk to people on Slack) only in 40 minutes. In this case - **don’t break the deadline**. Yes, even if it’ll take you longer to solve that problem - you’ll reap the long-term benefits of training your brain.

If you are “nothing-I-can-do-without-help’’ stuck (which should be very rare), you can move the deadline closer (for example 20 minutes from now), but never break the focus time immediately.

Slowly, you’ll improve.

# Final words

If you do this one right, I’m 100% sure your team will thank you.

It’s up to you to create a culture that supports deep work, and respects people’s quiet times.

### Cal Newport’s book recommendations

If you like the genre, you’ll enjoy some of the books Newport suggests. For an easy way to save them,[I created the list in BookWiz for you](https://bookwiz.app/lists/recommended-by-cal-newport-e29e63?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think):

[Checkout Newport's suggestions](https://bookwiz.app/lists/recommended-by-cal-newport-e29e63?utm_source=newsletter.manager.dev&utm_medium=newsletter&utm_campaign=distracting-software-engineers-is-much-more-harmful-than-you-think)

![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/57ec448a-3851-4463-b0c3-b52d5fe845bb/5f473d8b-0f01-4254-b1dd-621edc510518_998x829.jpg?t=1773825853)

### What I enjoyed reading this week

1. [The unspoken skill of finesse](https://newsletter.weskao.com/p/the-unspoken-skill-of-finesse?utm_source=%2Finbox&utm_medium=reader2) by - this one hit home. It’s a crucial skill I’m missing, Wes provided great tips on how to improve it. **Crucial for managers!**
2. [5 symptoms of a project with a tech-debt problem](https://thepeoplessoftwareengineer.substack.com/p/5-symptoms-of-a-project-with-a-tech?utm_source=%2Finbox&utm_medium=reader2) by . Simple checklist to see how bad is it in your company.
3. [Earth AI](https://www.notboring.co/p/earth-ai?lli=1&utm_source=%2Finbox&utm_medium=reader2) by . Another amazing deep dive article, on a unique company, that combines mining with AI.

***

[Powered by beehiiv](https://www.beehiiv.com/?utm_campaign=e9ee482d-96bf-45e8-906d-3aac28797658&utm_medium=post_rss&utm_source=manager_dev)

***

## Discussion

No replies yet.