Posted On: 2020-09-21
While I have mentioned it in passing once or twice before, I thought I should write a bit more concretely today about the concept of a content backlog: what it is, how it helps, and why it's a bit of a problem that I have (again) burned through mine.
When delivering content (writing, art, comics, etc.) on a regular schedule, one doesn't necessarily need to create the content immediately before delivering it. Indeed, it is often beneficial to have content complete significantly in advance of the deadline, as this creates the opportunity to potentially rework or polish the content beyond what one might do while creating content just in time for delivery. A natural extension of this idea is to keep completed content in a backlog: one works not to meet deadlines, but instead to stay a certain number of works ahead of the deadline. Completed works are then collected together and queued up in the backlog, so that they can be delivered at the appropriate deadline. Importantly, items in a content backlog are complete: no additional modifications are required*.
Using a content backlog provides much of the same value as using a cache in programming: by decoupling the demand for a resource (the deadline) from the process of creating the resource, one can schedule that creation much more optimally. Thus, a content creator can control their creation schedule*, allowing them to be both more efficient and more comfortable in their ability to fit the schedule. Furthermore, by keeping a substantial enough backlog, one can even overcome unforeseen (yet inevitable) delays, such as those caused by lapses in health or other personal/family emergencies. What's more, by pairing together a content backlog with a sustainable creation schedule, one can potentially release content on with a delivery schedule that might seem impossible**.
Personally, I have used a backlog to fairly limited effect so far: when I anticipate delays I use it to queue up a few extra posts, but most of the time I am instead authoring content close to (if not on) the deadline itself. Part of this is the nature of these posts: they are as much a catalog of my progress on my project* as anything else. Another part is the deadline being fairly lenient: a post usually takes between half a day to a day to write, so I am often able to recover within 24 hours, even if something completely unexpected comes up. Lastly, and perhaps most importantly of all, these posts are a lower priority than the actual work on my project: thus, if I find myself with spare time, I am far more likely to put it into furthering the project than building out a sustainable backlog.
All those things coalesce together to make, frankly, today's blog post. Although I am fortunate enough to be in a position where I can write a post today - I am riding on a wave of unforeseen delays, spending my time explaining backlogs where - had I been using them more effectively - I would be doing something else entirely.