Marc's Blog

About Me

My name is Marc Brooker. I've been writing code, reading code, and living vicariously through computers for as long as I can remember. I like to build things that work. I also dabble in machining, welding, cooking and skiing.

I'm currently an engineer at Amazon Web Services (AWS) in Seattle, where I work on databases, serverless, and serverless databases. Before that, I worked on EC2 and EBS.
All opinions are my own.


My Publications and Videos
@marcbrooker on Mastodon @MarcJBrooker on Twitter

How Do You Spend Your Time?

Career advice, or something like it.

Some people who ask me for advice at work get very long responses. Sometimes, those responses aren’t specific to my particular workplace, and so I share them here. In the past, I’ve written about writing, writing for an audience, heuristics, and getting big things done. This is another of those emails.

When we spoke, you mentioned that you weren’t happy with the things you were getting done. You thought you were productive, and getting a lot done, but they weren’t the things you (or your manager) thought were most valuable for your project and team. You’re busy, you’re productive, but it doesn’t feel right. It’s a problem I’ve faced before, which I think I’ve mostly solved for myself. Here’s some thoughts on what worked for me.

I set myself a time budget. Five or six themes, and an explicit goal for how I should divide my time between these themes. Then, over the long-term (weeks and months), I hold myself accountable to approximately spending my time in the way that I planned. I also, twice a year or so, calibrate with my manager that they agree with this time budget, and adjust accordingly.

The exercise of setting the budget itself is the most valuable thing. It requires me to really think about what I need to do to make my teams and projects successful, the way I balance between the short- and long-term, and what I want to get done over time. This seems to be the most common mistake I hear from folks: they’re not happy with how they spend their time, but haven’t thought at all about what success looks like, about what would make them happy. Even if you don’t act on the results at all, I recommend you spend some time thinking about your themes and how you divide your time between them, then talk to your manager about it in your next one-on-one.

The next step is to follow your budget. Here, I think it’s useful to be flexible in the short term (stuff comes up, the cycle of your business and projects demand different things, people need help, etc), but rather stubborn over the long term. If you aren’t following your plan over the long term, why not?4 Is it the wrong plan? If it’s the wrong plan, change the plan. If its the right plan, deeply understand why you can’t stick to it.

I always remember the observation of a very successful soldier who said, “Peace-time plans are of no particular value, but peace-time planning is indispensable.”1

Sticking to your budget requires saying no. You’re a capable person, and a lot of people know that, so lots of folks are going to ask for your help with stuff. Sometimes, you’re going to need to guide them elsewhere. Or just say no outright. That doesn’t feel good, but if you always say yes to stuff that isn’t that important you can’t be surprised when you don’t get important stuff done.

Some Caveats

There are some ways that I see folks taking this kind of thing too far. One of them is setting important in the wrong way: focusing on visibility, or trend chasing, or executive face time, or whatever. I haven’t found focusing on those things valuable.

Then, there’s the dirty work. The messy stuff that’s always urgent, and only sometimes important. Some folks get this wrong by always taking it on. Why didn’t you get this important task done? Because I was on this ticket, and that customer issue, and those on-call tasks, and so on. It’s super easy, in an operationally-heavy business like ours, to get into nothing but the details. That’s a trap. Going too far the other way is a trap too. As a leader, you need to be deeply aware of these tasks. You need to be hands-on with the most important ones. How can you expect to make successful changes to a system you don’t understand?

The other failure mode is losing control of your time. I spoke to a senior SDE the other day who was in 20 hours of planning-related meetings a week, every week, across multiple teams. What was weird about that is that he didn’t think he was adding much value in these meetings, his manager didn’t think we was adding much value, and his manager’s manager didn’t either. But they had all just drifted into that situation without explicitly talking about it. But nobody fixed it because everybody assumed that somebody else was doing it for a good reason. Sometimes, the only way out of these situations is to have a hard conversation.

My Themes

When I do this exercise, my themes tend to look something like this:

These buckets aren’t perfect, and not everything quite naturally fits, but most things do. I tend to tweak them over time.

The buckets aren’t important, and the edge cases are very much not important. What’s important is doing the exercise, and being explicit and thoughtful about how you spend your time. I find it valuable, anyway.

Beyond Myself

I tend to apply this pattern of thinking across the organizations I work with. The first step is encouraging people (both ICs and managers) to be thoughtful about how they spend their time, and encouraging managers (and other leaders) to be thoughtful and explicit about how they spend their team’s time. One conversation that I find particularly useful is just zeroing in on the IC work bucket. How big should that bucket be for the software engineers of each level in your team? How big is it today? Why are those numbers different? If the person manages managers, the conversation is doubly useful. Every time I have that conversation I learn something important, and often surprising. I highly recommend it.


  1. Dwight Eisenhower. The first time I read that, it was attributed to Richard Nixon, which would be pretty funny.
  2. Although I don’t do a lot of those. Over the years, I’ve found ad-hoc “can I grab some time on your calendar to talk about X?” mentoring much more effective, both as a mentor and a mentee, than the “let’s meet every two weeks at this time” style.
  3. To pick an example, a couple months ago I needed to review some work of a time building vector storage features, and didn’t know if I could ask smart questions. So a read a handful of papers, implemented some of the key algorithms and data structures (PQ, HNSW, an LSH variant) and felt like I was much more able to ask the right questions.
  4. There’s this idea of revealed preference in economics, which is the theory that looking at what a consumer buys can reveal their real utility function (rather than the one they say they have, or even think they have). I don’t know if its good economics or not, but it’s a useful lens on how you spend your time. You say you love a salad, but always end up ordering the burger.