Stream of consciousness, Sept. 26th, 2025
As someone with managing responsibility, you always have more to do than you can potentially do. Your day does not end when all your tasks are completed, your day ends when you decide you had enough.
My day always ends when Iām tired and ready to go home, not when Iām done. I am never done. Like a housewifeās, a managerās work is never done. There is always more to be done, more that should be done, always more than can be done.
Andrew S. Grove, High Output Management
This means we cannot do everything that there is to do in a given day. We can do a few things, but the vast majority will not be done in a day. They might stick around so we can do them the next day, but the next day there will also new things be coming up.
What to fill our days with is an important question. Theoretically, there are many approaches to that, but in reality we want to work on the thing that is most important, given there is no other thing that is more urgent and also somewhat important.
The fun thing is that things seldomly come with a label. You don't really know the importance and urgency of something when you come across it and figuring that out in a reasonable timeframe with a decent error rate is one of the core traits of an experience manager in my opinion.
Until you have the experience to better make these calls, there are some tools that are helpful that help categorizing work. Those categories can give a good indication on the importance of the work. One of those tools is categorizing work in leveraged and un-leveraged work.
The concept is simple: If you look at some piece of work that you could be doing, you ask yourself what will happen if you finish that work, what will be the outcome? Will it just be that piece of work being finished? That's un-leveraged work, the input-to-output ratio is one to one. Writing code is usually one of those un-leveraged activities: You write the code and the output is the code. In contrast, think about giving someone constructive feedback: You may prepare yourself for a bit and then have a thirty minute conversation. But what you get out of this is not just the 30 minutes talking to someone. If done well, they could be improving to the better, increasing the overall output of the team, maybe even taking this to heart and giving more constructive feedback to other team members, who in turn grow. Highly leveraged work: You put in an hour but get back much more.
I did not pick those two examples randomly, by the way. As a new leader who came out of an IC role, I often find myself doing "snack work":
Itās the low-effort, low-impact work that can kill you, because itās so attractive. Hunter refers to it as āsnackingā. It feels rewarding and can solve a short term problem, but if you never eat anything of substance youāll suffer.
Especially when faced with the two options above, reverting back to just fixing one thing quickly in code can be attractive. Giving feedback is hard and uncomfortable. I really don't want to be in that situation for 30 minutes. But if I'm not, I'm working on the wrong things. Essentially, I'm letting my team down in my role as a manager. Am not doing my job properly.
There's another angle to snack work though. It's almost like a small break, a nice and easy dopamine hit between the big and important things (that often have hellish long feedback loops). Will Larson writes about this:
Itās ok to spend some of your time on snacks to keep yourself motivated between bigger accomplishments, but you have to keep yourself honest about how much time youāre spending on high-impact work versus low-impact work
We should remember we're all just humans and even if we strive to do our best work, we can only do our best work when we're not broken. If an hour of low-impact work every now and then keeps us from breaking, I think this is a very fair tradeoff to make.