Managing your time

When you become a senior member of your team, you run into a problem, the problem of time and focus.

Because of your expertise and experience, people rely on you for guidance. So you need to talk with them, review their documents, review their code, provide feedback. You get a pile of code review requests, and are invited to a ton of meetings.

Soon you are no longer doing one of the things you love best, which is actually getting stuff done, being in the code, building things. And this also starts to make your value erode, as you are no longer in touch with the reality of the code.

The other challenge is, how do you decide what to focus on, what to give your time and attention to, when your time and attention have become really valuable both to yourself and others?

I haven’t perfected this, but I wanted to offer some approaches that have worked for me.

First of all, you need time to focus. I block off two to three hours every day. I mean, really block off. I mark myself as “Out of Office” and Google automatically declines all meetings. These need to be blocks of time, because that allows you to focus.

You have to do this, and you have to be firm about this. Some exceptions always occur, but you get to decide what those exceptions are, not let them be handed down to you by whimsical coworkers grabbing your time like hot donuts.

I then use the principles of lean and agile to decide what to work on and how to work on them. I recently read this great book The Principles of Product Development Flow by Donald Reinertsen. This book provided a wealth of data and math supporting key lean and agile principles. I have used principles from this to help me manage my time

First of all, I try hard to maintain a Work In Progress (WIP) limit. If you have too many balls in the air, none of them get done, and you spend all your time context switching. To me that means working with myself and my manager to decide what I want to focus on, and what needs to wait or be delegated. And yes, letting go of control and delegating is super important!

Secondly (this is actually the one thing I learned and took away from Getting Things Done), write everything down. Don’t try to keep it in your head. Then you can take a step back, take a look, and prioritize, and then do one thing at a time.

I use cost of delay to prioritize my daily backlog, using Weighted Shortest Job First . This takes into account not just value, but time criticality, risk reduction, information value for a total cost of delay, and then you divide that by level of effort. For example, I know I want to get some coding done, that’s important, but I have to split it up into small chunks or it never makes it to the top of the list. Which basically drives me to deliver value in small batches. In terms of coding, I time box an hour of coding every day or so and make serious progress while still getting to my other responsibilities.

I put this all into an Airtable. You can also do a spreadsheet but I wanted to try out Airtable.

To prioritize my tasks, I assign relative values to Business Value, Time Criticality and Risk Reduction (Risk Reduction is actually Risk Reduction *or* Information Value). The “total cost of delay” column is a sum of these three values. I do this really quickly, I try not to think about it too much.

Then I assign a relative value for Level of Effort, essentially points.

The Priority is calculated as Total Cost of Delay / Level of Effort. So something may have a high cost of delay, but if the level of effort is really high, it gets a lower priority. This forces me to break things down into smaller tasks. For example, you see two tasks “spend an hour coding” and “spend an hour learning Spaceman.” If it was just “learn Spaceman” (which is a very large project) it would have a massive level of effort and go way to the bottom.

I also regularly prune my todo list. A long list has a tail that will never get done — it’s better to admit it won’t get done rather than just let it sit there. Thta’s particularly important if someone is waiting on this — better to let them know it’s just not a high priority so they can either let it go or escalate. That’s another agile principle — long queues cause long delays and high variability.

I also review this backlog with my manager in our one-on-ones to make sure we’re both aligned on priorities.

With the focus time each day, maintaining a WIP limit, writing things down, and having a well prioritized backlog with small incremental deliverables, I am finding myself happy with a good balance of stuff I’m doing and stuff I’m doing for others, and feeling that what I am doing provides the most value for both myself and my company…