How Discourse Is Becoming a Community of Writers
We build software around the idea that long-form conversation beats chat for real thinking - so we started asking why all that thinking was staying inside the company. Here's what happened when we challenged everyone to write publicly.
Writing is how we think at Discourse. Figuring out what you actually believe, putting it somewhere other people can push back on it, and seeing what survives is the core of our work, as an open-source company and as individuals. It’s been a part of our DNA since we started; our co-founder Jeff Atwood has talked extensively about why writing matters, and we’ve always taken that to heart.
We build forum software. That’s our whole thing. Our product was created around the idea that long-form, searchable, threaded conversation beats chat for real thinking. So we started asking ourselves: if we believe that, why aren't more of us writing publicly? Why does all that thinking stay inside the company?
That contradiction bothered us.
Like many companies, we had one or two designated "voices" in marketing, responsible for publishing anything external. Efficient, sure, but it narrowed the company's perspective. Our engineers, PMs, designers, and support staff hold real expertise, but without a strategy to put that knowledge out into the world, it was siloed.
To fix it, last year we started an experiment to become a community of writers - challenging everyone, not just the marketing team, to take our internal debates, our projects and our passions and push them out into the open…
Where we started
Most people haven't written publicly since school, and common fears come up fast: "I'm not a writer," or "Who would care what I think?"
Many get stuck waiting for ideas to be fully formed before putting anything on the page. Imposter syndrome adds another layer: "I don't know enough to have an opinion."
Confidence grows through practice. Internal writing provides a low-pressure starting point: share drafts in a safe space, get comfortable, then move toward public articles. Breaking the process into small steps makes publishing approachable.
The blank page is intimidating when people are expected to come up with ideas from nothing. What works better is starting with a conversation. Interview-style development helps get ideas flowing and turns rough thoughts into something draftable. Giving people frameworks makes it easier than telling them to "write something." Once we started removing these barriers, people actually wanted to publish.
Building the infrastructure
We use our internal forum for drafts, creating a collaborative space to practice before anything goes public. Marketing provides editorial support, shaping and refining pieces while keeping the author's voice.
For publication, we use our Ghost blog and a cross-posting strategy. A content calendar keeps a steady rhythm rather than sporadic bursts, and templates show what good writing looks like.
We've built a feedback culture where iteration feels like a positive, rather than a negative feedback loop.
Topics that work (and topics that don't)
Some topics don't work. Corporate speak, promotional content, political commentary, or hot takes rarely land. We use a simple test: Would I read this if I didn't work here? If not, the piece needs more substance or a stronger connection to real experience.
The sweet spot is real experiences + technical deep reporting, things people can only write from firsthand knowledge about their own domain. Writing about what you actually do, rather than trying to sound impressive, is what makes a piece worth reading. Personal perspectives work because they show how the team actually thinks.
Some of our best pieces have come from Discourse staff who are passionate about a topic close to their heart and have come to the editorial team for help fleshing it out and publishing it, and we welcome every single idea. Yes, we keep a schedule, but it’s a living document (actually, a living post on our internal Discourse forum!)
Different voices, different strengths
Each team writes differently, and the variety has been the best part of this experiment.
Engineers write about implementation details and architecture decisions. They explain why a system is built a certain way, what the trade-offs were, what broke along the way. Their posts go deep in a way that's hard to get from anyone else.
Design process content shows how we build products. Our piece on building Horizon let designers walk through their reasoning and how feedback changed the final product.
PMs share the philosophies and frameworks behind their decisions. These posts help demystify product choices.
Support and community teams notice patterns across customer interactions that aren't visible elsewhere. Sharing those observations in writing makes them concrete.
When our co-CEOs write about why we make certain decisions, it creates transparency and trust externally.
And support posts, drawn from helping thousands of customers, turn everyday experience into guidance that people actually use.
Editorial process checklist
We break the work into stages so nobody's staring at a blank doc alone.
Step 1: Topic identification and assignment
Step 2: Interview or outline development
Step 3: First draft (can be rough)
Step 4: Collaborative editing and refinement
Step 5: Review rounds as needed
Step 6: Publication and distribution
Overcoming common obstacles
Time is the biggest barrier. Writing can feel like an added task rather than part of the work itself. We've found that the best fix is integrating writing into regular workflows: turning real decisions and reflections into content instead of asking people to carve out extra hours.
Quality concerns and audience anxiety come up too. Many contributors wrestle with whether a piece is "good enough to publish." We encourage them to focus on helping one reader at a time. Usefulness matters more than polish. On the technical side, simplifying publishing tools has helped more than we expected.
Finding good subject matter is its own challenge. Writing regularly builds habit, and picking topics at the intersection of personal expertise and audience interest keeps the work authentic.
Cultural shifts we've seen
The writing culture has changed how we communicate internally. People explain ideas more clearly in async channels, which makes collaboration smoother.
Decisions get documented and stay accessible for future reference, which benefits new team members and prevents lessons from disappearing into Slack. Cross-team learning has improved, with everyone getting a better picture of what other departments are doing.
Externally, team members are building their own voices. Candidates see how we think and what the culture is actually like, which has been a real recruiting advantage.
Measuring success beyond pageviews
We track how many team members are publishing regularly and whether the content gets used. Community feedback tells us what resonates, and sharing real experiences strengthens customer relationships in ways that marketing copy can't.
What we're learning
- Consistency beats brilliance. Publishing regularly, even imperfect pieces, creates more momentum than waiting for occasional masterpieces.
- Collaboration matters. Few people can take an idea all the way to a polished article alone. Different perspectives make the content richer.
- Practice builds confidence. The more people write, the easier it gets.
- Authenticity wins. Real experiences land better than corporate speak. But people need scaffolding and encouragement to get there, and building that support is what makes a writing culture stick.
Challenges we're still solving
Bandwidth is a constant constraint. Team members are balancing writing with their primary responsibilities, and marketing can only support so many pieces at a time.
Consistency across different authors requires ongoing attention, and generating relevant topics takes real effort. Momentum is hard to maintain over years, especially when getting leadership to write against packed schedules is always a fight.
We haven't solved any of this, but naming the problems helps us plan around them.
If you want to try this
Start with a few willing participants instead of a company-wide mandate. Provide structure: suggested topics, templates, editorial support, examples of what good looks like. Let people practice internally before anything goes public.
Emphasize cadence over volume. And when leadership writes alongside the team, it sends a signal that people notice. We're still figuring most of this out ourselves, but the writing we've published so far has already outlasted thousands of Slack threads.