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?⁴ 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.”¹

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:

• IC (individual contributor) work This includes writing code, reading code, reviewing code, debugging, testing, standing around a whiteboard talking code and design, writing design docs, reviewing design docs, and so on. The core stuff that is the practice of software engineering.
• Mentoring and Teaching This includes ad-hoc mentoring, standing one-on-ones², and simply having time open on my calendar for the “do you have a few minutes to chat about my career?” conversations with folks near me. I also tend to put things like tech talks into this bucket.
• Strategic Stuff What are we doing next year? What do the next five years look like? Where are the industry trends going? What are the new things our customers are thinking about that seems like it could be big? What skills am I going to need? What skills are the folks in my organization going to need?
• Rhythm of Business This is the day-to-day. The way it looks has varied a lot over my career (more business reviews, less sprint planning), but includes everything involved in getting hands-on with the business. This includes the technical side (operations reviews, security meetings, looking into tickets and metrics, that kind of thing), money side (business reviews, etc), and people side (talent reviews, interviewing, and so on).
• Learning I put aside time during my work day to learn things, including reading papers, implementing algorithms I think are potentially important, reading books, and similar activities. This often feels hard to justify, but isn’t - over time I’ve gathered a good set of success stories of business value of me spending my time this way³.
• Customers I like talking to customers, and some of them like talking to me. Customers are the most important thing to stay connected to.

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.

Footnotes

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.

Other Posts

• 17 Dec 2024 » Snapshot Isolation vs Serializability
• 06 Dec 2024 » DSQL Vignette: Wait! Isn't That Impossible?
• 05 Dec 2024 » DSQL Vignette: Transactions and Durability