What's on this page
The paths to DevRel are varied: some are straightforward, others winding. In some cases, transitioning to this side of the field seems like a natural progression, while in others it is quite sudden and surprising, even for the person involved. Tim Benniks describes his journey into DevRel as "quite odd" - yet, along with Jerzy Jarzębowski, they managed to extract many universal insights from this experience.
In their conversation, they discuss the key skills in this area, AI's role in crafting DevRel content, the challenging art of creating communities, and various other aspects of developer relations. What does a developer need to start conquering DevRel? How to attract potential collaborations? Tim Benniks answers these and other questions in the material below.
Key Takeaways from the Conversation
Balancing Planning and Reactivity: Successful Developer Relations (DevRel) requires a balance of strategic planning and the ability to react quickly to industry changes, ensuring content remains timely and relevant.
The Power of Communication and Humility: Effective DevRels are not only technically skilled but also excel in communication and teaching, learning continuously from their communities and maintaining humility.
AI as a Content Enhancer: Utilizing AI for structuring thoughts, generating questions, and identifying gaps can significantly improve the quality of written content, whether it be blogs, articles, or scripts.
Genuine Feedback Builds Trust: Providing authentic feedback in unprepared, live settings can establish credibility and attract collaboration opportunities, as it reflects genuine user experience.
Key Elements of a Strong Ambassador Program: A great ambassador program offers premium support from product teams, builds credibility, and encourages product usage through resources and community building, all of which contribute to the ambassadors' engagement and motivation.
The Conversation with Tim Benniks
Jarek Jarzębowski: Welcome to Advocu podcast. It's very nice to have you here.
Tim Benniks: Thank you so much. I'm super excited to be here as well.
Jarek Jarzębowski: On LinkedIn you call yourself speaker, dev lead, and content creator. But I know that's not all you do. So, can you please tell us a little bit more about yourself?
Tim Benniks: I work at Highgraph as a developer relations lead, mainly focusing on awareness and outreach. I'm in the content side of our DevRel space, navigating between marketing, developer education and developer experience. But generally, it's all around the content.
I've come into DevRel in a slightly odd way, having done other stuff for a long time. I've been at agencies as a developer from junior to global frontend lead at large agencies. From that perspective, I've learned a lot about partnerships work and how people learn. Hopefully, my skill is still up-to-date, but I argue a lot from actually knowing the code.
It's quite interesting because coming from the agency side, especially from a higher position, you always need to consider business implications, KPIs, and how to communicate with C-suite executives. So, with that experience, I bring a slightly different perspective to DevRel.
Jarek Jarzębowski: From what you're saying, you have quite a lot of responsibilities. Can you tell us how it looks like in a day-to-day job? What are you actually doing on a weekly basis?
Tim Benniks: Our approach is quite diverse, but we plan a quarter ahead. We aim for consistent activities, like a weekly live stream and a blog post or article. These are our cornerstones.
However, being reactive is crucial in DevRel. For example, if Firebase adds a Postgres database, we create content about it immediately. We adapt to industry changes and use products frequently, creating demos or videos when we encounter common user challenges. This balance of planning and reacting has proven successful.
Regarding KPIs, it's challenging to measure DevRel success, especially in tough economic times. We focus on impact, tracking how our efforts contribute to developer experiences and eventually revenue. We're refining our metrics, aiming to increase user signups and their engagement with our product. Lowering the time from signup to activation improves engagement and ultimately revenue.
DevRel can also function as a content marketing engine, since DevRel professionals know how to engage technical audiences.
Jarek Jarzębowski: As far I have seen you've been in DevRel for three years. How did you transfer from being a developer to someone who is focused on developer relations, marketing, sales? Someone who understands what needs to be done to get the product to make the company successful? Because this is what I believe DevRel is all about. But this is not something that you learn being a developer or even a director of web development.
Tim Benniks: That's true. And so I might have a bit of an odd journey into DevRel that helped me understand this a little more. And let's be honest, I didn't understand any of this three years ago. Here’s an example: my colleagues mentioned GTM which is the go-to market. You know what I thought it meant? Google Tag Manager. That's how far back I was.
I didn't initially know these things, but I learned quickly through experience. Let me explain how. At an agency, I led a global program with 120 developers, often navigating complex political situations. Somehow I stepped up, learned a lot and became a kind of a natural leader.
That was picked up by a few folks who suggested that I lead frontend development globally. However, getting promoted wasn't straightforward due to cultural differences in accepting new leadership. For example, in France, new bosses are easily accepted, but in Poland, trust must be earned. It’s a different culture. So, I essentially took on the role unofficially, working hard for a year to prove myself, acting as an internal developer relations person.
I had to market myself as trustworthy within the company, helping with complex projects and giving conference talks. This experience taught me the political game. However, the politics of choosing software due to partnerships made me realize I wouldn't be happy in six months. Fortunately, a friend offered me a role at a growing product company, focusing on developer relations. They recognized my skills in videos, blog posts, and speaking at conferences, and I eagerly accepted the opportunity.
This company where I ended up was still growing, with around 20 employees, and we didn't really have a marketing team and no DevRel at all. It needed someone who understands the space, what to say to potential customers. That's the role I took.
I was fortunate to learn from our excellent marketing team, including experts from successful startups like Contentful. They combined traditional marketing with developer marketing and growth hacking. This experience taught me a lot. Now, I have a better grasp of business concepts. Understanding these is crucial, especially when pitching ideas.
Let's take the example of Supabase who does incredible memes on Twitter. That is a modern form of developer marketing that comes from understanding your audience and market. But if you wanted to pitch that to a founder, you better be able to connect that to all those fancy words.
So, in the end, It's a journey. And also as a developer who is in charge of bigger projects, I had to have this view, right? Without that, you are not able to talk to a C-suite of a brand. Does that make sense this way?
Jarek Jarzębowski: Yeah, it does. I'm also wondering whether you can assess which of these skills are more useful for you at the moment. I mean the tech, marketing, or people skills. Are they equally important in DevRel? Can they work without the other? You have come from the technology side, having then learned the people and marketing side. There are also people who come from these areas to learn tech. Which way is better in your opinion? Is there any best one?
Tim Benniks: I have a colleague who is incredible at understanding community outreach, particularly in healthcare. They understand how people react to certain things, like whether a small gesture, such as receiving a sticker or a pat on the shoulder, makes them happy. They are great at figuring out the social implications and using that knowledge for educational purposes.
For example, creating a certification program based on that understanding is much more effective than one based solely on technical knowledge, like TypeScript. I helped them with a few implementation guides, and the code I wrote was too complicated. They asked, "Tim, why?" I realized that while my approach made sense to me, it was too complex for most people. They simplified it because it needed to speak to a broader audience.
So, you don’t need a super technical background. For me, it worked because I was in the right place at the right time in the early 2000s when we all learned to make websites, giving me a solid foundation. But you don’t need that base to be successful. In fact, some of the best DevRels I know are the best at speaking to others and are natural teachers. They learn from the community and remain humble. This broader, more inclusive approach is more effective than just having technical skills and knowing how to write a blog post.
Jarek Jarzębowski: That's an interesting approach. I think that you should have a grasp of technology if you want to be trusted in this space. It also depends on what you are doing because as you have yeah on the context because as you have mentioned if you're doing community management. You don't really need ah much of the tech skills.
Tim Benniks: Exactly, I completely agree. What’s interesting is that even if you have just a bit of tech knowledge, you can succeed as a DevRel by doing live streams where you learn in public. For example, if you’re new to development, you can host a live stream and invite a famous guest to learn together.
This approach shows how easy it is to get started with your product, even if you’re not super technical. It’s particularly effective for simpler products like CMSs. For more complex, technology-driven products, this approach might not work as well. Different contexts require different types of DevRels. For instance, I might not be the best fit for a database company because my knowledge of SQL is limited, whereas for other types of projects, I might be perfectly suitable.
Jarek Jarzębowski: How do you think AI will start to influence this? When I see something written by AI, I can tell immediately and often don’t want to read it.
Tim Benniks: Um, once again, the answer is: it depends. If you just let AI write something and publish it without any editing or human touch, it won’t be good at the moment. Maybe it will improve in the future, but right now, it’s not sufficient. However, using AI to assist you in structuring your thoughts, coming up with questions, and finding holes in your reasoning can make your writing better, whether it's for a blog, article, or script. So, you can use AI to enhance your content, but you need to know how to use it.
Jarek Jarzębowski: You need to have the skill to use AI, like ChatGPT, and understand where AI fits into the content creation process.
Tim Benniks: I agree fully. You need to know what you want to write about. If you write something that comes from your heart and resonates with your audience, using AI to fill the gaps makes sense. I’ve experimented with AI by providing a detailed brief and my thoughts, asking it to write in my tone of voice without sounding like typical AI. The result was decent and in my voice, but setting up the AI took almost as much time as writing it myself. So, I’m not sure how much it helped.
Jarek Jarzębowski: Yes, it can work, but it doesn’t eliminate the need for effort. We still need to work, focus, and know what message we want to convey. AI can be really helpful, but we need to know how to use it.
Another thing I want to discuss is your journey in DevRel. You mentioned learning the ins and outs of DevRel during your first job, but you’re also an ambassador for multiple programs. Did that happen before or after you became a DevRel?
Tim Benniks: It’s a bit of both. For example, I was in the first Cloudinary ambassador program, Media Developer Experts. I’ve used Cloudinary, an image delivery pipeline API plus a DAM system, since around 2015 on large projects. I loved their tools and used them in both professional and personal projects. In 2019, they invited me to join their program. Other ambassador roles came about organically.
My approach is influenced by my experience in agency work, where we focused on solving specific problems for clients by hiring the right experts for each project, rather than sticking to a single platform like Adobe.
The value-first approach, where you identify a specific problem to solve for a company, is the model I also use in my projects. Of course, I have my preferences for tech stacks, like Netlify or Vercel. I often use Nuxt with Vue because I've used it a lot in the past, but not always. When a new project comes along, whether it's for myself, a demo, or a partnership with another company, I figure out what I need. Once I find the tool that meets my needs, I use it. Over time, I’ve built a portfolio of tools I love, which I use consistently. When I discover a new tool that works better, I add it to the portfolio and retire others.
I never stick to one thing. For example, I love Nuxt and Vue, but I've built many projects with Next and React or Astro. I always become an advocate for companies with awesome products. I'll use them, speak about them, and provide feedback. I have a YouTube series called "Tim Tries," where I try something for the first time in a live, unprepared setting. This allows me to give genuine feedback based on my 20 years of experience. I might comment on an odd onboarding flow or button placement, but I always provide fair and constructive criticism.
This approach has led certain companies to reach out to me, or vice versa, expressing interest in collaboration. For instance, I've used Supabase extensively for personal projects, and after reaching out to them, I became part of their ambassador program.
Similarly, NuxtJS approached me, which was a pleasant surprise. With Algolia, I naturally became an advocate because I use their tool for search, filtering, and faceting all the time. Their product is so good that it almost doesn't need DevRel. It’s easy to set up, and it just works. So, if I'm excited about a product, I'll use it and advocate for it.
Some people are advocates for projects like NuxtJS and contribute heavily to GitHub pull requests and documentation. Personally, my priorities are different. I'd rather use and advocate for a product than contribute directly to its development.
Jarek Jarzębowski: Has being involved in these ambassador programs helped you in your current job at Hygraph? These programs are different from what you are currently doing. If they have helped, how so?
Tim Benniks: It's a bit of a back and forth. Being part of these programs is amazing. It gives you a sense of validation and makes you feel part of a community. This helps with social proof. When I say something on LinkedIn or Twitter, being part of these programs adds credibility. For example, if I’m talking about something in the Hygraph space, my involvement in these programs helps because I’m knowledgeable about the tools and partners. Additionally, having easy access to the founders of tools like NuxtJS or Supabase is beneficial. During customer calls, if a client uses one of these tools, I can provide insights or ask the team for premium support quickly.
On the other hand, these programs have helped me learn from other communities and share my work with them. For example, I can promote a live stream in these channels, increasing viewership. It’s a give and take. Running an ambassador program well requires a lot of effort.
The Cloudinary program is a good example. Initially, they had a budget for creators, allowing ambassadors to travel to events or buy equipment. Over time, the effort waned, but they have since refocused and improved the program. Company goals, such as being sales-led or product-focused, influence the emphasis on community. The NuxtJS and Supabase programs have always been strong because community is core to their product.
Running a good program is challenging, and I often say no to new ones because I don't want to be in another Slack or Discord where participation is minimal, but content creation expectations are high.
Jarek Jarzębowski: If you had to name three things that make an ambassador program great from the ambassador's perspective, what would they be?
Tim Benniks: Firstly, premium support from product people at the company, including founders or other ambassadors. Having direct access to the product team for questions and support is invaluable. Secondly, the honor of being part of the program. It’s great to mention at conferences, and it builds credibility. Lastly, the program should enable and inspire you to use the product as much as possible. This could include providing equipment or travel funds for conferences. While I haven't needed these benefits much, they can be incredibly valuable for developers from underrepresented regions. An overarching, important aspect is the sense of community.
Jarek Jarzębowski: This feeling of community can be very important but also tricky. It's difficult to foster a connected community from people who are not initially connected. How can you create a community out of ambassadors and foster these relationships not only between the ambassadors and the company, but also among the ambassadors themselves and the product users?
Tim Benniks: That’s a tough question, but successful communities share a few key aspects. The product itself should be incredible and provide immediate benefits, often through free accessibility. It should solve a real problem for developers, creating superfans who use it in every project. When you gather such enthusiastic users, there's a magical spark that can grow even with just a few people. Open-source projects often succeed here, as users can contribute, give feedback, and build upon the product, fostering a collaborative community.
Helping another community member without the involvement of an ambassador or a product representative is when things really start to get cool, right? To me, those are two key indicators of a successful community. Once you have a bit of scale and it's quite active, with people having lots of discussions, they start to make content about your product and post it in the community. Then people talk about that content. As your company or ambassador program grows, you can start doing things like hackathons or Q&A sessions with founders. This adds significant value to the community.
For many startups, the best community is one where Q&A can happen quickly. When a new developer asks a question and gets an answer within five minutes, it might sound weird, but that could be one of the most successful community aspects in certain startup spaces. Others, like the Next.js or Supabase communities, are more like home bases where people talk to their friends. So there are different types of communities. Does that make sense, or am I coming from a strange angle?
Jarek Jarzębowski: No, it's not a weird angle. Creating a community around a commercial product is difficult. It's not like gathering around a sport or a sports team you support. It is still a product and a business.
Creating a Kubernetes community, for example, is challenging. But I believe it can make or break a company. If you create a good community experience, it can help grow the company, the product, and the initiative. However, this requires a strong focus on the experience, especially for the initial members. You can't do it in an hour a week; it needs dedicated attention.
Tim Benniks: Exactly, the first week needs to be perfect. Focusing on the first ten guests or so is crucial. Even if you have more people from the beginning, you need to make it perfect for some of them because you can't focus on 500 people at once. This is why these programs tend to grow gradually rather than starting big.
The fact that a community grows organically and people want to be there is what makes it strong, even if founders might not like the slow pace. Often, communities start to decline when there are no dedicated people in charge anymore, and it just becomes an announcements channel. When that happens, it’s less interesting, almost like a company's Twitter handle.
For example, I do live streams for Hygraph on the Hygraph channel, not my own. It’s hard to get people to follow a brand because it’s not a person; it's just a CMS. However, we have 60-70 people watching each stream, which is good for a niche space like ours.
Growing a community takes time, and consistency is key. Being present and transparent, showing every product change, fixing issues, and communicating openly keeps the community engaged. Otherwise, it becomes like a brand’s Twitter where people join but aren’t active.
Jarek Jarzębowski: As we approach the one-hour mark, let's hope more developers think about communities in this way and that more such communities will appear for tech enthusiasts. Thank you, Tim, for sharing your experience and insights. This conversation could be very valuable for people in different spaces.
Tim Benniks:Thank you so much. One closing thought: DevRel is changing. You almost can't be purely focused on education anymore. You need to understand and engage with other disciplines in your company. If you can communicate with salespeople, partnerships, or developers, you increase your impact and job security. Understanding marketing, for example, helps you show the impact of your work using their terminology.
Jarek Jarzębowski: DevRel should build bridges, not moats. This applies to many roles in tech companies. Before we wrap up, where can people find you if they want to connect?
Tim Benniks: You can find me almost everywhere as Tim Benniks. Interestingly, my LinkedIn is now outperforming my Twitter ten to one. Also, check out the Slack community at hygraph.com. Our community has 8,000 members, and we'd love for you to join us.
Jarek Jarzębowski: Great, thank you and hope to speak to you soon. Bye!
Tim Benniks: Cheers! Thank you so much.
Tim Benniks’ Background
Tim Benniks is a Developer Relations expert at Hygraph, focusing on content creation and company perception in the tech community. His role includes producing videos, writing, social media posts, attending conferences, and measuring KPIs.
Previously, Tim progressed from Front-end Developer to Global Director of Web Development in various agencies, managing 48 offices and leading diverse development teams. His experience spans e-commerce, enterprise clients, and large-scale software systems, always balancing idealism with practical constraints.
An active open-source contributor, Tim creates video content, speaks at conferences, and serves as an MC for brands like NuxtJs and Cloudinary. He is skilled in Vue, Nuxt, MACH, Composable DXP, inclusive design, accessibility, and more, passionately creating sophisticated websites and advancing web development practices.
Closing Thoughts
Based on Tim Benniks' experience and the stories he shares, one conclusion is clear: there are many paths to DevRel, and there is no single universal recipe for success in this field. However, there are undoubtedly a few must-haves for any developer wanting to move into this area. Strong people skills, the ability to receive and act on feedback, and reactiveness are very important traits in DevRel.
His journey confirms that authenticity pays off. Additionally, effective DevRel should strike a balance between consistency and adaptability to industry changes. Technical skills are important, but not as crucial as they might seem – skilled communication matters much more.
