Deep Work

Cal Newport is a smart guy. There's a reason why his book Deep Work is so popular. Uninterrupted time blocks of deep work are crucial for getting important work done. This is especially true for software engineers. Every single meeting that you put on a dev's calendar is a giant hole with a "NO DEEP WORK" sign in front of it.

It’s even worse than that. The size of those holes isn’t limited to the start and stop of each meeting. Depending on the placement of those meetings, those holes can extend well beyond the start and end times.

This is why I recommend that founders stop doing daily standups. What should they do instead? They should use async text chat like Slack or Teams. This approach has loads of advantages, but I’ve written about that elsewhere, and is not the focus of this article.

The focus of this article is to address the main objection I get from people about async standups.

When I talk to people about eliminating daily standups and suggest using async chat as an alternative, I am often met with shock. I hear complaints like "Nobody can be productive with constant pings and notifications!" or “Our Slack is already bad. It would only get worse if we didn't have a daily standup each morning!"

I know it seems crazy, but hear me out.

Your team can be productive using async chat as its primary method of communication. If you remove the disruption caused by a synchronous daily standup (or other recurring meeting), you do not automatically incur a larger interruption cost from notifications and long chat threads. Devs don’t have to be distracted by pings and notifications. You can balance necessary collaboration and communication with valuable focus and deep work.

Before I explain how, let me emphasize the importance of deep work for software developers.

Software Engineers and Deep Work

Deep Work is a non-negotiable requirement for software engineers. It takes time to get started, to build momentum, and to model a system in your mind. Interruptions cost developers by taking them out of that mode of thought.

It’s like working at the bottom of the ocean. You have to check your tanks, put on your scuba gear, get all of your equipment together, and slowly descend. Once you're down there, you can be productive. If you are called back up to the surface, it will be a while before you can get back down to the ocean floor and return to a productive state.

This “ocean floor productivity” is flow state. It's where developers are at their best, and for many, it's where they are happiest. This is where they create enduring value for the business: features, fixes, documentation, tests, etc. It's difficult to do any of these well without full attention and focus.

The key to maintaining flow is resisting calls to return to the surface. Some teams make this impossible. They have the rule that every day, you have to be “back up in the boat” from 10 am to 10:30 am. If you had to operate that under that rule, I wouldn't blame you for staying in the boat until 10:30.

Even without a standing daily meeting, the surface will try to bring you back up. Email, Slack notifications, news alerts, text messages, and phone calls will do their best to get you to stop what you're doing and pay attention to something else instead.

Given that deep work is so valuable and notifications and alerts are so distracting, how is it possible that async chat is more effective than one focused meeting? Doesn't async chat result in constant notifications throughout the day that will stop the flow state? Wouldn't it be so much better to focus the team on collaborating for 15-45 minutes and then have all that time back for deep work?

No. Not if the devs shut their notifications off.

Balancing Collaboration and Communication with Focus and Deep Work

Devs should either be in deep work mode or not. When they are in deep work mode, they should turn off all notifications and eliminate all distractions. Silence all alerts. Close all tabs that aren't relevant to work. Nothing should get through.

Then, once an hour, developers should check their messages and notifications. If something is on fire and needs their immediate attention, they should attend to it. But normally, this is not the case.

For non-urgent requests, devs can respond in a way that minimizes disruption to flow and gives the requestor a solid idea of when they will get their resolution. For example, "I'm finishing something up right now, but I will get back to you at 2 p.m."

In my experience, exceedingly few things would be negatively impacted by a response time of an hour. Devs do not need to be “on call”.

If you’d like a specific framework to follow, this approach works perfectly with Pomodoro:

1. Eliminate every single possible distraction
2. Set a timer for 25 minutes
3. Work until the timer goes off
4. Set a timer for 5 minutes
5. Stand up, walk around, stretch, get a drink, go to the bathroom, etc... until the timer goes off
6. Set a timer for 25 minutes
7. Work until the timer goes off
8. Set a timer for 5 minutes
9. Check notifications. If there are any that are non-urgent, reply with a time you will address it. If there are any that are urgent, attend to it
10. Go back to step 1

Of course, not all collaboration is responding to one-off requests. Code reviews, QA, helping with blockers, and types of multi-party planning discussions all come to mind. Those aren't deep work, but they're all important, so how do we fit those into these short 5-minute Pomodoro breaks?

We don't.

Deep work is mentally taxing and difficult to maintain. Cal Newport estimates a maximum of four hours per day. What's great about this is that four hours of deep work is orders of magnitude more valuable than spending eight hours in the shallows, and you have four hours left over for all the collaboration activities above.

Sometimes, developers need to schedule blocks of time with each other for reviews or discussions. That's fine. They can be adults about determining when these are necessary, deciding who actually needs to be available, and scheduling them at times that are minimally disruptive to flow.

Next Steps

If this sounds easy, it's because it is. In fact, the only likely issues will come from leadership. Leaders need to be willing and able to set and reinforce boundaries. Two things should be made clear to everyone:

1. Do not expect anyone to respond to you in less than an hour.
2. You are required to at least acknowledge a ping within an hour of receiving it.

In my experience, people often have contradictory fears for their team. One is that devs are off in their individual silos, building without any regard to other team members or business needs. The other is that there is so much chatter and noise that nobody is getting anything done.

If these are your fears, run an experiment. I'm confident that neither fear will materialize. What you will see, however, is happier and more productive developers.