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
  • Software Engineering vs DevRel - The difference
  • Pros
  • Cons
  • Signs to switch to DevRel

Was this helpful?

Export as PDF
  1. Misc

Is developer relations right for you?

How do you know whether moving into developer relations or DevRel is right for you?

PreviousHow to scale a developer relations teamNextTooling your way to a great DevRel Team

Last updated 3 years ago

Was this helpful?

Summary:

  • Differences between being a product-based software engineer

  • Pros and cons of this move

  • Signals in your own life are strong indicators that you might be successful in DevRel

  • What the DevRel mindset is

Scribbles

  • The main focus of the blog is to focus on the engineering side of developer relations.

Difference between being a software engineer on a product and a software engineer in developer relations

Software Engineering vs DevRel - The difference

Time spent coding

  • Product-based software engineer the majority of your time is spent working on

    • features

    • fixing bugs

    • writing tests

    • eliminating technical debt

    • writing design documents

  • Engineer in developer relations, there’s simply a lot less time to do all of this

    • developer relations teams are the connective tissue between 3rd party developers and the internal product and engineering teams

    • time spent on creating, building, and connecting with communities.

    • collecting feedback and working with your internal stakeholders to make sure the product is evolving to better serve the developer community

Size of coding projects

  • not always be the case, but generally speaking, the size of the coding projects in DevRel is smaller.

  • building a proof of concept, a demo, a code snippet, or perhaps a client library

  • your code itself is to be used by other developers within their own projects

  • building a community, overhauling documentation, amplifying knowledge about a product through videos and speaking engagements -- less coding.

Part of everything

  • part engineer, part product manager, part marketer, and part business development.

  • encounter a lot of different stacks

  • have to be flexible and learning new stacks on the go.

Focused on people

  • DevRel at its’ core is about people

  • software engineering is often more about the code you produce

  • a mix of a great engineer who connects with other engineers and has the respect of the internal teams at the same time caring about people (developers) and making them successful.

Evaluation of contributions

  • software engineer’s impact is likely focused largely on technical contributions

  • For DevRel

    • community growth/support

    • growth of product awareness

    • product influence

    • communication regarding product launches

    • delivery of technical content

Pros

  • Requires being good at a different set of skills.

  • You have a chance to see the world.

  • You’ll be closer to the people who use the product.

Cons

  • There are less DevRel jobs than software engineering jobs.

  • Most people understand the value a software engineer brings to a company, it’s not as clear in developer relations.

  • There's a lot of explaining to do.

Signs to switch to DevRel

  • Actively participated in or organized programming events, contests, hackathons, or workshops.

  • Spoke at technical conferences or meetups.

  • Have a mixed background of engineering and product or project management.

  • Academic background or teaching experience of technical subjects.

At the end of the day, it's all about the mindset, #DevRel being about people, the mindset has to be one of empathy. Their success is our success.

Is developer relations right for me?Medium
Blog
Logo