If you’re not familiar with the term Approval Economy, check out this excellent post from Zander Nethercutt. It’ll take about 10 minutes. Don’t worry, we’ll wait. 😀
If you’re like me, you’re a bit tired from the seemingly endless debate about what dev rel really is and where it belongs in the company org chart. People have made impassioned statements that dev rel is all about Marketing; that it is direct support for Sales; that it’s a purely an Engineering function; that it is first and foremost a servant of the Product Management org.
It’s not that I don’t have strong opinions on this topic after 15+ years in the field –– dev rel belongs in Product Management, thank you very much –– but I have been curious about why we continue to have the debate at all. In a world where flat hierarchies are touted to be the most successful means to grow a business, people get to make up their job titles based on how they think they can best reach their audience, and my own CEO says that job titles are just an overlay on top of successful open organizational structures, where dev rel reports into doesn’t seem like it should be a hot topic. As long as we have a decent budget and the autonomy to serve our constituent communities, who cares if our boss is the CMO or the CTO?
In pondering this question, I’ve concluded that the real tension is in the perceived function of dev rel by those who are not practitioners. Specifically, folks at our companies often expect dev rel to serve the attention economy, whereas dev rel professionals are experts at cultivating the approval economy. I touched on this briefly during my DevRelCon London keynote back in November, but this post will go into greater detail.
The attention economy thrives on all the aspects of traditional marketing that make dev rel folks shake their heads in some level of despair. How many subscribers do we have to our newsletter? How many click throughs? What’s the open rate of this email? How many people unsubscribed after we started this drip campaign? Or, perhaps the words that strike the most dread into the hearts of dev rel professionals, how many sales leads did we get from hosting this meetup?
Don’t get me wrong, all of these metrics are useful to different parts of the organization. But they’re not the crux of why companies should build out a dev rel team. The responsibility of a dev rel team is to both raise awareness of your company’s offerings and, more importantly, to make people feel good about using them. dev rel targets the approval economy, making use of your company’s products something that helps developers feel good about themselves, or, to paraphrase Mr. Nethercutt, to buy better versions of themselves.
In dev rel, we focus on long-term relationship building with the community, which is an essential aspect of the approval economy. Long-term relationship building means that the individual you’re in dialog with thinks that you matter, whether you become a customer today, next year, or never. Long-term relationship building means engaging with credibility, even if it means recommending a competing solution; developers, ever skeptical of over-inflated promises straight from marketecture driven slide decks or quota driven sales folks, are thrilled to be associated with someone who gives them accurate information for their needs over a company product pitch. This person, to them, is authentic and clever; they “get it.” Who doesn’t want to have associates who “get it”? Don’t we all want to be someone who “gets it”?
Long-term relationship building, regardless of whether it results in sales, can appear antagonistic to company aims, particularly if your company is a start up. People resources are especially limited, and everyone’s success depends on their ability to leverage the work done by their peers. Making friends is great and all, but if it doesn’t fill Sales’ coffers or help Marketing drive the (vanity) metrics that your VCs seek out in each monthly board meeting, you have to forgive folks if they groan and claim they don’t understand what dev rel does all day. (And how to better educate them on the value of your work – and what dev rel can and cannot do to help them meet their objectives – will be the subject of a later post.)
In addition to long-term relationship building, another key function of dev rel is helping users feel good about using your product. One aspect of this work is straightforward education; how can your audience get up and running using your product to solve their problems with a minimum of time and hassle? Dev rel folks are there to lead them through this journey, and to take in feedback along the way. Not only is this feedback valuable to your Product Management team, it cements the value of the approval economy cultivating your DevRel team does; who doesn’t want to be associated with a product where the team promoting it is kind, helps you to be successful, actually listens when you say you have a problem with the product, and doesn’t make you feel stupid or foolish for having trouble with it?
Dev rel further supports the approval economy simply by raising awareness about your product. Developers are notorious for kicking the tires on shiny new technologies, but they’re actually excited to recommend products they think are cool. And what makes a product cool? That it solves a technical problem in an elegant way, sure. But at times, it’s even more important that a technology is popular and using/developing for it as seen as a signifier that one is a part of the “in” crowd of a technology that’s on its way from shiny and new to tried and true. Otherwise, VCs wouldn’t be asking start ups to report out on metrics for job openings related to their stable’s technology portfolio and looking for trends up and to the right.
So, what can Devr el folks do to cultivate the approval economy for their products? Be welcoming. Be honest. Recommend the competition when it’s better for a particular use case. Get out of broadcast mode and into listening mode when interacting with your audience off the stage. And maybe keep mumbling under your breath that you report into Marketing if you have to.
Thumbs-up photo by Peace Alberto Iteriteka, via Pexels.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?