1. The goal of the CODE framework is to help us create Intermediate Packets (IPs): small reusable deliverables.
2. IPs can be anything, from a meeting agenda to a common support question. Whatever you can reuse is worth refining and storing for later.
3. You can create IPs in minutes, but they can save you hours.
How often do you repeat yourself?
You get a question from a colleague or client, so you type up the answer or record a short video. It only takes a few minutes, so it’s no problem. Right?
Unfortunately, you're wasting time.
With a second brain, you should not be repeating yourself. By putting your ideas and insights through the CODE process, you have polished packets of knowledge that are ready for (re)use.
Here’s how to get more feedback while saving yourself a serious amount of time:
Express yourself using Intermediate Packets
When I first discovered the CODE framework, I thought the Express step was about publishing content.
Turns out, I was making it too big.
What we’ve done so far (Capture, Organize, Distill) accumulates in the Express step. With most of the work done, we can now create individual building blocks to do more knowledge work in less time.
So, what are these building blocks?
They are meeting agendas, checklists for completing recurring tasks, slide decks for pitching clients, etc. Whatever you can (largely) reuse is worth polishing and keeping for future use.
And because we've organized and distilled these pieces, they're easy to find so we're more likely to actually reuse them.
Tiago Forte calls these building blocks intermediate packets. They’re essentially mini deliverables in projects, with a focus on reusability for future projects:
The advantages of thinking in intermediate packets are that you become interruption-proof, increase the quality of your work through feedback, and save lots of time overall.
Here’s my experience with it:
An example of how I created an Intermediate Packet with a 10x time ROI
At Logseq, I'm responsible for support and regularly get the same questions. Instead of writing out the instructions every time, I progressively repurpose and refine them.
Here’s a concrete example:
The first time someone reported this error, I spent 5 minutes asking an engineer how to solve it. I sent an email back to the user and got confirmation the solution worked.
As more people ran into the issue, I stored the steps in our team knowledge base for easy copy—pasting:
Some people asked follow-up questions, and an engineer chipped in, so I refined the steps:
Once we implemented a proper support system with templating options (Plain, highly recommended), I added the snippet as a template and can now send it within a second:
Finally, after all the feedback, the resulting product is in the Logseq Sync manual (which is nothing more than a collection of intermediate packets I produced while providing email support).
Writing down the steps, refining them, and publishing them in different places probably took only 15 minutes, spread over several support work sessions.
The flip side is that support volume is down, and I can answer the question via email in seconds, already saving hours.
The key is that I didn't invest these 15 minutes upfront; I took an existing intermediate packet and refined it over time, and each time made it easier to access/reuse.
Your turn: What Intermediate Packet can you create right now?
As I’ve shown, you can turn the most mundane knowledge into reusable assets that help others and save you time.
So ask yourself:
What is one thing I do repeatedly that I can make easier for my future self?
It could be a little piece of “how-to” content, as I do for Logseq, or a checklist for something you must do regularly (for example, that tax return coming up).
Please comment or email me with any questions or suggestions for creating intermediate packets.
I hope to read from you!
Just-In-Time PM #4: Intermediate Packets
(4 minutes reading time)
If you want more examples of intermediate packets, I recommend reading this article by Tiago Forte (who coined the term). And if you’re interested in “just-in-time” project management, this whole series is worth studying.