It’s only been a few days since I returned home from DevRelCon in Prague. The last time I attended DevRelCon in person was in London, in 2019. It was due time.
I was asked to have a talk ready, in case speakers had to cancel - because that’s what we do as event organizers these days, prepare for the unplannable. Good thing I had something on the shelf (how Devopsdays organizing teams responded to the pandemic), because indeed someone had to cancel. I will publish the content of that talk soon, watch this space!
Aiven sponsored several people with a diversity scholarship, and I’m just so grateful that we could support the community in these times 🙏
Which brings us to one of the overarching themes of the event: how to do developer relations during an economic downturn?
Ben Greenberg is a second career developer, and Senior Developer Advocate at Parity Technologies. In his talk (slides) Ben explains that it’s paramount that we know and show our worth. “DevRel is hard to measure” is a popular trope. BUT if we're part of the success (narrative) of other teams, and we're not measuring that, we'll just populate other team's funnels and show up in their metrics.
In order to find out what to measure, Ben suggests returning to your team’s “origin story”. Why were you created in the first place? In a downturn you will want to create value directly connected to your origin story.
An example: "DevRel was organized here because our product is very complex and we had no developer tooling to help". Great! You can measure time to hello world, the number of issues created and time to resolve them, and/or the number of API calls through SDKs. You need to (continuously) share this data, or else it is like you didn't even do those things.
Matty Stratton, Director of DevRel at Aiven (that’s right, he’s my boss), and the global chair of the DevOpsDays set of conferences, encouraged us to now more than ever reach beyond our department, and even beyond our organizations. Forge relationships with Marketing, Sales, Product, and reach out to your peers in DevRel for joined activities.
For the last 5 years, Karin Wolok has been building programs that turn the most engaged users into advocates. First at Neo4j for the graph database community, and then at StarTree, a startup focused around Apache Pinot. In her talk, Karin covers strategies and tactics on how to build a program to encourage your users to become advocates and how to do it at scale.
The goal is to get a little bit more from every user, you don't need everyone to become an advocate. Lurkers become Commenters, Commenters become Contributors. People want to be valuable.
Quoting from Growth Hacker Marketing (Ryan Holiday), and using Google Reviews as an example, Karin shares how showing potential impact (help answering questions), gratitude, actual impact (views for similar places), and leveling up / status, minimizes the barrier to entry, creating a "ladder" of easy contribution.
Community champions programs… There are many: Heroes at AWS, MVPs at Microsoft, Asana Together at Asana, Supernovas at Postman, Trailblazers at Salesforce. Ully Sampaio, Contributor Program Manager at Elastic, talked about Elastic’s champions program from its creation in 2020 until present day.
A snapshot of the 2022 community:
- +13% number of participants (from 39 in 2020)
- +38% amount of contributions (from 300 in 2020)
- +11% participating countries
- +25% different languages
One of the indirect impacts was that 4 contributors were hired by Elastic. Brandon West in his talk (summarized in this blog too), and Ully both celebrate champions becoming employees, but I’m on the fence. Not being on the payroll allows externals to talk about your product and company with a certain authenticity. I think that for a community to be successful it needs to be made up of different parts.
Elastic’s leaderboard scoring system is something I have a hard time believing that it will drive the right behavior (in the long term). Champions programs are notoriously not-diverse to begin with, URMs (underrepresented minorities) don’t have the privilege to contribute free labor and are less likely to rank high when a system looks at the number of activities.
Continuing on the topic, Rebecca Marshburn, Head of Community at Common Room, talks about using Common Room to grow the “Uncommon Community”.
She defines a champions program as designed to create a closer connection with product users to extend knowledge, improve brand recognition, and drive sales. Generally, we mean to create a long-term partnership where there’s a give and get: both external product users and internal teams give value and get value.
Before you start a similar program, make sure you align your goals internally, and define what you’re looking for / from your champions.
Introduced as DevRelCon's filosofer in residence - he did a four years post-graduate study in cognitive neuroscience, and got a PhD analyzing epistemology of 20th century neurophysiology - Don Goodman Wilson talked about how understanding the power we have over others is important for not only doing our job well, but doing our job ethically as well.
There are very many neurotransmitters, and their variety allows for differentiated messaging. Oxytocin is released when receiving value in a context sensitive way (helpful advice, being listened to, feeling validated, …). While serotonin is what you get when you're treating people with kindness, triggers need to be repeated and be consistent for oxytocin release.
“Oxytocin is literally love. Our jobs are done well when we trigger oxytocin release, thus Developer Relations is a practice of cultivating developer love.”
Treating people with kindness and respect will improve your numbers more than anything you can do on a person-by-person basis. Successful DevRel programs engage in patterns of repeated activities that demonstrate kindness and respect for developers.
The negative effects of oxytocin include increased group think, propensity for group-serving deception (toxic communities), sensitivity to contagion cues, magnitude of anger and fear responses.
Kindness and respect are table stakes. You can and should go much further. Build personal relationships, and because you don't scale, enable others to build relationships as well. And don’t forget the moral obligation to be sensitive to the emotional effects of our actions.
Benjamin Bryant, Go engineer and meetup organizer, reminded us that we have a choice to be more aware. When he heard a story of a candidate who only used male terminology when referring to engineers, Benjamin asked the person if they let him know that this was a reason for rejecting him. And he asks us: would you? The answer, like the answer to many things in life, is: it depends. A thought-provoking talk, about responsibility and support networks.
Cat McGee leads the developer relations strategy for some of the biggest leaders in the blockchain space (Hype). Addressing the palpable skepticism in the room around Web3, Cat comes armed with data.
The current web is built in a way which incentivizes data collection and information manipulation, we all know this to be true, and in fact (the new owner of) the bird app were mentioned mockingly by several speakers.
“Web3 is here to stay. And if you’re planning to be in developer relations over the next ten years, then you’ll either work directly with web3 technologies or the developers you target will have them somewhere in their tech stack.”
It’s still early days and it's important to be cautious, but according to a study by Electric Capital there are 18.416 monthly active devs in Web3.
Two take-aways from an allround interesting Developer Success Roundtable with that same Cat McGee, Kristof van Tomme (CEO Pronovix), Jonan Scheffler (Director of Developer Relations, Parity Technologies), and host Matthew Revell (Hoopy.io / DevRelCon org):
- In reply to PJ Hagerty (Spotify) “Developer success is not static, it’s a moving target”, the panel concludes that it’s best to have the outcome defined as such so that you can adjust the activities. Carla Teixeira (Miro) mentioned “low churn” as an example.
- Brandon West (Datadog) defines Developer Success as “identifying patterns in usage and suggesting ways to optimize and spend less money on your platform”.
Kevin Lewis is a Developer Advocate and Director of You Got This – a learning hub to help developers improve their core skills. His talk introduced me to the term “kitchen sink demo”, an apt name for a demo that includes all features of a product, plus complimentary tech to make it all work.
Challenges with more complex demos are plentiful. You're going to have to teach more (concepts) than just your product, which adds up in terms of maintenance. You risk use-case lock-in. And then there’s the "Uncanny valley" of realistic demos - a more complete demo might actually lead to disappointment.
Smaller demos are easier for your audience to lift and drop in their projects for really testing it out, and they are better reference material (for follow up demos).
Kevin recommends an atomic design approach for your future demos, where “atoms” are very specific, “molecules” combine (a small number of) complimenting features, and “organism” present a contextual use case.
In any case, before you build your next demo, gather requirements first, agree on the demo type upfront, and decide who will maintain the material.
Senior Developer Advocate Olena Kutsenko in her lightning talk, helped us deal with our anxiety of public speaking by using science. For immediate stress relief one can use breathing exercises, or eye movement exercises to trick the mind into calming down. For long lasting stress relief Olena cites studies that recommend meditation, sports, and… cold water exposure 🥶
David G Simmons, Head of Developer Advocacy at StarTree, addresses a subject that resonates with everyone in the room: “we need to handle conferences and CFPs for the whole company, there's an almost infinite amount of conferences, and a large amount of data points for each conference, managing all of that is a nightmare.”
Starting with a screenshot of the all too familiar Google Spreadsheet, David jokingly said he made it worse at first by creating an even more complex Airtable for events management.
Beyond the forms front end, powerful sorting options, and linking between different bases which Google Spreadsheets is also totally capable of, Airtable has the ability to present a variety of "Views". Plus: it has powerful integrations for notifications eg.
For StarTree employees (DevRel and other teams) there is now a form to submit conferences, that has all required fields for data consistency, and format fields to avoid errors. Submitted conferences are vetted and then added to the Calendar.
Folks who want to be a speaker have another form to fill out, in which they can identify interest areas, and can choose if/how they want to be notified of CfPs. When they submit they need to choose from existing conferences. StarTree has a complete view of when and where colleagues will speak, and because DevRel has a direct line with SLT, travel for conferences that are not in the system do not get approved. Bold, but effective - how else can DevRel support colleagues in their public speaking endeavors?
Daniel Bryant is the Head of DevRel at Ambassador Labs, who, over the last year, has doubled down on their adoption of Product Led Growth (PLG), a growth model where product usage drives customer acquisition, retention, and expansion. It’s been an interesting journey for the DevRel team, who have found themselves working more closely with both the sales and growth engineering teams.
The Ambassador Labs team have learned more about the value of creating hypotheses and analyzing quantitative data, but have also been reminded that there is no substitute for qualitative data and engaging human-to-human.
Product-led Growth (PLG), when done well, can break down barriers between departments and teams to drive more adoption (and revenue). DevRel teams have a lot to add to PLG, in empathizing with your user and product to drive effective experiments, focusing everyone on the end-to-end (developer) experience, and identifying the user value, "aha moments", and opportunities for virality.
Brandon West (previously SendGrid and AWS) is an Advocacy Team Lead at Datadog. He talked about how an effective DevRel program can showcase and reinforce culture and values, attract top talent, and build trust in a brand. And, on the flip side, can sink all of that too when done poorly.
Contrary to what some speakers claimed - and what a lot of the hallway chatter was about - Brandon doesn’t think that this is the time we should stop doing the things that don't scale. For one, he asks to bring back event write-ups - you’re welcome, Brandon.
Ivan Brezak Brkan is the Director of Developer Content at Infobip. He talked about Employer Branding, and I think the Infobip Engineering Handbook deserves a mention, which - like the GitLab Handbook - gives candidates a great overview of what working in Engineering at Infobip is like.
Amy Mbaegbu and Afzaal Ahmad Zeeshan, Internal Developer Advocates at Adyen, talked about how their team focuses around engineers’ satisfaction inside their company. By identifying expert groups and communities, developing team-specific onboarding, establishing in-house tools and processes, and migrating from “tribal knowledge” to standardized documentation, internal developer advocacy helps build the culture description, not the job description.
After reading all this you might be excited to join the next DevRelCon. I heard talk of many cities and folks wanting to bring DevRelCon there, but certain are DevRelCon Yokohama, March 10-12 (CfP closes December 31), and DevRelCon Tel Aviv - successfully influenced during the speakers dinner.
Of course in the meantime we’ll have the videos of this years