Right now, I'm fortunate to be contracting at a tiny organization with extremely high trust. This meant I was able to pitch an offbeat idea:

I could bill for two types of hours:

• High productivity hours.
• Low/medium productivity hours.

I’d get paid roughly twice as much for the former.

This is something that obviously wouldn't hold up under a scaling organization, and even at our tiny size, we started with an assumption that "in 3 months, Goodheart's Law will probably have distorted the thing beyond usefulness". I think it’d only ever make sense for an employee to opt into, rather than an employer to expect. (I’m actually a bit worried about posting publicly about it, because even the prospect of it becoming a common thing might have weird consequences. But I think on net it’s a neat thing worth talking about)

We're one month in, so... still a chance of this getting distorted. But I currently bet you could maintain it indefinitely in non-scaling organizations where everyone trusts each other (and themselves) at least reasonably. At the very least, I think it's worth doing for at least a month, to a get a sense of how you work.

In January, I worked 75 low/med hours, and 25 high productivity hours. (I took a week off, and I generally work 5ish hours a day)

The payment rates are such that the average of them is approximately what I’d normally get paid (I think the net result of this has been somewhat less payment for me, since I ended up doing a lot more low/med hours than high productivity hours. But I still think this is net positive for me from a “gain more information about myself and grow more.”)

High Productivity hours are fuzzy, and sort of left up to me, but some factors going into high productivity hours:

i. My supervisor and I have to agree that a thing is The Most Important Thing.

This is the straightforward, non-weasel-out-able part, and why I think is most likely to be useful in the longer-term. It's easy to get distracted by things like "make a UI element look prettier" or "fix some random small bug that's annoying me, but isn't the most important thing" or "talk at meetings", none of which are "actually get the highest priority thing done".

Incentivizing the latter seems worth doing.

ii. High product hours should aim for "deliberate practice"

The original pitch came from a background conversation on arranging the org around deliberate practice - what skills did we each want to really excel at, and how could we get there? Evidence suggests people can do deliberate practice up to 4 hours a day, and that you should be straining against the upper limit of your skills, pretty much the entire time.

That said, it’s hard to make formal payment rules around deliberate practice since it’s vague and hard to enforce, so this is ended up being more like “the intended spirit of the law, to periodically check in on”, rather than an explicit rule.

iii. Practicing Duration Calibration

However, even if it's unclear if I'm deliberate-practicing *at programming*, an additional thing I do is use my Task Duration Prediction spreadsheet to predict how long the task will take (how many minutes, upper and lower bound). This at least forces building the skill of "predict how long things will take".

During the first month, I failed to do this consistently. But I recently updated my spreadsheet so that if I try to enter “productive hours” without having done time estimation, I get an angry red cell.

iv. Coding vs Meetings

A thing I'm trying this month is splitting low/med hours into "coding" and "meetings" (they're still billed the same, but I think it's useful to keep track of how much of the day is actually spent coding at all)

That's all Folks

I don't really have a conclusion. Just thought this was a neat thing that was working out interestingly enough so far to be worth talking about.