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
  • Where did it start?
  • Motivating the Internal Developers
  • Recognising complementary roles of marketing & development
  • Timelines
  • Metrics
  • Understanding the users and advocating for them
  • Don't publish everything!
  • Is it working?

Was this helpful?

Export as PDF
  1. Developer Experience

Building a Developer Community in an Enterprise World

Listen to Laura Cowen as she goes around talking about how she developed a community and DevRel culture in IBM making the organisation understand the needs and expectations of the developers.

PreviousThe Power of ContentNextHow to lose a dev in three ways

Last updated 4 years ago

Was this helpful?

Summary

  • Define your community

  • Challenge the status quo to reach where you want

  • Fund the work properly

  • Build the internal sub-community within the organization as well

  • Understand the development and marketing relationship

  • Defend the target audience, understanding their needs and advocating them

Scribbles

  • Were more focused on Developer Experience but developers expected community support.

  • Wanted Java EE Developers to love their product (Liberty) so much that they tell their friends to use it too

    • Created articles, resources, GitHub codes, YouTube videos, etc.

    • Created shared expertise within the community

    • Openness within the community - meeting developers at conferences, talking to people generally, sharing experiences

Where did it start?

  • Whiteboard session at Devoxx 2008 (Belgium) - comparing Java application servers - everyone complained about difficulties starting/ fixing errors and consulting fees.

    • Wanted to create resources for Liberty to get around this problem.

  • Realised that they need to create a more developer-focused website for their community.

    • Frequent updates, adding new articles regularly created engagement, people were coming to the website and interacting

Motivating the Internal Developers

Wanted to get regular content from internal developers

  • But this became difficult for them with a day job

  • One developer made in charge of maintaining fresh content, working a day a week dedicated to this.

  • As it grew, one person was hired full time for regulating this.

  • Made a strict weekly publishing schedule to maintain a regularity (Made a pipeline)

  • Executive director motivated developers to contribute to content around Liberty - it worked!

Wanted to involve developers to be involved with Social Media, StackOverflow or go to conferences

  • Mentoring them to use the handles

  • Letting them know the use of hashtags

  • Creating guidelines around attending conferences

  • This cannot be forced - social media is genuine and if forced to post/ tweet, it reflects

Recognising complementary roles of marketing & development

  • Developer Advocates were hugely protected by the marketing team

  • Marketing is good at awareness and hooking people to the product

  • Marketing helps the product to shine but developers need details as well

  • Added a trial for developers to try out the product

    • If registration was added to trial download, 60% of the developers turned away, if not the marketing couldn't collect leads.

    • Cold calls attracted negative reactions from developers.

Timelines

  • Building a developer community is organic and long term.

  • Marketing needs to work on short term campaign

Metrics

  • Quantitative Measures: Numbers of downloads, visits to the website

  • Qualitative Measures: Quotes from people, their thoughts on the product

Understanding the users and advocating for them

  • Most difficult thing: Keep the focus on who is the end-user & who is the target.

  • UX Terms: Primary users, secondary users, tertiary users

  • Developers are the main users

Don't publish everything!

  • It is difficult to say no, but things should be relevant to the target audience

  • Having a clear definition of what is needed, helps in this regard.

Is it working?

  • Yes - Metrics are going up!

  • More people are talking about the product - getting feedback

Laura Cowen (IBM) - DevRelCon London 2015