Work in the open. Be genuinely useful. Let the work speak.
This document captures the communications approach for Future Debrief — not a marketing plan, but a way of sharing progress that respects the audience and builds trust.
Kathy Sierra: Don't promote the product. Help people imagine being better at what they already care about.
The audience — DSTL scientists and analysts — want to:
- Deliver insights that influence real operational decisions
- Be recognised for their work
- Build tools and capabilities others rely on
- Be the expert others consult
Content should show them succeeding at these things. Future Debrief is the means, not the message.
Trusted colleague, not vendor.
Ian has worked with DSTL for years. The relationship is collegial, not commercial. Content should feel like a peer sharing interesting progress, not a supplier pitching services.
This means:
- No sales tactics or persuasion techniques
- No manufactured urgency
- No calls to action beyond "here's the work, have a look"
- Genuine enablement, not strategic influence
| Channel | Purpose | Cadence |
|---|---|---|
| GitHub (home) | Where the work lives. Canonical source of truth. | Continuous |
| GitHub Pages blog | Progress posts, milestones, vision pieces | When there's something worth sharing |
| Amplification to professional network | Points to blog posts | |
| YouTube | Video demonstrations, walkthroughs | When visuals add value |
GitHub is home. Everything else points back to it.
Content serves one of three purposes:
Evidence that the project is alive and moving. This is where most content lives now.
- Progress posts showing what got built
- Problems encountered and solved
- Decisions being made
Evidence that the platform is substantial. Only claim this when earned.
- Feature parity milestones
- End-to-end workflows working
- Quality and reliability evidence
Imagination fuel — what readers could do that they can't today. Use sparingly until Tracks 1 and 2 support it.
- Mockups of future capabilities
- Aggregate analysis possibilities
- Python extensibility scenarios
Current phase: Primarily Track 1, with Ian's existing credibility carrying occasional Track 3.
Worth sharing:
- What was built, concretely
- Problems encountered and how they were solved
- Decisions and trade-offs being considered
- Uncertainty about what comes next
- Interesting technical details
Not worth sharing:
- Routine commits without narrative
- Plans without progress
- Hype without substance
See .claude/agents/media/content.md for detailed guidance on:
- Voice and tone
- What to include and avoid
- Post templates by type
- LinkedIn formatting
Key rules:
- First person, conversational
- Lead with substance
- Include problems and uncertainty
- No superlatives or marketing language
- End when the content ends
No fixed schedule. Publish when there's something genuinely worth sharing.
Natural rhythm tends toward:
- Monday: Planning posts — what's coming next (invites feedback before implementation)
- Friday: Progress posts — what got done
But don't force content to fit a schedule. Silence is better than filler.
Invite curiosity, don't solicit engagement.
GitHub Discussions is the feedback channel. Link to specific discussions when there's a genuine open question — not as a generic call to action.
Let readers choose to engage. If the work is interesting, they will.
Not impressions, followers, or engagement rates.
Success is:
- Scientists imagine themselves using Future Debrief
- Technical leadership sees strategic value
- Organic conversations happen without prompting
- When collaboration discussions come, people already understand the project
- Not a marketing funnel
- Not a content calendar to be filled
- Not an influence campaign
- Not a way to generate leads
It's simply: do good work visibly, be available when people are curious.