Anyone who’s raised teenagers understands the transformation that happens to a child’s sleeping patterns as they go through puberty. They go from waking you at the crack of dawn to wanting to sleep all day. This is because their “chronotype” changes during puberty. A person’s chronotype influences when they want to sleep and when they have their period of peak energy. It also tells us something about how we should organize our work days to be most productive.
Note: a chronotype is a result of a person’s biology, not something that you can easily change.
Chronotypes and Productivity
Scientists divide people into different chronotypes based on when we want to sleep and when we prefer to wake up. Since chronotypes follow a bell curve distribution, we can be roughly divided into 3 categories1:
- Larks who prefer to wake very early in the morning (e.g., 5am)
- Night Owls who prefer to go to sleep late and stay asleep until a socially unacceptable time (e.g., 9am)
- Third Birds who tend to go to sleep before midnight and wake around 7am. Most of us fall into this category.
Regardless of your chronotype, science has also shown2 that people are most productive from roughly two hours after they wake up until their mid-day meal (aka lunch). These are referred to as our “golden hours”. After lunch, energy dips and then rebounds again in the afternoon and evening, but not usually as high as in the morning.
This means that the best time for getting stuff done is the few hours at the start of your workday.
So for larks, their golden hour is usually from 7-11am. Night owls will be most productive between 11am and 2pm. And the best time for third birds is usually from 9am to 12pm.
Focus Time
Knowledge workers engaging in creative work benefit by getting into “flow state”3. Software engineering especially is difficult and requires tremendous focus (it has a “high mental load”). The ideal state is when you are super focused, time disappears, you feel challenged but not overwhelmed, and you become one with the code. This is called being “in the flow” and when you’re in this state, you feel hyper-productive.
The problem is that getting into the flow takes significant time and getting knocked out of the flow is super easy. It takes, on average, ~20 min to get into the flow4 - you need to ramp up on the task, visualize the code architecture and build a mental model of the changes you are going to make or the bug you are trying to solve.
Getting into flow is only half of the challenge. Once in flow, engineers need about 2+ hours of time to make serious progress on work, and this resets with each distraction. This is why experts recommend blocking off big chunks of time to do serious creative work - so you can get into the flow!
Note: this applies mostly for individual contributors and not managers due to the difference between Maker’s schedule and manager’s schedule.
Check out the comic on the right or watch this 5 min video for more on the flow state:
Reclaiming our mornings
Combining our understanding of flow with what we know about chronotypes and productivity, it makes sense to dedicate your morning golden hours to getting into the flow and being optimally productive.
The problem is that most teams have their daily standup in the morning. This prevents anyone from trying to do really productive work before standup because there is rarely enough time to get into flow. It also inherently limits the amount of time you have for getting into the flow before you hit your productivity trough. It would be much better if developers could spend their morning getting into the flow and being productive without being distracted by meetings.
So if science shows us that morning standups hurt our ability to leverage our optimally productive time, what can we do about it?
While you could try having standup even earlier, I suspect most engineers would revolt at such a suggestion. So my recommendation is that teams move their daily standup to right after lunch, say 1:30pm.
Having an early-afternoon standup is better for multiple reasons:
- After lunch is a period of low energy for most people, so it’s a great time to have a meeting like a standup which doesn’t require a lot of creativity
- It allows developers to spend their morning, the period of peak productivity, focused on work
- Having it right after the period of maximum productivity also ensures that the work will be top-of-mind (as opposed to morning standups where you’re trying to remember what you did yesterday).
- It optimizes the afternoon for team members to collaborate on any challenges they face
Here’s what that looks like on the same “stages” diagram:
Resistance to change
When suggesting this to teams, I almost always initially meet resistance. People tend to feel that the morning standup is somehow sacrosanct and moving it just feels wrong.
I consider this a form of status quo bias and I recommend reading my post on that for tips on how to overcome that. In a nutshell:
- Explain you want to help them, and share the science behind why this is better.
- Start with a single team where you suspect they will be less resistant. Use their success as precedent to suggest the change to other teams.
- Suggest an experiment to see if it works. If it doesn’t, it’s easy to switch back.
If you’ve tried this or seen it in action, please let me know!