How (Some) Engineers Work
Since my sophomore year of undergrad, I’ve been fascinated with the idea of systems that purport to increase productivity. During my four years of music school I experimented with various todo apps, time management systems, and even a horrendous two days of polyphasic sleep. In case you’ve lived a good life and not heard of it, polyphasic sleep is sleeping twenty minutes at a time throughout the day instead of the usual eight hours at a time. Basically, you subject yourself to sleep deprivation until you start hallucinating that you’re getting things done. None of these things actually made me more productive—especially not polyphasic sleep. More often than not, this lack of productivity was due to focusing on the wrong thing: I would study theory and play through mechanical exercises when I should have been training my ear and transcribing. The ability to prioritize my work came much later in life. But there are also diminishing returns to a time management system’s complexity. It’s fairly easy to lifehack your way into a behemoth of a system whose care and feeding take away valuable time from, you know, actually doing things.
I suspect that one of the problems with many personal productivity systems is that they’re marketing materials as much as anything: they’re designed to make you feel like you’re getting more done as much as they are to help you be more productive. Many of the folks hocking the most complicated systems have job titles like “life coach” or “personal success guru.” And while their systems may very well work for other life coaches and personal success gurus, they’re far from universally applicable. So if I’m feeling led astray by the advice filling YouTube channels and productivity blogs, where do I turn for guidance? How about other people in my field?
One of my favorite books on time management is Time Management for System Administrators by Tom Limoncelli. I don’t necessarily use every piece of advice in the book, but I love it because it’s written by someone who actually does the same work as his audience. Tom is an actual sysadmin working at an actual company telling us what he actually does to manage his time successfully. Luckily, I happen to know many engineers who are impressively productive. So, in late 2019 I put together a short survey asking about their work habits, told myself I would write a blog post about it, and promptly let the responses sit there through the winter holiday season whilst I whiled away my time with family, friends, and wine. I regret nothing. But, the holidays are over and we’re now firmly in the new year’s “self improvement” portion, so I’ll attempt to distill the responses into some takeaways that might actually help with productivity.
A note about the survey
The survey is not intended to be comprehensive or scientific in any way. The sample size is deliberately very small because I only wanted responses from people I know. We’re all busy people, life is filled with wonders to experience, and correcting the data set for every internet rando who responds “worky mcworkface” isn’t how I want to spend my weekend. The respondents also skew quite senior in terms of job title because I wanted these results to have a certain amount of experience behind them. I’ve been guilty of suggesting “hey, you should try this thing that I tried literally once and it worked in that one instance” before. I’d rather not repeat that mistake here. If you’re looking for a scientific study on the working habits of software engineers, look further.
On average, roughly how many projects do you work on at a given time? If you work on multiple projects simultaneously, what is your relative level of involvement in each (e.g. leading the project, contributing code/docs/designs full time or part time, advising on the project)
This question is intended to gauge the level of large-scale multi-tasking that the respondents engage in. Most respondents work on three to five projects at a time, with one or two projects as the primary focus and the rest in an advisory role. The three to five projects are broadly divided between one or two core team projects and the rest as cross-team work. One respondent calls the secondary work side quests. Managers consistently responded that their work isn’t easily divisible into “projects” in the traditional sense, which aligns with my understanding that the best engineering managers trust their teams to make the gritty technical decisions, so projects get a bit fuzzy since you’re mostly providing coordination, coaching, and cover. Unsurprisingly, the takeaway here is the importance of focusing one’s work on what matters. Limiting yourself to one or two primary projects at a time keeps you focused on what the next step is to complete the project, and side quests give you something to work on if you’re main line of work gets blocked.
What tools do you use to keep track of your todo list and work to be done (e.g. apps, paper, etc.)? Briefly describe how you use those tools.
This question’s most surprising result is the total absence of any dedicated todo apps: no one used Todoist, Omnifocus, or any of the other myriad apps that are supposed to keep track of your todo list. In fact, there was almost no consistency in tools at all, with one exception: calendars. Calendars are a big part of my own productivity: if I need to do something, I normally schedule time to do it so that that time isn’t monopolized by something else. This sentiment is echoed in the responses. The other constant is that all of the preferred tools are extremely flexible. Nearly every respondent uses some combination of “thing that contains plain text”—Google Docs, Google Keep, a text editor, and paper were all popular results—and a calendar as their main tools. I didn’t ask why the respondents preferred plain text tools, but if I had to venture a guess it has to do with flexibility. Most todo tracking apps allow you to add context to a task with a comment or extra field, but ultimately you’re beholden to the app’s task data model. With plain text, you can make up your own data model on the fly based on the needs of the task, making this one of the few use cases where schemaless actually makes sense.
How do you prioritize what to work on at a given time? Provide as much detail as you can.
Nearly all the responses to this question emphasize having an extremely discerning sense of what actually needs to be done versus what seems like it might be urgent. This theme is likely due in large part to the respondents’ relative seniority: “this task needs to be done” and “I’m the one who needs to do it” are senses that one builds and refines throughout their career. A commonly stated heuristic for “does this task need to be done now” is “will other people be affected by this task not being done?” Tasks that block others are almost always given higher priority or delegated so that they can be done quickly. The responses also emphasized the importance of not always being in the critical path. “Am I the one who should be doing this task” is an important question to be realistic about, both to make sure that the task gets done, and to keep yourself from burning out. Roughly, most respondents' priority order is: urgent work blocking another team, project work, side quests, everything else that might fit the heuristic as being important. Drop everything else.
How do you handle incoming requests?
As with the previous question, the responses to handling incoming requests underscores the need for a well developed sense of what is actually urgent and what might appear to be urgent to someone else. Along with that, they emphasized the need to cut down on the number of incoming requests you get, and to be able to push back if requests don’t seem urgent. Cutting down on the number of incoming requests you receive is a bit of an art, but not actively monitoring Slack if you don’t have to helps. Sometimes the economics of asking someone for something favors proximity, and by constantly monitoring Slack channels where questions are going to be raised you run the risk of being on the receiving end of an interrupt. In the case that you receive an incoming request, nearly every response included some version of “write it down, set aside time to batch small tasks, and schedule the rest,” and stressed the importance of avoiding context switches where possible. Obviously there are some exceptions to this rule. “Hey folks, where’d the database go?” is an incoming request that’s probably worthy of a “drop everything” approach. People favored different techniques for pushing back on incoming requests—requesting a Jira ticket or a meeting were both common—but the key insight is putting the burden on the requester to prove urgency. To quote one respondent: “If it's not real it'll die when I ask them to do a small amount of work and give up some time.”
How do you handle/keep track of "open threads" (i.e. situations where you have a long-running todo item that requires coordination of multiple people and possibly many steps)?
The responses to this question are wildly inconsistent, suggesting that–much like making Kubernetes usable–it’s a hard problem that everyone is solving their own way. The only theme among the responses is “don’t try to keep everything in your head.” Some people keep a long running list of tasks, some use spreadsheets, some use tools like Jira, and some use recurring Slack reminders. One interesting response splits the notion of “open threads” into “ongoing finite tasks” and “ongoing infinite tasks.” The former has some definite end date, and the latter is a thing that you do on a recurring basis until there’s some reason to change it. Handling these as separate cases seems like it would be useful, but I’ve not yet found a way to work it into my own system.
Overall, I’m a little surprised by the range of responses given the small sample size, but that just speaks to the importance of finding a system that suits your working style. Personal productivity is, as the name says, personal; what works for me won’t necessarily work for you. Despite the variance, there are a few generally applicable takeaways. The first is to develop a sense of what’s important in your work and to focus on that. Develop a strong sense of prioritization, and leave yourself enough space to work on the important stuff. The second is to use flexible tools to get things out of your head. Come up with a system that works for you that externalizes all of the stuff that you’ll forget about, stick to it until it needs refining, and schedule time on the calendar for the time sensitive stuff. Lastly, come up with a way of dealing with incoming requests that doesn’t cause you to have to context switch continuously. Avoid actively looking for incoming requests, don’t feel beholden to every errand that you’re asked to do, have a means of pushing back when a request doesn’t actually seem urgent, and don’t context switch just because you have an unread Slack DM. Those three simple takeaways should help your productivity tremendously if you’re not already doing them. If I were going to put it in a catchy marketing slogan, it would be something like “prioritize, externalize with flexible tools, and triage effectively.” Then again, I’m not trying to sell you anything.