I’ve created a goal to require a minimum number of hours in focused ticket work at my job (meetings, for example, wouldn’t count). However, sometimes, due to circumstances outside my control, I cannot meet the goal. For example, two days ago our test environment was down all day and today I’ve finished all my tickets. Both days would leave me with fewer hours than my goal requires. Obviously that sort of thing isn’t predictable enough to schedule a break.
Do I just derail and take the loss? That hardly seems fair, since it wouldn’t be my fault, and the purpose of the goal is to cut down on letting myself get distracted, not to control the test env. Derail and call nonlegit? Except I hate how that makes my graph look. Put in data as if I got all my hours with a note specifying extenuating circumstances? I know y’all hate fake data, though.
Good question and good thoughts! A big disadvantage of @cgamer1’s option 1 is that it kinda violates the QS First principle. Hours of focused work is the most interesting, fundamental metric and it’s a shame to compromise on that.
I don’t think calling non-legit is so bad an option either, if the goal is dialed ambitiously enough that you do also have legit derailments sometimes.
Another option is to somehow get yourself to maintain enough safety buffer. Maybe a meta goal that requires a +1 every day and you get the +1 by topping off your focused work goal: getting it into the green or as close to green as you can until you run out of focused work to do.
This hasn’t come up very often for me, so my personal experience isn’t a lot of use, but I’ll drop it here anyway… I’ve used time-based goals for two things:
Work goals, where I’ve never had the problem of running out of stuff to do, because there’s always something on my plate that would benefit from me putting my hand to it. Part of that is perhaps that I’ve defined my goals broadly so that there’s always something I can do for them, and there’s something to be said for defining a goal that you know you can always make progress on.
Study goals, where the primary purpose is always going to be “sit down and spend time with my study material”. I have occasionally come up against walls there which don’t depend on me, like waiting to hear back from a tutor. One way I’ve handled that is having some leeway built into the goal, and the other is pretty much the same as above: find related work I can do.
I guess if my wife (who has worked in a ticketed system) came to me with this problem, I know their work environment and schedule (we both work from home) well enough to say that in their case, it’d be a great time to make sure no old tickets had been reopened, that all the 'i’s had been dotted and 't’s crossed, giving customers/coworkers a call to let them know about the progress so they know they’re forgotten, or for them to make progress on to-dos for older tickets that are taking time to fully resolve – stuff that can easily fall by the wayside in the quest to close close close incoming tickets. So depending on your work environment and whether you have those kinds of situations, that could also very handily be part of your definition of “focused ticket work”. (I’m guessing that’s not the case for specific-you personally, but this might be helpful to someone else with the same problem!)
OK, Support Czar hat on now for this one: adding fake data would definitely be very bad (we find that lying to Beeminder becomes more and more tempting the more you do it, and it would also make your charted progress meaningless as some percentage of it would be progress you never actually made). Normally, I’d say it’d be better to call non-legit by a long way (though we do see people who rely on calling non-legit a lot finding that it kind of dilutes the sting to always be crying off). We have a very firm principle of not wanting to charge you if it isn’t fair.
Calling non-legit a lot would usually be a sign that the parameters of the goal aren’t realistic in some way, e.g. the rate is more aspirational than realistic, and we’d probably suggest keeping a close eye on it for a bit and then setting your rate to the true average amount of hours you can do. That might be what having two such cases in a week means… or it might be that those two cases are really exceptional, it’s surprising they happened close together, and your rate is normally just fine.
As for what we’d call “a lot”, one rule of thumb we’ve mooted is “are you having more non-legit derailments than legit ones?” Like if someone’s asking support to fix 4 out of every 5 derailments, there’s probably something going wrong somewhere and they shouldn’t be leaning on the support team so much. In that case, it’s usually time to re-evaluate some stuff! If someone’s asking support to fix 1 in every 5 derailments, they’re probably totally fine.
To me, it does sound like the cases described would be non-legit derailments: you physically couldn’t complete the goal. So for these specific cases at least, I’d say call non-legit. Which in your case just leaves the problem of hating how it looks. Is there anything in particular about that you hate? Like is it just the red triangle, or is it the little jag in your bright red line? I might have some suggestions about how you can make that better for yourself, if you can share!
I’m not sure there’s a great solution here. The best I’ve got to is to record a fraction of the lower of available-to-work hours and the minimum you want.
So if say you have a minimum of 3 hours/day you want to work, if the work is available:
- you work 4 hours, you record 4/3
- you work 3 hours, you record 3/3
- you work 2 hours (but could have done 3 - there was enough work there to do this), you record 2/3
- you work 2 hours because there was only 2 hours of work available, you record 2/2
You can enter fractions in the Beeminder data entry interfaces, so this isn’t hard to enter. The graph slope is set to 1/day (or probably 1/weekday, if you are on a premium plan). You can find the actual hours worked by multiplying your total by (in this case) the 3hrs/day you targetted.
It’s not perfect. Here are a couple of niggles I can see:
- beeminder records as decimals, not fractions, so that can look ugly (but you can always enter the hours as a note on the data line)
- if you want to change your minimum per day, you have to make a mental note of this (or use the note field in the data entry)
Might be worth trying something like this!
Echoing @shanaqui’s answer of “design your goal such that this situation is impossible”: Obviously every job is different but for me, even if my corp vpn was dead and I couldn’t clone fresh code at all, there’s approximately infinite doc improvement, ticket updates, “hmm-one-day-i-should” lists to prune & refine, people to ping for updates on their work, &c, that I could spend time on and call it “focused ticket work” without any shred of uncertainty.
I’m not sure I agree with your rule of thumb; at the very least it should be constrained by time (i.e., 5 derailments over a year is different than 5 in a month).
I don’t like both of those things: the red triangle and the jagged line. It’s not really what y’all were going for, but I’m as motivated by that to avoid derailing as I’m motivated by paying.
Thanks, everyone, for the thoughts. I’ll mix and match and find something I can work with.
The idea is not that we’d ever say “you called not legit 10 times while you were sick, now you can’t do it again until you’ve derailed 40 more times to maintain your 1:5 ratio”. It’s more like “in the long run, on balance, are you crying off more often than you accept the charge? If so, something is wrong here.”
And sometimes the reason is that there’s something wrong on Beeminder’s side, e.g. there’s something buggy about the integration or about reminders.
Well, I’m not sure if I should tell you the things that mitigate that, then! But if you want to know and don’t think it will harm your motivation (particularly as part of it is fiddly): as long as you don’t make your goal easier in the present, you can smooth out just about anything using graph.beeminder.com, and the red triangle can be removed by editing the text of the “Recommitted at” datapoint (or deleting it).