Push distribution for known audiences + time-sensitive needs; pull distribution for unknown future audiences — deploy both for significant outputs
Use push distribution (direct delivery to inbox/channel) for known audiences with time-sensitive needs, and pull distribution (searchable repositories) for unknown future audiences seeking information over time—deploy both for significant outputs, not one or the other.
Why This Is a Rule
Push and pull distribution serve fundamentally different audience types and temporal needs. Push (email, Slack, newsletter) delivers directly to a known audience who needs the information now. The audience is identified, the timing is controlled by the sender, and the distribution is active. Pull (wiki, blog, knowledge base, searchable repository) makes information available for unknown future audiences to discover when they need it. The audience is unidentified, the timing is controlled by the seeker, and the distribution is passive.
Most people default to one mode: they either push everything (sending emails, posting in channels) or publish everything to a repository (adding to the wiki). But significant outputs deserve both: push ensures the known audience receives the information promptly, while pull ensures future audiences can discover it when they need it. A well-written analysis pushed to the team via email serves this week's decision; the same analysis published to the knowledge base serves next quarter's similar decision by a person who wasn't on the original email.
The "deploy both" instruction doubles the output's total impact: the push captures immediate value from the known audience, and the pull captures ongoing value from unknown future seekers. The incremental cost of dual distribution (usually just saving to a searchable location in addition to sending) is minimal compared to the doubled reach.
When This Fires
- When distributing any output worth more than ephemeral value
- When deciding between "email this" and "publish this" — the answer for significant work is "both"
- When good work disappears into email threads and is never found by people who need it later
- Complements Define the distribution plan before starting production — audience, channels, format, and timing are design constraints, not afterthoughts (distribution-first planning) with the specific distribution mode selection
Common Failure Mode
Push-only distribution: sending a valuable analysis to 5 people via email. The 5 recipients benefit. The 50 people who will face the same question next quarter won't find it because it's buried in someone's email archive. The work produced value once when it could have produced value repeatedly.
The Protocol
(1) For each significant output, identify two audiences: Known/current (people who need this now) and Unknown/future (people who might need this later). (2) Push to the known audience: email, Slack message, calendar invite with attachment, direct share. (3) Pull for the unknown audience: publish to wiki, knowledge base, shared drive, blog — anywhere searchable by people who don't know this output exists. (4) Title the pull version for searchability (Title notes with the natural-language words you'd search for, not abstract labels or jargon — search terms beat category names): use the words future seekers would type, not the project codename that only current team members know. (5) For low-stakes ephemeral outputs, push-only is fine. For anything with a half-life of weeks or more (Annotate each output type with its half-life (hours/weeks/months/years) — calibrate investment in durability and polish to actual lifespan), dual distribution is the default.