Mary Thengvall


Developer Relations may sound like a made-up title to some ears and vaguely familiar to others. Or maybe you already have a whole team of Developer Relations experts working magic on your behalf. Mary Thengvall has been in Developer Relations (a.k.a. “DevRel”) since it became a thing, and assures us that it’s definitely not a passing fad—it’s an increasingly critical consideration for companies who want to interact in an authentic way with their developer communities.

Over the past decade or so, we’ve watched community-building has become a part of any successful business strategy. In fact, Mary herself started out in a Community Management role (that just happened to be at a tech company) and worked her way into Developer Relations rather naturally. She’s now Director of Developer Relations at an open-source process automation company called Camunda, as well as an in-demand consultant and speaker on the subject. She’s also the author of the first-ever Developer Relations book: The Business Value of Developer Relations, co-host of the Community Pulse podcast, curator of DevRel Weekly, and founder of DevRel Collective Slack team.

So, what is Developer Relations? How is it different from Community Management? Why should you care about it as a business leader or a developer yourself or someone who has any kind of stake in what devs do? The answers, my friend, are in this interview. Mary kindly shares her thoughts on how DevRel benefits everyone, along with some tools, tips, and tricks she uses to elevate her own team—and the community-building industry at large. 

How did you get into Developer Relations? Did you have a technical background?

I had zero intention of getting involved in tech. I actually studied journalism in college and had the great luck of graduating at the same time as most newspapers for laying off their editorial staff—right around when blogs were coming up.

I wound up getting a job at O’Reilly Media, a technical media company, basically writing press releases for new books and new videos that were coming out. All these technical topics were brand new to me—I didn’t know much about them. So, I was using that journalism side to really do the research and find out what things meant and why people were interested in these topics.

But I was having a hard time finding out: Why is it that we chose these topics right now? How do we know these are the topics people are really interested in? How do we know that these are the resources that people are asking for rather than just things that our brilliant editors are interested in? So, I kept asking questions. Until, honestly, I think I just became that annoying early-twenties coworker, and someone said, “Fine, go ask those questions, figure it out.” So, I found myself with this job title of Community Manager—not really knowing what a community manager was or what I was going to be doing. But I was given the freedom to kind of figure it out.

In the beginning, a lot of it was just talking to people and sitting down with our conference attendees or our authors or speakers and saying, “What information do you have? What are you excited about? What are you interested in? What events should I be attending?” Then, taking a lot of that information and that feedback to our conference chairs and our editors and our Marketing team and saying, “Here are the interesting topics that people are pursuing right now.”

Along the way, I kind of discovered that there was this whole industry called Developer Relations and that Community Management really is a thing. So it felt—and it has continued to feel throughout my entire career—that I’d been lucky enough to be on the cutting edge of this industry.

A couple of years ago, I hit a point where I’m feeling like I have a lot of experience to share, and people are looking to me and a few others to really help them understand what this industry is.

So I started creating content that was essentially the content that I wish had been there when I got started. I started a podcast with a couple of friends of mine and started a Slack team for people who were doing this type of work. And a lot of little things like blog posts here and small get-togethers at conferences that encouraged people in this industry to really get to know each other and to collaborate in a way that we hadn’t been able to before. And that’s led to all sorts of other opportunities! I’m speaking at conferences these days. I’m a guest on podcasts, the Slack team now has almost 1,700 people in it. I published a book almost two years ago on the business value of Developer Relations. It’s become a passion of mine to not only help companies figure out what the most successful way to run a Developer Relations function is, but also provide these resources for people who are really in the trenches and doing the work.

How did DevRel evolve into a practice? Where do you think it began?

Back at Apple in the mid-eighties was the first time we heard the title Developer Evangelists. It kind of started from the need to sell products to developers, but in a language that they will hear and understand and respect. And it’s obviously picked up from there.

The first time I’ve heard the term Developer Relations come around was 12, maybe 13 years ago now. I believe the growth of the field has been driven by the increase in B2B companies for whom developers are the end users. We suddenly have a need to talk to people that Marketing usually doesn’t have a good way to relate to—you rarely find a developer who is also in Marketing or someone who has a developer background in Marketing. There’s also this misconception that developers hate Sales and Marketing. It’s not that people hate those things; it’s that they hate feeling like they are being marketed to or sold to. And that’s not a developer-specific characteristic; that’s a people characteristic.

