Skip to content
GitHub Copilot is now available for free. Learn more

Time management for makers

As makers, software engineers should adopt these seven essential habits.

Artwork: Susan Haejin Lee

Photo of David Noël-Romas
Stripe logo

David Noël-Romas // Staff Engineer, Stripe

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

It’s been more than ten years since Paul Graham wrote Maker’s Schedule, Manager’s Schedule, and in that time his then-revolutionary ideas have become almost mainstream. Every worthwhile engineering manager now knows—even if they don’t always act upon this knowledge—that engineers require long stretches of uninterrupted time in order to make things. And yet, the interruptions continue to come.

Upon reflection, it should not be too surprising that even the most protective of managers can’t shield their engineers from every interruption. There are several inherent tensions at play:

  • The (relatively modern!) expectation for engineers to “own” the systems they build—that is, to be responsible for the system’s successful operation and on-call when it fails—has many benefits, but it obviously exposes those engineers to interruption when things break.

  • Organizations are learning to replace top-down decision models with ones that rely more heavily on “ground-level” data, which is generally held by “ground-level” workers. Again, this is probably of net benefit, but again it ultimately exposes engineers to interruption when unexpected decisions need to be made.

  • Even the most efficiently run organizations must pay the communication tax. Certain meetings cannot be avoided, and as our organizations become more geographically distributed, it becomes more difficult to schedule meetings in a way which does not break up blocks of each participant’s focus time; a 9AM meeting in San Francisco is an 11AM meeting in Chicago.

These complexities compound as engineers progress in their careers. They are increasingly relied upon to untangle the most critical of on-call incidents, contribute to the most urgent of business decisions, and act as the interface to a greater variety of stakeholders. Their schedule starts to look more like a manager’s schedule than a maker’s schedule. This is a dangerous trap!

Engineers are primarily makers. They may also be expected to do many other things, but ultimately the business expects them to make things—requires it of them, in fact—and will primarily assess them against their ability to get things made. Engineers who fall into the trap of accepting a manager’s schedule are prone to suffering one of two fates:

  1. They may continue making things outside of regular work hours, since it’s the only time they can get anything done. They become overworked and burnt out.

  2. They… *gasp* become a manager.

A common way of avoiding these fates is simply avoiding increased responsibility; if an engineer can avoid being relied upon to untangle critical incidents, contribute to business decisions, and talk to stakeholders, then they can avoid falling into the trap! This is a tried-and-true strategy, but it is often coupled with stifled career progression.

So, how can makers working inside an organization avoid the trap of the manager’s schedule while still scaling their responsibility, ambition, and impact? Engineers who do this successfully tend to exhibit the following behaviors:

  • They are defensive of their time.

  • They “pay themselves first.”

  • They defend the time of others.

  • They clearly designate interrupt-driven work and batch it.

  • They clearly designate low-leverage work, and time-box it.

  • They communicate with candor.

  • They prioritize ruthlessly.

Let us review each of these behaviors in turn.

Defending their time

What does it mean to defend time? It means internalizing the idea that time’s value increases extralinearly over continuous blocks. In other words, eliminating interruptions and batching what can’t be eliminated, to maximize uninterrupted time.

This is easier to do in a remote work environment, since there are no impromptu visits to one’s desk, or group coffee breaks. Even remotely, engineers should be wary of interrupt-driven communication tools like Slack. A practical approach is to batch written communication like Slack or email into predetermined time slots throughout the day, and cluster any unavoidable meetings back-to-back as much as possible.

But how can an engineer promote these meeting clusters in their calendar?

“Paying themselves first”

Personal finance aficionados may be familiar with the idea of “paying themselves first” by contributing to their savings account and fixed expenses before allocating money for miscellaneous line items. Time works the same way: engineers who understand the extralinear benefit of continued un-interruption can schedule their focus time first, far in advance of other demands which might come up. (It is never too late to start this practice! If your calendar is full right now, it is probably empty next month or the month after.)

Another idea which engineers can borrow from personal finance is to define their “time budget” far in advance. Besides just claiming focus time, engineers can maintain a long-term outlook by deciding early how they will allocate that time. They can define “accounts” like programming, writing, professional development, meeting prep, presentation prep, personal time (lunch, end-of-day, etc), and pre-allocate time for each in accordance with their long-term goals.

Defending the time of others

This is perhaps the “Golden Rule” of time management: impose upon others as you would have them impose upon you. Engineers who manage their time well (and have a modicum of consideration) do not schedule into other people’s focus blocks or personal time. If an exception is absolutely unavoidable, they will at least ask the recipient privately before adding the imposition to their calendar.

Another critical element in defending the time of others is placing a huge emphasis on unblocking people; engineers who are good at time management have an instinctive understanding of the cost of blocked colleagues. Defending the team’s time, and the organization’s time is important! Conversely, unblocking people rarely means accepting a long interruption; instead, it more often means helping the blockee find the next question to ask or the next piece of information they need in order to proceed in their quest.

Clearly designating interrupt-driven work

There are some forms of engineering work that are inherently interrupt-driven. Competent engineering organizations usually batch this work into “rotations” and designate specific times when individuals must be subjected to it; the most common examples are “on-call rotations” and “run rotations.” This is an extremely important and under-documented practice! When interrupt-driven work creeps up outside of these clearly designated boundaries, if it cannot be eliminated it should be added to an existing rotation or staffed with a new one.

Engineers should not spend more than 20% of their workdays attached to interrupt-driven rotations; this implies that healthy rotations must be composed of at least 5 engineers.

Clearly designating low-leverage work

Another behavior exhibited by engineers who are good at managing their time is the ability to successfully identify, and clearly designate, low-leverage work. There will always be tasks that need to get done, but which do not represent a high return on investment. The correct approach toward these tasks is to complete them in a time-boxed manner and accept a lower bar for quality other tasks. Taking this approach ensures that these engineers can spend more of their time and energy on activities having an outsized impact.

Communicating with candor

The best engineers communicate candidly. While it’s difficult to do well (Kim Scott’s Radical Candor correctly describes the failure modes as “obnoxious aggression” or “ruinous empathy”), the benefits are abundant. Among those benefits is improved time management, since engineers who communicate candidly are—by virtue of being direct—less likely to waste the time of others. Similarly, they will not allow others to waste their time, and have learned the ability to say “no.”

Prioritizing ruthlessly

This should actually have been the first behavior on the list, because it is the most important thing to get right: an engineer who is able to always ruthlessly prioritize the highest-impact work, and who is a maker, has successfully avoided the pitfall of the manager’s schedule! Of course, this is difficult to do in isolation. The other behaviors can help build toward ruthless prioritization.

Ultimately, though, a maker can perfectly defend your time—maintaining pure blocks of focus time—and still fail at their work if they are not prioritizing the right things. Determining the right priorities can be a challenge in its own right, but once determined a maker must be quite wary of changing them. There will always be short-term demands seeking to distract them from their priorities, and for the most part, they should try to ignore them entirely. When the distractions cannot be ignored, the other behaviors listed above can provide the tools needed to minimize every deviation from what the maker knows is most important.

Hi, I'm David. I've been playing with computers for almost two decades; it started with silly websites and hacks and has ballooned into much more. I spent many years in much smaller startups before joining Stripe as an engineer. These days I spend a lot of time building (virtual) things with my team, and when I'm not doing that I often think about the meta-problem: how to be better at building things with teams. I even host a podcast about it.

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing