Beeminder Forum

"urgency load" metric

I’ve been playing with a metric to capture how much I’m skating the edge on my goals.

I have a good number of goals, usually around 60, and I have found it easy to lose track of progress. When I feel like Beeminder is breathing down my neck, I look and see mostly green goals, sit down and do work for an hour, and I look at my dashboard, and… it’s still mostly green. When I’m already in a grumpy mood, I need more basic feedback than “dates changed on a list of 60 items”.

I use Beeminder primarily as a way to balance my life, rather than to focus on a single “life’s work”.

I’ve rigged something up for me, and I’m ready to talk about it in public :slight_smile: Now, when I work on my Beeminder stuff, I can look at my urgency load before and after and see my progress super easily.

@dreev and I were talking about it recently, and he said:

The idea of Urgency Load is to construct a single number that captures how edge-skatey you are across all your goals. One way to do that would be to sum up how many safe days you have on all your goals. So the higher the number, the more safety, the better. But it’s not great how adding more edge-skatey goals adds more total safe days across all your goals. More goals means more (potential) urgency; that shouldn’t improve the metric! So Adam cleverly flips it around: Every day of safety buffer less than 7 is a day of urgency. Sum those over all your graphs and you have an urgency metric that you want to keep as low as possible. A beemergency adds a full 7 to your urgency load, having 6 days of safety buffer on something adds 1, etc. And adding new goals can at best leave your urgency load unchanged, if you keep them at 7+ days of buffer.

In short:

\text{urgency load} = \sum_{g\in \operatorname{goals}} \max(7-\operatorname{buf}(g), 0)

where \operatorname{buf}(g) is how many days of safety buffer a goal g has.

Thoughts? @dreev and I came up with “urgency load” which may not be the most attractive name but it seems to work.

4 Likes

Adam also had the idea to normalize it so that 0% would mean that every goal has at least 7 days of buffer (what we can call fully safe – see #15 of blog.beeminder.com/obscure) and 100% would mean every single goal is red.

It might be more understandable that way but I think less mindable. With Adam’s metric you know exactly what to do to get your urgency load down by 1: dispatch a beemergency or do the daily amount due on any goal (that isn’t already fully safe).

PS: Not to mention that normalizing like that ruins the property that more goals = more urgency. Actually I bet Adam had a less extreme normalizing in mind. In any case, I like the above argument for not normalizing at all.

1 Like

I was actually thinking of just dividing my number by 7. A Beemergency costs 1, and a goal due tomorrow is worth 6/7ths. I still kinda like the raw 7 for Beemergency better.

Another thing I want to write: I like that adding new goals with lots of safety buffer doesn’t reduce my urgency. Other options that we’ve talked about suffer this problem, and they don’t map to the “Beeminder breathing down my neck” feeling.

3 Likes

This sounds super cool. How long have you been minding this metric? Are you using the metric goal to actively change behavior, or is this more of a tracking goal?

2 Likes

I’ve been beeminding emergency days since January, and urgency load since June.

Regarding behavior changer vs tracking… both, really. I’ve been trying for years to build a yes-o-meter, to help me support decisions for when to take on more things vs cut things off. This is quite good for that, so far.

3 Likes

How do beemurgencies on this goal tend to go? Do they occur a lot at midnight based on your other goal deadlines?

1 Like

Ah, I see your question. The road is far enough away from the goal that having an emergency on this goal isn’t really a possibility right now. I’d like to get there, but I don’t even have a good intuitive grasp of what rates mean with regards to life busy-ness yet.

2 Likes

Thinking about this, I immediately thought I’d want a normalized metric - adding more goals for me doesn’t mean I’m creating more capability (there are still only 1440 minutes per day), it just means I’m spreading the capability more thinly.

However, I guess it perhaps depends what your goals are: if they are externally driven metrics, then it is indeed perhaps appropriate to think of it as “urgency load”, which perhaps shouldn’t be normalised as it genuinely reflects more (external) commitments. For me they’re internally created goals, so it’s more about “on average, how close to the edge am I”, which should be normalised.

This is a nice metric to track, but I have trouble seeing it as a good actionable goal. For any slope that makes you work to achieve the goal, you are likely to bump a bunch of goals just past 7 days and then the day turns over and you have a lot of goals that you need to deal with in order to not fail beeminder - pretty similar to the reason that road skating gets stressful.

I sometimes play a game of try to get at most one goal due by tomorrow, at most two goals by the day after, etcetera. It does set me up pretty well for having to do things all the time but always having the choice of doing a lot of one goal or a little of several (more flexibility without more leniency compared to having a single date in the future that you allow X goals within). But similarly, I can’t think of a metric for it that it would work out to beemind. (A way to generalize this into a number instead of just yes/no is to ask the farthest day in the future - or most recent day in the past - the stair pattern can start. But I don’t think that number is good for beeminding.)

2 Likes

If you’re good with it, I’d love to see your graph.