Skip to content

Instantly share code, notes, and snippets.

@matthiasr
Created September 14, 2022 18:42
Show Gist options
  • Save matthiasr/64efa398f61b5abfbeae36ce274130d0 to your computer and use it in GitHub Desktop.
Save matthiasr/64efa398f61b5abfbeae36ce274130d0 to your computer and use it in GitHub Desktop.
On 20% / self allocated time

20% time is a buffer against many kinds of process failure. If your planning is perfect, you can always exactly predict what the costs and benefit of future work will be, and how long everything takes, you don't need it. If your process is perfect, you can perfectly line up every tooling improvement, every product experimentation, every tech debt repayment, every personal development investment, at 100% utilization.

But you can't. Sometimes you can't really formulate how something will improve productivity in the future, what feature your product has been missing, which blog post is the one that each engineer must read. 20% time acknowledges that you're only going to be right about 80% on all this – and that there is value in having slack for the other 20%.

This time becomes a buffer for planning emergencies (because let's be real, sometimes planned work spills over into it), for exploration that doesn't make it into a roadmap until the exploration has already happened, for productivity improvements that you feel in your bones (or your daily frustration) and just want to fix. By providing a 20% buffer where the normal prioritization is suspended, you allow yourself to do an 80/20 on planning accuracy as well, cutting down the time you spend on developing the perfect plan to a much smaller time to develop a good-enough plan, and to develop the inputs into that plan. You hand a chunk of capacity from formal process to engineers' intuition to do what they feel is the best thing to do without having to justify it in detail, and thus leverage their expertise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment