Scaling developer content production at Snyk

How Snyk massively scaled content production through process automation and careful outsourcing.

Case study participant
Matt Jarvis
Director of Developer Relations
Founded in 2015, Snyk is a developer-first security platform that finds and automatically fixes vulnerabilities in code, cloud environments, and dependencies. From the pitch deck onwards, the Snyk founding team baked DevRel into the company’s strategy. Today, Snyk’s DevRel team is a part of the company’s Product organization, with 15 people under the leadership of Randall Degges.

The challenge

Like many similar teams, Snyk‘s developer relations team has a broad and varied remit. They speak at events, engage with local developer communities, contribute to upstream projects, and produce content. As a developer-first company, where direct developer engagement has been part of the strategy from day one, the DevRel program’s work is essential to building a pipeline of developer end users.

But not all DevRel activities are equal when it comes to proving return on investment. Although there was no question over whether the team’s work was valued, Snyk’s Director of Developer Relations Matt Jarvis was keen to create an initiative that would have an outsized impact. Crucially, it would also need to be easy to measure.

The opportunity

After discussions within the DevRel team’s leadership, it became clear that content production would meet each of Matt’s criteria. It would be easy to measure, cost effective to scale, and other companies such as Digital Ocean had previously proven its value.

Writing blog posts for developers was already a part of the DevRel team’s work. However, as one of many responsibilities, each developer advocate had time for one or maybe two blog posts per month. What Matt had in mind was on a much bigger scale. He wanted Snyk to become a search destination for developers.

“We already had an internal team getting good results from SEO targeted content. What we needed specifically for developers was a large library of content that was directly focused on answering their questions in a credible, authoritative way.”

The key to the initiative would be its ambition. It wouldn’t be enough to produce content about Snyk specifically. Instead, the team would build a content portfolio on topics adjacent to Snyk that were likely to appeal to the company’s target developers.

The solution

Snyk’s Head of Developer Relations and Community, Randall Degges, had already seen success with a similar initiative at Okta. Drawing on Randall’s experience, the team worked to create solution that would offer:

  • a repeatable model that would predict how many sign-ups each content piece should generate
  • improvements to distribution
  • credible content at scale.

A repeatable model

The team set a target of increasing developer website sessions by 300% within eight months. To get there, they’d first need to understand how content impacted sign-ups.

“We built quite a complex model that showed us how many sessions we could expect from a new post and, in turn, how many sign-ups we could expect from those sessions.”

But understanding that relationship wasn’t enough. An increase of 300% meant generating an additional half million website sessions from developers. That would require a completely new approach to distribution.

Improving distribution through SEO

Previously, when the Snyk DevRel team published a blog post they would promote it through personal Twitter accounts and similar channels. But to drive the traffic they needed, Matt recognised that search engine traffic was the only scalable way.

SEO had always been a part of the DevRel team’s distribution plan. However, optimising for search traffic was something of an afterthought that often took place after an article was ready to publish.

“Snyk’s internal SEO team had been advising us on how to rework the content we’d produced in order to match what people were searching for. For example, if a developer advocate had written a piece formatted as frequently asked questions, the SEO team might suggest we flip it to focus on something specific that people are looking for.

“However, to grow our web traffic we needed to bake SEO in from the beginning.”

For the new content initiative, each content piece started by asking how well it would serve the team’s target search engine terms. One tool they turned to was the Chrome Plugin Keywords Everywhere.

Credible content at scale

Although Matt was able to dedicate much of his time to the project, the rest of the DevRel team’s other duties remained. One or two articles from each person per month would not drive the desired uptick in traffic.

To supplement their own capacity, the team sought out specialist content agencies. Working with external resources enabled Snyk’s developer advocates to focus on content ideation and review, while outsourcing the bulk of the writing. Even if agencies were to take some of the strain, it was important to Matt that each developer advocate take ownership of the content they’d initiated.

“We have a very defined process where our advocate creates an outline and then works with the agency to see it fleshed out. It’s very much a collaboration, where our developer advocates are the subject matter experts who own the end to end process of creating a particular piece of content.”

Automating where possible

Process has been essential to bringing all those moving parts together. Not only process but automated process.

“When you have an awful lot of material moving through all the time, automation becomes absolutely critical. There are so many phases that a content piece pass through, with different external and internal stakeholders who each need to play their role. So we needed to industrialise this process.”

At the heart of that process are Asana and the low-code platform

“We built a tonne of low code automations that run on our Asana boards. At each stage of the production process, we automatically allocate subtasks that also exist in other teams’ boards. For example, each piece needs a review from the editorial team. We also need to prepare the social media team and the digital marketing team gets notified in case they want to build a campaign.”

This automation has given the Snyk DevRel team the confidence that their process is repeatable. But what about measuring its impact?

Measuring content’s requirements and impact

Modelling is central to how the Snyk team understands both resource requirements and the impact of its work. That commitment to repeatability has enabled Matt and his team both to:

  • create a reliable production timeline for each type of content and how it affects an individual’s ability to deliver on other types of work
  • forecast the average impact that a content piece should have on their goal of increasing web sessions.

To model content’s impact, the Snyk DevRel team identified three content types:

  • Deeper technical pieces that generate around a thousand sessions in the month after publication
  • Introductory technical content that generate around half the sessions but takes less work to produce
  • News and event reaction, such as a post on the Log4Shell vulnerability, that could generate as many as 30,000 sessions but happen only once or twice a year.

The first two types allow the team to plan what resources they’ll need to invest in order to drive a certain level of traffic, while assuming that they’ll get a boost from reactive content when it happens.

The outcome

Since starting the content program, Matt and his team have driven hundreds of thousands of additional web sessions. The content process they created has helped them to ideate, create, and distribute content efficiently. In particular, automation and careful outsourcing have enabled the team to deliver more content without necessarily taking away from other activities.

“The program has been a greater success than we hoped. Each month we produce new content and also benefit from traffic to existing content. That compound traffic means that we’re constantly delivering more and more sessions.

“The big challenge has been the industrialisation of the process. All those moving pieces, such as measurement, automation, relationships, took around six months of my time to set up and get running well. But now the automation makes us much more efficient and effective.”

Matt’s advice for other people considering a similar program is to be realistic about how long it will take to get the content pipeline going.

“When you’re working with third parties, it’s going to take eight or nine weeks before you have content that’s ready to publish. Getting that flywheel going takes effort. For example, we didn’t realise how much time we’d need to put into the content outlining. And it took our developer advocates time to get used to that. But now the process is running, the results are fantastic.”