Growth Marketing

Note: This page is a work in progress for the newly-created Growth Marketing team. For an overview of our kickoff, see Growth team .

Table of contents

Team

  • Taylor Sperry, Product Manager
  • Brett Hayes, Software Engineer
  • Becca Steinbrecher, Software Engineer
  • Paulo Almeida, Product Designer
  • Kelsey Brown, Data Analyst

About Growth Marketing

For devs, by devs

The Growth Marketing team focuses on product-oriented features that generate inbound traffic and lead to qualified trials. We inform our priorities and achieve our goals by partnering with Community, Product Marketing, Data & Analytics, and Design.

Team vision and principles

  • We drive qualified trials by talking to devs as devs. Our voice should always be a dev voice, whether we’re engaging ICs, engineering managers, or directors. They’re devs too.
  • We understand that devs learn and get excited by playing, not pitching. That’s why we showcase the power of Sourcegraph by providing value instead of giving the hard sell.
  • We only do things that we could proudly and publicly state that we’re doing. No gross growth. No spam.
  • Everything we do is in the interest of driving qualified trials. Sometimes our ideas for how to do that will fail; if they don’t, that means we aren’t being ambitious or fast enough.

How we work

  • For every change we make, we have one metric that is clear, trackable, and links to a dashboard. We discipline ourselves with one very good metric to avoid fuzziness. If we make an exception to this rule, we document our rationale and share it publicly.
  • Every effort has a defined end deliverable. We don’t get bogged down in ongoing work.
  • We prioritize rigorously to make sure our projects have a clear deliverable, a clear level of effort, and a clear metric. We need everyone’s input on this, but Quinn Slack and Taylor Sperry will be the decision-makers. This lets us move quickly and decisively by protecting us from analysis paralysis. We accept the risk that sometimes we’ll make the right call, and sometimes we won’t, but that’s how we’ll learn what’s working.
  • If we have an instinct that something is wrong and no persuasive data to the contrary, we will assume our instinct is correct and hold ourselves accountable with new data. It’s more important for us to be data-informed than data-driven.
  • We will make small, quick changes without design so that they can support us (and other teams) with bigger projects.
  • When in doubt about whether an idea appeals to devs, we run it by #dev-chat, #ask-a-dev, or in very quick surveys of external developers.
  • We work in the open in #growth. We use #growth-marketing-internal for housekeeping and post weekly updates in #progress, which holds us accountable to moving quickly and sharing widely.

Other guidelines

  • No gated content.

Ownership

See Engineering ownership