I honestly think that that’s been the biggest impetus for this growth: We need a group of people who can speak that developer language, who can talk to developers from direct experience and understand their issues. There is a marketing/sales side to it, but it’s far more relationship building and enablement: We want to help make your job better than it is.

The reason why DevRel has picked up so much speed in the last couple of years is that the startup scene has exploded. The number of new startups founded in 2019, according to Crunchbase, was 4,097. That’s just founded in 2019. Most of those companies these days have something to do with developers: You’ve either got developers or working there, or an API that they’re building on, or tooling that they can use, which means you have to have people who can talk to them. If you have someone that developers trust on your team—building that community and making it clear to developers from the start that we’re listening and we care enough to actually not just receive their feedback, but do something about it—that can turn into a competitive advantage for companies.

Do you necessarily need a technical background to do well in Developer Relations?

Within the DevRel industry, there are roles that require far more technical ability versus what I call “tech-savviness.” I can draw the patterns. I can look at a list of GitHub repositories and know 30% of them are written in Java. I know the libraries and frameworks that go along with the actual Java programming language and can make those deductions, but I’m never going to be the person that sits down to help you debug your code. And that’s fine. Right?

There’s a path for people, even if you don’t have a developer background. One thing that I always had to remind myself and my teammates was that people are rarely unwilling to answer questions. I think there’s a general feeling these days that “I have to have the answer to everything—I can’t admit I don’t know something about my company or my product.” When, in reality, as we’re trying to build relationships with our audience, trust is the foundation of that relationship. If I’m sitting at a conference booth faking my way through an answer, someone’s going to know, and they’re not going to trust me. But if I say, “Hey, you know what? I actually don’t know the answer to that. Let’s find out together, or let me go find the person who does,” there’s going to be a lot more respect. And now you’re going to be seen as the person who knows everybody and who can make all of those connections for people across the industry, which is valuable.

What does your day-to-day look like in your current DevRel role at Camunda?

My day now as a manager is a lot of empowering my team: Figuring out, what does my team need from me? What do they need from the company? What can I do to help them? Helping them set priorities and figure out the next thing they should be tackling.

We have a saying at Camunda that I love: “As much as necessary and as little as possible.” We set up all of our tooling and infrastructure, and frameworks in that way. We need processes to help us be more efficient as a team and as a company, but only as much as necessary and as little as possible so that people don’t have to do processes for processes’ sake. Even though we are a process automation company, we want to make sure that processes are being used responsibly. A lot of that is helping the team prioritize their work and figuring out what the next steps are and what the next goals are, which comes from spending time in cross-departmental meetings or having conversations around our company objectives.

My personal goal is to really understand where my team really fits, not just org-chart wise, but where can we provide the most value. Because at the end of the day, Developer Relations isn’t just serving the external community; it’s serving the internal community too. There’s always this balancing act of keeping the needs and the problems of my internal community, my coworkers, and the developers who are building our products in mind as well as the needs and solutions that my external community needs.

To the company, I represent the community; to the community, I represent the company—and I must keep both interests in mind at all times. Things like knowing that there’s a job opening on another team can be hugely beneficial because I can say, “Oh, I actually know a community member who would be perfect to fulfill that role.” I can make that internal connection.

There also might be projects that we can help out with or interesting insights that we can provide for a particular document or things like that. Also, having those conversations and those spokes out to the rest of the company helps me to better set goals for my team. Because I’m able to understand everything that everyone else is working toward, I can relate the goals for my team to the overarching goals for the company. This way, more people are going to see the value that my team brings, not just to the external community but to the company as a whole.

“Community” seems to have become almost a buzz term in the business world recently. In your words, what does community mean, and why is it important for companies?

So starting with “What is community?” The definition that I use is, it’s a group of people who not only share common principles but also develop and share practices that help individuals in the group thrive. So it’s not just enough to say, “Hey, I’m also using that software or I also like Java,” but it’s about sharing best practices, sharing tips, and connecting with people. At the end of the day, Developer Relations is truly community-building for a technical audience. It just requires slightly different skill sets sometimes because you have a different type of audience.

