Creating a global content presence for developers

Context

I was a copywriter turned Editorial Manager and Content Manager for the GitHub Blog. As Content Manager, I managed the blog pipeline as content was drafted, edited, and published through GitHub or WordPress. I ghostwrote or edited almost every post in 2018 and 2019, and wrote content and supported launches through the Microsoft acquisition, GitHub India, the Octoverse reports, the GitHub Sponsors expansion to Malta and Cyprus, and more.

When I joined, GitHub was already the well-known and beloved platform for developers of all sizes. Within a few months it grew exponentially and completed its acquisition by Microsoft. We had to consider the volume of supporting content for GitHub and Microsoft, and elevate our communications and processes to match the next stage of the company: auditing processes for efficiency and resiliency, evolving communications for even more diverse audiences, and lowering the barrier to collaboration between companies.

The goals: help developers contribute content without it going stale in a backlog, with a way to review drafts, share feedback on time, and prioritize and schedule requests; make processes that scale to a larger volume of requests and editors; and keep the approachable, educational, and supportive voice the community knows and loves.

The work

Remembering our roots while we grow

Because of GitHub’s beloved brand personality, I wanted to keep the familiar, fun tone but elevate it to complement Microsoft’s style and content. That meant auditing and reviewing everything from content contribution processes to brief templates, data analysis, transition plans, ghostwriting, and much more.

Audit and goals

Most of our audience fit into five levels, from “never heard of GitHub” to “super fan or employee,” so we could tailor campaigns to each level of GitHub experience. I clarified content through editing and ghostwriting, often as suggested changes in pull requests, to support developers regardless of their experience.

Five audience levels: never heard of GitHub, heard of GitHub, uses or has used GitHub, needs GitHub, and super fan or employee

Suggested changes on a Security Lab blog post pull request

Research and a brief template

Regular audience research kept us proactive with communications, which mattered even more with the new audience we’d inherit from the Microsoft acquisition. Process should help creativity and collaboration, not hinder it: not every piece can be templated, but a blog brief template gave anyone the important details at a glance.

A research plan for defining personas and auditing existing content

A blog post brief issue with title options, excerpt, publish dates, categories, and tracked edits (author redacted)

Feedback and data

Feedback is a gift. Clear guidelines and “lanes” for constructive feedback, from the kickoff call to the retrospective, were essential to resolving problems. With Looker, Datadog, and more, we could make bets on the kinds of content that would help our audience, depending on the GitHub service they used.

A premortem issue template with sections for the problem and next steps

Expanding processes

As we scaled, our processes had to evolve too. I regularly collaborated with other teams on processes that fit their resources and priorities, like tiers of event campaign options for social media.

An "Event Campaign Options" page describing Tier 1 social coverage for large events

Jekyll to WordPress, and beyond

We tried different tools to learn what made sense next. We were publishing blog posts with Jekyll on GitHub, and I supported and completed the transition to WordPress. The migration left us with a CMS instance just for the blog, and the chance to evolve it into the beautiful, accessible, content-focused blog it is today.

The "¡Hola! Our help documentation is now available in Spanish" blog post

WordPress Site Health status for the blog

Editorial calendars and analytics

When I started, the editorial calendar was a few tasks in a GitHub repository. I used Asana and then Airtable to build a “living” calendar so everyone could see the pipeline at a glance. At the height of GDPR, we had to forgo analytics and go with our instincts and data points from other departments, which meant connecting with our audience to understand their needs.

The Airtable editorial content calendar, with post titles, draft status, and publish dates (names blurred)

Notes on which posts Hacker News, Reddit, and Stack Overflow sent the most traffic to

Transition plans

When I moved from Editorial Manager to Product Manager for GitHub Sponsors, I wanted to set the next person up for success. There were many moving pieces and little documentation about “all things content,” so I wrote a comprehensive guide to managing, supporting, and contributing to the GitHub Blog.

A section of the blog guide explaining how to review repository permissions