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:
  • Why it can be creepy
  • Process
  • Listen
  • Acting on feedback
  • Optimize

Was this helpful?

Export as PDF
  1. Managing a DevRel Team

How to report on community relationships without being creepy about it

Microsoft’s Sarah Thiam spoke at DevRelCon London 2019 about tracking community metrics without crossing the line into creepiness.

PreviousI messed up and I’m going to get firedNextHow to scale a developer relations team

Last updated 3 years ago

Was this helpful?

Summary:

  • 3 Step Process

    • Listening

      • When push comes to shove and everything is happening really, really quickly, it’s hard to remember to listen.

      • Function as a team, don’t function as individuals.

    • Acting on feedback

      • If you create something, you have a responsibility to listen, but you also have an accountability to act on the feedback that you will receive.

    • Optimising

      • How do you optimize it a step further so that you can not only just meet requirements but also lead the conversation?

  • Anything in the developer ecosystem, things are always gonna change, things always need to refresh, and this is the only way that will keep relevant, and to keep improving.

Scribbles:

Why it can be creepy

  • It’s around the business value that

    • As dev rel professionals, we are paid to do a job.

    • And at the end of the day, those stakeholders, in order to continue their investment, will continue to ask us

      • “What is it exactly that you’re doing?

      • What is the business impact you’re bringing back to our business?

      • Continue to invest in your travel, your budget, your swag, and your stickers?”

  • How exactly are we gonna format this?

  • How do we avoid commoditizing community connections?

Process

  • Listening

  • Acting on feedback

  • Optimising

Listen

  • Listening is something that is easily forgotten.

  • When push comes to shove and everything is happening really, really quickly, it’s hard to remember to listen.

  • It’s hard to remember when you are being tasked with a certain thing and expected to deliver, it’s hard to remember to listen to your teammates around as well.

  • Function as a team, don’t function as individuals.

  • Lots of feedback questions

    • What is it that you’re not comfortable about?

    • What do you think the reporting needs to entail, and what do you want to be able to put down into a form so that we can record what you’re doing?

    • So, two things that we heard, and these are my learnings, I’m gonna do both at the same time.

Privacy

  • How far can someone go to violate privacy in order to do well at their job, or to be able to prove their impact?

  • Have a reporting program that you can fall back on that is able to respect people’s privacy.

Authenticity

  • Only trusted people will be more open with their feedback.

  • Be more invested to give you better engagement and better feedback for you to improve that technology

  • It’s a symbiotic relationship

Oh, I’ve done 10 community connections, “I’ve done 10 trips, duh, duh, duh, duh, duh” it becomes a number. And, by making these things a number, are we dumbing it down to something that is so much less than the meaningful relationships that we make?

Acting on feedback

  • If you create something, you have a responsibility to listen, but you also have an accountability to act on the feedback that you will receive.

  • It’s gonna be really redundant if you just leave that aside, or you don’t demonstrate how that has directly connected to you building your program.

  • So, acting on feedback was really important.

Privacy

  • Put in a baseline requirement of how privacy is key.

  • Only focus on publicly available information.

    • Example --

      • Only things that people have posted up on their public Twitter sites if it’s not privatized.

      • They posted it on a public Facebook group and not a closed Facebook group.

  • Use the GDPR standards.

    • European standard for privacy.

    • Use this as a building foundation for you to build up additional requirements that you wanna add to privacy filters.

  • Keep the reporting process a bit more open, and encourage more authentic dev rea behaviour.

  • Let people continue doing as they are doing without feeling pigeonholed.

Authenticity

  • Acting on that feedback

  • Really important to defend authentic DevRel behaviour.

  • Being able to provide the right metrics.

  • Metrics drive behaviour

    • If something is celebrated in your company or your team, it’s going to influence the way that people act moving forward -- make sure that you have the right metrics in place.

    • Authentic dev rea behaviour, we have metrics that are qualitative and quantitative at the same time.

  • Defend authentic dev rel behaviour

    • Come up with something really creative and new to engage the developer community.

    • Open-ended to be able to celebrate things that are new and creative as well.

Optimize

  • How do you know you’re going in the right direction?

  • How do you know your reporting program’s going in the right direction?

  • How do you optimize it a step further so that you can not only just meet requirements but also lead the conversation?

Privacy

  • Optimizing the reporting process in a sense of being more community-focused.

  • But what if we also moved away from individuals as a whole?

  • Reporting -- focusing on the community only.

  • The community is the thing that matters, not the individual.

    • Individuals in the community keep changing, it's natural it's fine.

  • Encouragement to become more inclusive in the developer environment and not the potentially toxic behaviour of focusing on a few exclusive individuals.

Authenticity

  • Focus not just on what you did but the learnings that came out of it.

    • You’re centred more on the objective of improving developer engagement.

  • You’re not actually changing the way that they behave at all, zero.

  • Reporting mechanism to feed into what they are focused on, which is improving developer engagement.

  • And, not just for them, but also how do you share these learnings with the rest of your business to say, “Hey, as a whole company, “this is how we can better engage developers”?

  • And, it’s not just what we did, but it’s more important than the learnings and the best practices that came out of it.

Video