Time is the most important factor in creating high-performing software teams. Managers must carefully manage time, scope, and people to deliver successfully.
What teams do with their time is the primary factor in determining their output. Even if you hire the best engineers, they will not succeed if they spend all their time on the wrong things or are constantly interrupted.
Software engineering is a creative task, so total time spent is not enough to ensure efficiency or success. Fragmented chunks of 5 minutes may mean that the project never gets done. For most engineers, that’s not even enough time to make meaningful progress on a simple bug fix.
Software projects typically require engineers to have several concepts and context in their memory to make forward progress. A task might require reading a ticket with requirements, looking at log output, and reading related code before making changes. Any interruption causes an expensive context switch that forces you to start the whole process over.
Flow state is when you are fully immersed in your work and at your most productive. Fragmentation and interruptions kill flow state because context switching is so costly for engineers. This state is typically where the most work gets done and the hardest problems are solved.
Because it takes time to get enough context to make forward progress on a task, we’ve found that the minimum unit of time that allows for flow state is 2 hours. Two hours of uninterrupted time is called Maker Time. It is certainly possible to achieve flow state in shorter periods of time, but that’s typically an exception. Periods longer than 2 hours can also lead to higher quality flow states.
Fragmentation is when you have a poorly organized calendar or work schedule that prevents you from creating long periods of open space to work.
A day where you have eight 30-minute meetings spread equally once an hour will be significantly less productive than a day where those 8 meetings happen from 8am-12pm and you have the rest of the afternoon to do focused work. Maximizing the percentage of Maker Time in a week is an important priority for software teams.
I’ve found that the best teams are able to achieve 70% or higher maker time during a work week for their engineers.
As a manager, it can be hard to remember what it was like to need primarily Maker Time to succeed because a manager’s role can be significantly more interrupt-driven. Paul Graham summarizes the differences between manager and maker schedules in his essay Maker’s Schedule, Manager’s Schedule: http://www.paulgraham.com/makersschedule.html. To be most effective, engineers require large blocks of uninterrupted time, and any interruptions are disproportionately costly.
Key takeaways: