What's on this page
Driving revenue is something no company can ignore. DevRel can support this, but its role goes far beyond that. "Nurturing" is the word often repeated in Jarek Jarzębowski's conversation with Tessa Kriesel. An experienced DevRel professional well known within the developer community, Tessa has extensive experience in building community and ambassador programs, and now she is sharing the valuable lessons she has learned along the way in our podcast.
DevRel is still maturing and evolving, as evidenced by the misconceptions surrounding it. In the conversation, Tessa Kriesel takes on a myth buster role, explaining and debunking most common biases. In what way is DevRel like sales? Why is it much more than marketing? Where does it fit within organizations, and do labels actually serve it? Her insights provide comprehensive answers to these and other questions. Discover them below!
Key Takeaways from the Conversation
Diverse backgrounds lead to DevRel: many individuals in the developer relations (DevRel) space come from varied backgrounds. DevRel is a multifaceted role and diverse perspectives are crucial in tech.
Impact of DevRel on revenue: while DevRel focuses on nurturing relationships with developers, it indirectly influences revenue by fostering a supportive environment that leads to product adoption, upselling, and ultimately, financial gain for companies.
DevRel as sales: contrary to common misconception, DevRel is a form of sales —albeit not in the traditional sense. By building relationships and credibility, DevRel contributes significantly to revenue generation through its nuanced approach to engagement.
Skills for DevRel leaders: DevRel leaders need a balanced mix of technical skills, people skills and business acumen to navigate the complexities of their role effectively. Having achieved this balance, they can drive both community engagement and organizational goals.
Importance of developer ambassador programs: Creating communities and ambassador programs for developers is crucial for nurturing superfans and leveraging their enthusiasm and trust to amplify product adoption and innovation within and beyond the developer community.
Accurate developer tracking in CRM: Properly identifying and tracking developers in the CRM is crucial. Capturing relevant details helps in nurturing these relationships. Whether through QR codes or social media follow-ups, having an efficient system is key.
Cross-departament exposure: Restricting DevRel to a single department, like marketing, can reduce its effectiveness. Leaders might focus on immediate goals, overlooking broader contributions. Successful DevRel needs exposure and collaboration across multiple departments.
Conversation with Tessa Kriesel
Jarek Jarzębowski: Hello, Tessa, welcome to the Advocu podcast.
Tessa Kriesel: Hello, thank you for having me. I'm excited to be here.
Jarek Jarzębowski: I know that many people in the developer space know you, but probably not everyone. Can you tell us a little bit more about yourself?
Tessa Kriesel: Very kind of you to say that. I'm sure there are plenty of people that don't know me.
So, again, Tessa Kriesel. I call myself a developer expert nowadays. I was actually laid off about a month ago from my Head of DevRel role over at Snapchat. We were working on Snap AR technology, leveraging the camera technology to bring that to developers, which was pretty fun.
At the moment, I'm pulling together some fun stuff on my own and excited to bring that to the world, but it's a little too early to shed a lot of light on that. Essentially, I am a developer by trade. After spending a lot of time in the hospitality business leadership, probably almost twenty years ago, I taught myself how to code. And I just loved the idea of tech.
I built a community for one of my first projects to teach myself how to code, and I naturally fell into developer relations. When I was offered my first role in developer relations, it wasn’t called DevRel; my title was agency and community engineer.
As I explored the role, it involved a lot of public speaking, training, helping developers, building code samples, contributing to documentation, and all the aspects we see in DevRel today. Reading that job description, I thought, "Oh my gosh, this is literally my dream job."
Jarek Jarzębowski: I see that people come to the developer space from so many different backgrounds and roles, and I'm wondering, what does developer relations actually mean for you? What is DevRel in a nutshell?
Tessa Kriesel: That's a great question. Lately, I've been thinking a lot about the fundamental concept of DevRel. We call it developer relations because it's about building and nurturing relationships with developers to help them with their needs.
However, to me, it's really about serving developers. I view it more holistically as a developer program. Many DevRel professionals focus on advocacy, awareness, content creation, blog posts, and writing code. But when you see it as a developer program, it's bigger than that. It helps you understand how your company can best build a developer methodology across the company, rather than just impacting developers within your role.
Jarek Jarzębowski: 1 hour ago today, you shared on LinkedIn a post with an image that says “results from effective developer programs”. The first bullet point is “revenue”. How do you see that? I mean, is revenue actually the most important effect of DevRel, or how should we perceive the effects of different programs?
Tessa Kriesel: Let's take revenue specifically and just break that down. When I, as a DevRel leader, hear the word revenue, I just sigh. The company cares about it, but I care about my developers and my users, as well as their success. Revenue is sort of an aftermath or an effect of my care.
Of course, the company absolutely needs revenue to exist. But in certain situations, revenue isn’t an impactor, right? I was blessed to be in such circumstances in my previous role. Innovation, driving awareness and building engagement was the key.
It somewhat depends on how the company looks at developers. If you see them as your employees or a recruiting pipeline, then revenue of course is not going to be an effect of your DevRel program. But for the most part, especially when we're looking at developer-first products, developer tools, anything that a developer is actually a user or a buyer of, revenue is going to be one of the key effects of that developer program.
And so the way we look at that is that the company needs to get the expected end results. In most of those cases, it needs revenue to keep moving forward. Of course, they probably need product feedback, reduced cost, additional credibility with developers, innovation and better products. But they need that revenue.
Jarek Jarzębowski: Firstly, I agree with you, but to play devil's advocate, don't you think it could be perceived as fake relationships then? If you focus too much on revenue as the key goal, where do relationships come in? What is the place of relationships if revenue is the main focus?
Tessa Kriesel: I think there are two angles here. One is structural—leaders focusing on these concerns. The other is that it doesn't have to feel like money, right? Revenue means someone paid for something. So, if you take a step back, how do you get someone to want to pay for something? That's what DevRel fundamentally is. They build credibility, answer questions, serve developers, and ensure developers have the resources they need.
In day-to-day DevRel, I wouldn't say I drive revenue. I help developers, and that leads to revenue. It’s more important for their leader to think about revenue than for developer’s advocate. As a leader, I'd work with my developer’s advocate on deliverables.
For instance, if they are running a campaign around a new product feature, it might include a blog post, a video, a code sample, and social media posts. DevRel can contribute to all of this. Developer advocates should aim to get devs to try the new feature. As a DevRel leader, you should encourage your team to think about adoption, which ultimately leads back to revenue—something executives care about.
If users adopt a product feature, it might mean they move up in their pricing plan or sign on for something additional. This impacts revenue, which is crucial for the company’s sustainability. Does that make sense?
Jarek Jarzębowski: Yeah, it does, but I'm wondering, do the skills of DevRel managers and developer advocates differ, or can you grow from one to another by building on a certain skill set and expanding your business orientation? How do you see it?
Tessa Kriesel: I love that you asked this because I have many thoughts on the subject. This disconnect has led to the disillusion of many DevRel programs.
Starting as a developer advocate, you typically come in as a developer advocate, technical writer, or developer educator. You’re likely a developer who cares about other developers, showing empathy and a desire to help peers. If you have technical skills and empathy, you can succeed as a developer advocate.
Of course, you should also work on public speaking, building a personal brand, and networking. But fundamentally, it's about technical skills and understanding your users.
For a DevRel leader, it's different. They need technical skills and strong people skills to manage their team and engage with developers. They also need to manage up and communicate effectively with executives.
Business acumen is crucial for a DevRel leader. They need to understand how money works in the business, hiring and firing, and other business fundamentals. Many DevRel leaders lack these business skills, leading to issues in the industry.
A successful DevRel leader needs technical, people, and business skills. It's not just about years of experience in developer advocacy, but having the necessary skills to run a successful program.
Jarek Jarzębowski: There's a saying that if you promote your best specialist, you lose your best specialist and sometimes get a poor manager. I see it as a similar case, but let's say some developer advocates among our listeners are thinking about stepping up and believe they could be good DevRel leaders. You mentioned tech skills they should already possess. Now, what about developing people skills and business-oriented skills?
Tessa Kriesel: This is a great question. I offer coaching in this area, and it starts with a discovery process. I have conversations about their wins, challenges, goals, and dreams. Through these discussions, I gauge their sentiments and identify areas needing improvement. Often, DevRel professionals lack a company-wide understanding regarding their specific challenges. Most are self-aware of their capabilities, but some areas need focus.
For example, I have a coaching client with an excellent resume and personal brand but lacking in thought leadership and credibility. Through conversations, I identify the skills they need to work on. When it comes to leadership, we discuss their DevRel experience, skills aligning with leadership roles, and areas needing development. I use a developer program map to outline everything involved in a developer program, helping me guide clients in understanding the company side, stakeholder engagement, prioritization, and reporting.
Leadership skills involve understanding how to drive impact, manage a team, build a strategy, define goals, and contribute to those goals. This comprehensive approach develops the necessary business and people skills.
Jarek Jarzębowski: I understand it's a process, and not always an easy one, especially when self-discovery is involved. What do you recommend as a first step for our listeners to start this journey?
Tessa Kriesel: This may not be the expected answer, but I recommend the book "Rise" by Patty Azzarello. It’s not about DevRel, but about being successful in your career. The book teaches three concepts for career success, one of which is standing out to others. Often, DevRel professionals, including myself, are humble and don’t want to brag about our skills. However, we need to highlight our achievements for the business to recognize our impact. The book covers how to be a great employee, communicator, and prove your impact, guiding you to communicate effectively with leaders.
Jarek Jarzębowski:Thank you for the recommendation. I’m also curious about misconceptions regarding DevRel. Are there any common misunderstandings about DevRel from both inside and outside the field?
Tessa Kriesel: There are two main misconceptions I want to address. First, the idea that DevRel isn’t sales. I recently wrote a controversial blog post titled "DevRel is Sales." While it’s true DevRel doesn’t involve traditional sales tactics, it does lead to sales. The second misconception is from companies that see DevRel as merely a marketing function. They think we’re just creating marketing content and bringing in users, which isn’t entirely accurate.
Regarding the first point, DevRel professionals should avoid sales pitches to developers, as it can push them away. DevRel is about nurturing relationships and supporting developers, leading to sales indirectly. When developers have multiple touchpoints with your team, they’re more likely to sign up for the product and advocate for it within their company. This leads to sales, but through a non-traditional approach.
Companies need to understand that while DevRel leads to sales, it’s not driven by sales metrics. DevRel teams should report on revenue influenced, not revenue they’re directly responsible for. Their effectiveness comes from doing things the developer way, which ultimately benefits the company.
Jarek Jarzębowski: Before we go to the second misconception, how should DevRel teams report the revenue influenced?
Tessa Kriesel: Great question. There are many ways to approach this, but I'll share how I’ve done it. If your company uses HubSpot, Salesforce, or another CRM, get yourself and your developers into the CRM. I know that sounds odd—developers in a CRM? But they need to be there because they are prospects.
First, talk to your sales team. This is where business skills come in. You need to engage with sales leaders, those responsible for the sales funnel and the steps in the sales process. These steps need to be developer-friendly if you’re bringing developers into your CRM.
Label developers appropriately in the CRM, so the company knows they are developers. Unless you’re a developer-first company, this should be standard practice. Once labeled, these developers are sent to the right salespeople who understand how to engage with and sell to developers.
For example, let’s say you meet Jane Doe at a conference. You chat at the booth and give away some cool technology. Jane fills out a form for swag, so you now have her email. Later, at the afterparty, you chat again and discover you both love dogs. You note this in your CRM. DevRel professionals need to capture these interactions to track activities effectively. I try to take daily notes to avoid forgetting details, dumping everything into the CRM or an activity log.
Back at the company, I follow up with Jane. I send nurture emails to those I had meaningful conversations with, not just generic "thanks for stopping by" emails. For Jane, I mention our discussion about dogs and share resources or demos I promised. I suggest a follow-up call to address her challenges and show how our product can help.
Over time, Jane feels nurtured and ready to buy. She might use her company credit card and proceed independently, or she might involve a decision-maker. Sales can then see the full picture: Jane’s activities, her company, and any new leads from the same organization. This creates a seamless partnership between DevRel and sales, ensuring that leads are well-informed and ready to close.
When sales close a deal, they acknowledge DevRel's contribution. For instance, landing a $700,000 deal might earn DevRel a shoutout in a company meeting. This is how you integrate DevRel into the sales process successfully.
Jarek Jarzębowski: When you explain it, it seems simple. But I know that simple does not always mean easy. What is the most challenging part? Is it the nurturing or the tracking and measuring?
Tessa Kriesel: All of it is difficult. At Snap, we didn’t have a CRM for this, so I built one for our team. Sometimes you lack the necessary tools or a sales team that aligns with you, which is a big problem. Aligning with sales should be possible, but in companies not focused solely on developers, existing sales processes might resist changes to cater to developers. Educating the sales team about the impact of DevRel and understanding developers can be exhausting and sometimes fruitless.
Being diligent in note-taking is crucial, but challenging. I created processes with forms and tools to capture notes easily, but during events, it’s tough to track everything accurately. Conversations can blend, making it hard to capture each lead’s details.
You need to find your method. Whether it's using a QR code to connect or following up on social platforms, streamline your process. The steps to integrate DevRel into CRM and sales are not easy, but with experience and the right support, it becomes manageable. That’s why I’m passionate about coaching and consulting to help others navigate these challenges.
Jarek Jarzębowski: Okay, it seems doable, and that's the most important thing. It might not always be easy, but it seems doable. Now, let's address the second misconception you mentioned: that DevRel is not marketing. What does that mean? Can you expand on it?
Tessa Kriesel: Yes, absolutely. DevRel is fundamentally marketing, but it's not just marketing. This is a misconception I feel very strongly about correcting, especially for leaders and founders implementing DevRel programs. DevRel drives awareness, which is crucial, but it's also much more than that.
If you place a program or a team under marketing, they risk being pigeonholed into only marketing functions. For example, if the DevRel team reports to the CMO, their efforts might be solely focused on generating leads because that's what marketing leaders are responsible for. While DevRel does bring in leads, it's also about advocacy and education.
When DevRel is under marketing, they might be restricted to marketing goals and not fully valued for their broader impact. Good leaders avoid this, but it happens often. DevRel teams then might be evaluated only on leads and marketing metrics, neglecting their roles in product improvement and developer feedback.
DevRel teams work closely with product teams, gathering developer feedback that needs to be shared across the company—not just with marketing, but also with product development, engineering, and even recruitment. For example, they might provide insights on the application process or suggest changes to a marketing campaign. They need to collaborate with various departments to enhance documentation, improve the product, and innovate.
Being pigeonholed under one team can limit DevRel's effectiveness. Leaders might prioritize immediate marketing goals over broader DevRel contributions, especially when budgets and resources are tight. Even though DevRel can succeed under marketing with the right leadership, their exposure is often limited to marketing.
I've thought a lot about this, and a useful analogy is HR. HR works across the entire company, collaborating with all departments to understand their needs and resources. DevRel should be viewed similarly, impacting the whole company while being integrated into its operations.
The company needs to recognize DevRel's role in communicating with developers and users, which can lead to product improvements, innovation, and new features. Developer feedback can spark new ideas, such as rolling out a marketplace for product extensions.
In summary, DevRel requires company-wide understanding and executive buy-in. It should communicate across all departments, from sales to product development, and be included in company meetings to share developer trends and impacts. This comprehensive approach will help DevRel succeed, much like how HR supports the entire organization.
Jarek Jarzębowski: I have actually seen HR under the board, under finances, under operations. Maybe there are other constellations, but where would you put DevRel? It should be a separate thing under the CEO, or it can be under marketing or product or engineering, but with this understanding that it is somehow separate.
Tessa Kriesel: Yeah, so I think there's a lot that goes into this. There’s a great book, "Developer Relations: How to Build and Grow a Successful Developer Program" by Caroline Lewko and James Parton. Inside, they have this thing called an influence mapper, which helps define why DevRel exists.
In the post you referenced, there are 7 or 8 reasons for a DevRel team. By looking through that list and considering the desired outcomes of your developer program or DevRel function, you can determine where the reporting structure should go.
In my last role, we focused significantly on support deflection due to resource constraints, aiming for a better experience through self-serve options. Though I did much more, I reported to sales and loved it. When considering where DevRel fits, it often depends on the company's structure. Ideally, it boils down to whether you’re developer-first or developer-plus.
In a developer-first company, there should be a Chief Developer Officer or Chief DevRel Officer. Or even better, a Chief User Officer. Currently, no one on the executive board explicitly advocates for user needs across all functions. Marketing, product, and customer success touch on user needs, but there isn’t a dedicated role focused on this.
The reporting structure can vary, but it’s crucial that the company understands and supports the importance of developers, ensuring all departments align with developer needs.
Jarek Jarzębowski: Yeah, definitely. Actually, I have already talked and recorded an episode with Caroline and I can definitely recommend listening to it.
You've mentioned that there is currently no function that thinks about users, but there is customer service.
Tessa Kriesel: Right, right. It's not the same, but they do care.
Jarek Jarzębowski: I know that it's not the same, but there is customer service, and they do care. I don't know if you have seen the news, but Klarna has recently laid off 700 people, mainly from customer service, and they are using AI for that function. So there is this company who was quite trendy, sexy, I would say, for so many people, and they are going into the AI world with the customer service role. Do you feel that there is a risk, a threat to DevRel as well?
Tessa Kriesel: I do. I have many thoughts on this. Stepping back a bit, consider the current trend: people are focused on self-care, finding the right place for themselves, achieving work-life balance, and overall happiness. This trend has become very evident in 2024.
When companies think about offloading customer success to AI, they might face pushback from customers who value personal interactions. People in this self-care mindset don’t want to deal with AI roadblocks. For example, if signing up for a service is difficult, I’d rather step away than deal with unnecessary hassles.
While AI can supplement jobs, companies must balance profitability with customer satisfaction. If customers feel undervalued due to AI interactions, they might turn away. Post-COVID, companies need to adapt to this reality, ensuring they serve customers effectively while maintaining profitability.
DevRel, however, cannot be replaced by AI. Developers trust their peers' recommendations. At conferences, I can engage with prospects, but I also need customers to validate our product. AI cannot replicate these peer relationships. Successful DevRel relies on genuine human interactions, which AI cannot replace.
Jarek Jarzębowski: I don't want to do that. Definitely. I have recently also talked to David Ostrowski from Google, and he said that, in his opinion, all the companies are becoming tech companies, and because of that, all the companies will need DevRel. So his opinion is that DevRel will grow actually, it will not shrink; it will grow. Do you feel that? So what is the future for DevRel?
Tessa Kriesel: Yep, I do. Earlier, we discussed the need for DevRel professionals to have strong business skills. When DevRel programs demonstrate their impact, they drive company success. While there are successful programs, they’re a minority. Most DevRel professionals need to understand business better.
Developers are crucial for any tech company. Whether building internal culture or targeting developers as users, their influence is significant. Developers also drive innovation in products like Asana, Notion, and Airtable. DevRel programs should exist in almost every company, adapting to different needs and structures.
The future for DevRel is bright. However, we need stronger business skills and the ability to demonstrate our value. With dedication and the right approach, DevRel will continue to grow and thrive.
Tessa Kriesel: In the notes I shared yesterday, I aimed to paint a picture of how to do DevRel in a way that the CEO is fully invested and understands the mission. It involves four key elements: the company, the developer program, your developers, and you. You need to assess your career, skills, and capabilities in these areas. If you lack in some, work to improve and supplement those areas. The future of DevRel is very bright, but we need leadership and founder-level understanding to realize its full potential.
In my notes, I listed the results of an effective DevRel program: increased revenue, credibility with developers (essential as they won’t sign up without it), a new audience (adding developers as a target), reduced cost to serve (especially for developers), more "yeses" in the sales funnel, a better product, and innovation expansion. We must incorporate these elements into all our developer programs.
Jarek Jarzębowski: One last question because we’ve already passed one hour. What is your take on developer ambassador programs and creating communities for developers? I'm asking because, of course, Advocu is a tool for developer ambassador programs, but I'm really curious about your perspective.
Tessa Kriesel: Yes, absolutely. Do it, do it, do it! I cannot stress this enough. I have a book on my desk called "Superfans" by Pat Flynn. It emphasizes that you don’t just want followers or customers—you want superfans. DevRel exists because developers need to talk to their peers and get credible recommendations. Once you have enough developers who are superfans or promoters (rating 8 or above in a net promoter survey), build a program for them. These power users love your product and will advocate for it, provided you nurture them.
In my first DevRel role, I built such a program without much guidance. I identified developers who were already promoting us and thought, "Why isn’t marketing leveraging this?" So, I proposed nurturing these advocates, giving them a VIP experience. The concept in the "Superfans" book, like Hershey opening its doors to fans, is powerful. Let your superfans provide feedback, advise you, and promote you. One of the first significant investments should be in building a program to let developers share their love for your product because peer recommendations drive sales.
Jarek Jarzębowski: That’s a perfect conclusion. Where can our listeners connect with you if they want to learn more?
Tessa Kriesel: You can find me as TessaK22 pretty much everywhere. My website, tessakriesel.com, is the best place to see what I’m up to, whether you need a coach or consultant, or just want to follow my thoughts.
Jarek Jarzębowski: Great. Thank you, Tessa. I’ll share the links in the show notes so everyone can find you easily. Thank you for sharing your knowledge and thoughts. Please continue to share them on social media so we can all learn from you.
Tessa Kriesel: Absolutely, I wouldn’t have it any other way. Thank you for having me.
Jarek Jarzębowski: Thank you.
About Tessa Kriesel
Tessa Kriesel is a seasoned developer relations leader with a strong background in community building and technical advocacy. Formerly the Head of DevRel at Snapchat, she specialized in integrating Snap AR technology for developers.
Starting her career in hospitality management, Tessa transitioned to tech after teaching herself to code. Having built communities early on, she found her niche in developer relations. Today, Tessa continues to drive innovation in tech and community engagement, pursuing new ventures while leveraging her expertise in developer relations.
Closing Thoughts
The issues Tessa raised in her conversation with Jarek and the conclusions drawn from this exchange paint a clear picture of DevRel as a role far beyond marketing and sales. Instead of just driving awareness, it focuses on nurturing relationships.
This is how DevRel contributes to revenue, albeit indirectly and sometimes invisibly. It doesn't operate on sales metrics but can deliver substantial sales outcomes. Building trust, cultivating developer loyalty, and facilitating product adoption and improvement encapsulate DevRel's essence.
The key to achieving DevRel milestones? Primarily, integrating DevRel seamlessly across organizational functions instead of confining it to one specific area. Follow Tessa's advice and watch your program or team flourish in advocacy and education, not merely in marketing. It will pay off!
