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:
  • Tips to make it easier to get useful DX insights from a hack event.

Was this helpful?

Export as PDF

Dogfooding developer products: gathering insights from internal hackathons

Josh Brown shares Spotify’s experience of using internal hackathons to learn about the APIs they’ve developed, in this talk from DevRelCon London 2019.

PreviousMaking 22-year-olds love 26-year-old softwareNextHow far does your ethical responsibility stretch for the tech your devs create?

Last updated 3 years ago

Was this helpful?

Summary:

  • Stay out of the way during hack week.

    • Hackers are eager to dive into products!

  • Learn as much as possible from the developer experience of hack teams that were building on our API and SDK products during Hack Week, of which there were many.

  • ‌Studying DX from employed developers can be tough.

  • Avoid collecting feedback on your entire platform.

  • Be super aware of which resources your internal developers use when they build their hacks.

  • Take some time at the end of your internal hackathon to interview developers.

Scribbles:

  • One was to stay out of the way during hack week.

  • Learn as much as possible from the developer experience of hack teams that were building on our API and SDK products during Hack Week, of which there were many.

‌Studying DX from employed developers can be tough.

  • They are very different from external developers who use your SDK or API and

  • They often bring background knowledge about a product that an external developer would not have access to.

Tips to make it easier to get useful DX insights from a hack event.

  • Avoid collecting feedback on your entire platform.

    • Pick really specific topics that I wanted to study and do a deep dive on those.

    • Focusing on a small area can make it actionable for the product team.

  • Be super aware of which resources your internal developers use when they build their hacks.

    • Employees at a company tend to have extra access to resources like log files, source code, and other developers who may have worked on the developer tools that they’re going to use.

    • When hack teams’ internal hack teams stray away from using your public documentation, that decision can be really insightful and could indicate a gap or problem with what’s publicly available on your website for developers.

  • Take some time at the end of your internal hackathon to interview developers.

    • One-on-one about their experience with your chosen process or product area.

      • It helps to bring pre-planned questions and to be really specific in these interviews.

    • As part of the interview, it’s also really important to take time to understand their day job, the team that they worked with on their hack,

    • The project goals of the hack

      • This context really helps place the feedback, makes it actionable and gives you context that can help turn that into something you could bring back to your product team.

Video