I think the biggest reason why community is such a defining factor for successful businesses is that there are lots of people who use your product who are sharing tips and tricks and experiences, and that’s a visible thing that you can see. It’s almost like seeing reviews on a website: It’s confirmation that there are real people using your product who actually appreciate it. And the more that we as a Developer Relations team are connecting with that community, the more those people start to see their feedback heard and actually become part of the product roadmap—In the case of open-source software, they can actually contribute. There are connections being built within your community that, from a sales perspective, make it really difficult for a person to walk away.

I truly believe that the companies who are taking feedback from developers seriously and truly engaging with that audience will wind up ahead. Those are the companies proving to be more responsive and more inclined to create a product that their customers actually want.

There was an excellent Real World DevOps podcast episode with VM Brasseur about how we’re starting to see some [open source] companies getting upset that people are using their software and building on top of it to create something better. And her point was that those people are creating something better than what you currently have because they’re actually listening to their audiences. If you just listened to your audience and actually implemented the feedback that you were getting, you could be the people standing there with the better, more superior product, and you wouldn’t have the competition.

That’s kind of the defining factor: Making it an initiative, internally, to say, “We’re not just going to collect this feedback, we’re actually going to do something about it.”

What are some of the tools and tactics that DevRel experts use to start building these communities?

It’s really only been in the past year or year-and-a-half that there have started to be more tools created for DevRel experts. There’s a company called Krunch that’s building out a system that lets you really understand the impact of the work that you’re doing. On the face, a lot of the information you put in is very similar to a social media metrics tool, where you can see engagement on Twitter and Slack, etc. But with this, you can integrate all of these different tools from Reddit to Github to Google Analytics in there as well. It gives you benchmarks for different activities like a conference, blog, or campaign and their direct impact on social media, Stack Overflow, or GitHub contributions. Having that information overlaid is huge because up until this point, I’ve had spreadsheets that are a huge pain to maintain. I truly think it’s something that can change our industry for the better and give us some good metrics behind what we’re doing.

The other one is called Orbit, which helps you kind of visualize the relationships that you’re building with folks. They have a couple of different components that they take into account: love and reach. Those come together within this idea of gravity: The bigger your reach and the more that people love the product, the stronger your gravity—the closer you are to the core of the community you really want to be connecting with.

It’s similar to a classic CRM in that you can add information about the person to kind of keep track of their engagement. But it really focuses on how often and at what level people are engaging, and you can set up a point system. It helps us as a company to determine what really matters to us and how we are going to reward people and to keep an eye on the community as a whole.

So how do you convince business leaders of the value of Developer Relations?

The biggest thing that I always emphasize is that Developer Relations is not a short game. If you’re looking at “What’s going to get me on the top of Hacker Noon?” or “What’s going to get me the most followers on Twitter?”, this isn’t what you’re looking for.

There’s more of a long-term goal of building relationships and having that solid foundation. That then leads to awareness and to an increase of people not only knowing who you are but knowing that you’re the people they want to be doing business with. And that takes a while—it’s not going to be instantaneous.

When you go to measure building Developer Relation efforts you’re trying to measure these things that are intangible. When you say, “We got X number of leads from a conference or this many click-throughs on the whitepaper”—those types of traditional marketing metrics fall short because what you’re really trying to do is measure that relationship. You don’t go up to a friend of yours and say, “We’re such great friends. And it took us three cups of coffee and two dinners at each other’s houses and a bike ride through the park to get to the point that we are now. And that cost me X amount of dollars.” They’re going to look at you like you’re from a different planet and probably walk away.

However, if you’re building relationships and establishing that trust, then your company is going to be top of mind any time that person needs a solution or their acquaintances need a solution. It goes back to the “reach” idea from Orbit. It’s like, “I have a relationship with Camunda, and I’m also going to recommend Camunda to my colleagues, to my friends, to my tech acquaintances, to someone on Twitter who says, ‘Hey, I need a way to automate my processes. Does anyone have a good recommendation?’.” It pays off in the long run, because, as you’re establishing that trust, loyalty is going to spread by word of mouth.

