# How to report on community relationships without being creepy about it {% embed url="" %} Video {% endembed %} ## 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.