DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary
  • Scribbles
  • Four Pillars
  • DevRel vs Developer Experience
  • Outreach
  • Community
  • Product
  • Education and support

Was this helpful?

Export as PDF
  1. Managing a DevRel Team

Four pillars of DevRel

To devise a DevRel strategy, one must understand their company's needs and the tactics that can be used to meet them. Let's take a look at the four pillars to understand all of this in a better way.

PreviousHow to move up in your organizationNextBuilding your DevRel dream team

Last updated 3 years ago

Was this helpful?

Summary

  • DevRel programme usually/arguably revolves around fours pillars.

    • Outreach

    • Community

    • Product

    • Education and support

  • Pillar define what exactly is done in the programme.

  • Pillar can be further divide based on the tasks performed by DevRel and Dev Experience.

  • Offers a handy way to think about tactics to pursue a DevRel strategy.

Scribbles

Four Pillars

  • Outreach

  • Community

  • Product

  • Education and support

What are the pillars for?

  • Pillars are about what you will do in your DevRel programme.

  • The strategic initiatives to meet the program's initiative are usually chosen from one or more of the given pillars

DevRel vs Developer Experience

  • Once you take a close look at the four pillars, it's visible there are two halves -- outreach and community which is usually covered by developer relations, then we have product and education/support which is covered by developer experience.

  • DevRel programme needs to consider all four.

  • A mix of tactics chosen will depend on the broader strategy. This brings us to the AAARRRP funnel, which you can take a deeper look at in the scribble linked below.

[link the scribble]

Example of why the divide b/w DevRel and Dev Experience isn't always clear.

  • One can have a great outreach program, arguably DevRel, to drive people from awareness to acquisition -- a better approach would be to have high-quality documentation, which arguably falls under developer experience.

Outreach

  • Broadly, covered in two ways

    • Online

    • In-person

  • Activities are done in order to drive customers.

  • Makes people aware of the products and helps them get a better overall understanding.

  • Helps people to overcome initial objections and push through to some commitment to using it.

Community

  • Community is about creating a framework that enables developers to be successful with your product.

  • Having an active community around the product is 🔑 for many developers.

  • Provides the evidence that people, other than the organization selling it are using it for various use-cases.

  • Helps in amplifying efforts of DevRel programme.

Community has a role to play in each stage but it’s most focused on moving developers from the acquisition through to the product stages. The social proof, additional support, and supplemental activities that a community delivers are all crucial in helping developers to feel comfortable about committing to your product.

Product

  • DevRel teams can find themselves in marketing, engineering or anywhere based on the organization's goals.

  • Now, DevRel in the product might sound a little unconventional for beginners as to what role can they have in shaping the product -- right?

  • Developer advocacy is more talked about than developer evangelism, partly because advocacy is a two-way thing.

    • Dev advocates, advocate the products to developers but also advocate on the behalf of developers in product discussions and ensure that developer needs are heard.

  • DevRel teams should focus on ensuring that developer needs are hears and should represent the voice of developers in product discussions.

  • In terms of dev funnel - DevRel's role in the product should focus on moving someone from activation to becoming a committed user.

Education and support

  • This domain can likely be covered by several different teams.

    • Dedicated support team

    • Developer success team

    • Developer education team

    • DevRel itself.

  • Whether or not DevRel is directly involved in it, they should take account of activities necessary to educate developers and support them outside of the company's formal/dedicated channels

  • DevRel team's role should be to support developers who aren't yet customers, to provide them with educational materials that the company's tech writes wouldn't cover.

  • To ensure that developers are more productive -- strong education and support is a must.

The four pillars of developer relationsDeveloperRelations.com
Blog
Logo