DevRel is also a big part of reducing customer churn. The stronger the community “stickiness,” the harder it is for someone to leave because even if it comes down to money and they can get a better deal from another company, you’ve built that relationship, and they know that they can trust you. They’re able to make a case internally at their company for you.

Those are the two things that I really focus on. Responding to feedback goes along with both of those because if you can establish a certain level of trust and honesty and authenticity with your community members and they’re willing to give you feedback, no matter how difficult it is, that’s huge. Then you’ve got people who are willingly coming to you rather than you paying someone $200 an hour to sit there and give you random feedback on things that you’re testing.

It’s real, and it’s authentic; it’s an opportunity to actually hear from users who are actively using your product. And that’s invaluable. But building those relationships, having that authentic conversation takes some time.

What are some of your biggest challenges as a Developer Relations expert?

One of them is continuing to have conversations around “Why is this valuable?” and “Why do we have to spend this much money?”

I know a lot of Developer Relations professionals who have stopped being a Developer Relations professionals simply because they’re tired of having to defend their jobs.

The other thing is that, because it’s a relatively new industry and because most of the people in the industry are individual contributors—not C-suites—a lot of the knowledge and expertise comes from people who aren’t in management. Convincing management that your ideas are the correct ideas is difficult. Honestly, it takes a lot of patience and professionalism to last for a long time in this role, which I think a lot of people don’t necessarily anticipate.

I mean, it’s far better now than it used to be, and you can find companies where, all the way up to the founder, they 100% understand the value that you’re bringing. But there are definitely places still that just tell you what your metrics are and adopt a “because I said so” attitude. And sometimes it’s like, “Well, that metric doesn’t make any sense whatsoever!” There’s a lot of figuring out how to fit those demands into your goals and your initiatives in a way that actually still brings the company value.

There’s a lot of business skill that goes into it. There’s a lot of just trying to figure out the easiest way to explain the value of what we’re doing and make sure that we’re also fulfilling the tasks that are being handed our way.

Was it powering through those challenging talks that made you decide to become a consultant?

That was part of it. I was frustrated with having those conversations on a regular basis and it was also frustrating seeing my friends have those conversations or seeing their teams continue to be dissolved or them not being listened to.

For reasons that never made sense to me, consultants seem to be respected more than the people in the company do. I saw an opportunity to back up people who actually know what they’re talking about at the company with facts and give them the tools for presenting in a way that makes more sense to their managers or to go into quarterly planning prepared.

For both individual contributors (ICs) and managers, those tools really helped them to shape their programs into something that business leaders understood was extremely valuable. It wound up being a combination of working with managers and doing a lot of consultations with CEOs and founders who were interested in trying to figure out, “What is it that this team is actually doing? How do I support them? Or maybe they’re not necessary anymore?”

Toward the end of my time doing consulting full-time, I wound up talking a lot with either side of the kind of work spectrum, from the ICs and managers to the investors—because the VCs were starting to have companies come back to them and say, “We heard that we have to have a developer relations team. Help.” And the VC firms were going, “I don’t know what that is. Ok. How do we do this?”

It was fascinating to be able to educate everybody throughout the entire org structure and to be able to really emphasize those points of value and the long-term benefits of Developer Relations. It was incredibly rewarding.

Having been at it for a while, where do you see DevRel evolving and do you think there’s a place for it outside of software product companies?

There are a couple of things that I see evolving: One we’ve touched on a little bit already, but companies are really starting to understand that having that community is not just “cool,” but it’s actually bringing true value to their business. It’s a competitive advantage. And so as companies are trying to figure out, “How do we get ahead? What’s the next step that’s going to set us apart from our competition?” More and more companies are starting to understand that strong foundational-community feedback is a big part of it.

As far as whether or not I see it outside of software, specifically: Absolutely. I mean, Community Management has been an industry in its own right for a long time. There’s actually a company called CMX that has been around for probably a decade as a resource for community professionals all over: you’ve got community professionals for video companies or for website companies or for photographers. I think, across the board, the community is becoming such a huge part of who we are and what we do as a world. And so much of what people are drawn to has to do with communities that I think it’s going to become that competitive advantage, no matter what industry you’re really hooked into.

Contact an expert