Most technical professionals do not have an idea problem. They have a retrieval problem.
The useful material already exists in project work: a decision that took three days to clarify, a failure mode that looked harmless in staging, a client question that exposed a hidden assumption, or a checklist that made the second implementation safer than the first.
The difficulty is recognizing those moments as publishable knowledge without exposing confidential details or pretending every lesson was a dramatic success.
Start with the decision, not the topic
“Write about AI agents” is too broad. “Why we evaluated the resulting account state instead of trusting the agent’s confirmation message” contains a decision, a mechanism, and a useful lesson.
A strong source note usually answers four questions:
- What were we trying to achieve?
- What made the obvious approach unreliable or incomplete?
- Which decision changed the outcome?
- What can another practitioner verify or reuse?
That is enough material for several post angles. One can explain the failure mode. Another can compare two approaches. A third can offer a checklist for making the same decision.
Separate evidence from interpretation
Before drafting, make two columns.
In the evidence column, record only what you can support: the system boundary, observed behavior, constraints, artifacts, and measured results you are allowed to share.
In the interpretation column, record the lesson: what changed in your mental model, which trade-off matters, and when the advice does not apply.
This separation prevents a common content failure. A model or hurried writer turns a reasonable interpretation into a personal achievement claim. If the source says “we added state verification,” the post should not quietly become “I built a system that eliminated failures” unless that result is explicitly documented.
Choose a post shape
Three structures work especially well for technical expertise:
The hidden system
Begin with the visible result, then reveal the less visible components required to trust it. This works for agents, automation, frontend performance, deployment safety, and attribution.
The decision contrast
Compare two metrics, designs, or operating modes that answer different questions. Explain when each is useful instead of declaring one universally better.
The working checklist
Turn a repeated review or discovery process into a short sequence. The value comes from the order and decision boundaries, not from making the list long.
Preserve the boundary of the lesson
Credible content says where it applies. “Retries improve recoverability when attempts are safe and independently verifiable” is more useful than “Always add retries.” Constraints make advice stronger because they let the reader decide whether the mechanism fits their situation.
Create several drafts from one source
Do not ask for three rewrites. Assign each draft a different job:
- Draft one diagnoses the problem for a practitioner.
- Draft two explains a decision for a technical buyer or leader.
- Draft three turns the lesson into a reusable guide, checklist, or evaluation question.
The topic may stay constant while the audience, argument, and structure change.
A repeatable source-note template
Keep this next to your project journal:
Situation:
Observed constraint or failure:
Decision made:
Evidence I can share:
What I cannot claim or reveal:
Who needs this lesson:
Practical next step:
Fill it in while the context is fresh. A precise ten-line note is more valuable than a vague plan to “create content later.”
The goal is not to turn every task into a post. It is to keep the decisions worth teaching from disappearing when the project closes.