Let's start with you. Who are you, what do you do, and what does your company build?
I'm a Developer Advocate at Redis, with over 8 years of experience as a full-stack software engineer. I'm passionate about making complex ideas simple, helping developers build faster, more reliable systems, and understand the "why" behind the tools they use. My current work focuses on applied AI, and exploring how intelligent, real-time applications can be built using retrieval-augmented generation, vector search, agentic AI, and other emerging technologies.
Redis builds the Real-Time Data Stack for AI - a fast, flexible foundation for applications that need sub-millisecond speed, scale, search, analytics, and AI capabilities. At its core, Redis is a fast, in-memory database, and the broader platform supports capabilities such as caching, vector and hybrid search, Agent memory, and low-latency Context Retrieval for AI applications.
What does DevRel actually mean to you? Is it marketing, engineering, product, or something else entirely?
It's no longer enough to have great technology. You need developers to discover, trust, and recommend the products and solutions that you create. Developer Relations is that bridge between developers and the product.
Developer Relations is how companies build authentic, mutually beneficial relationships with the developers who increasingly drive technical decisions. It's about enabling, educating, and empathizing with the developer community, while simultaneously advocating for their needs internally. A good DevRel professional not only promotes tools but also ensures they're usable, loved, and continuously improved based on real-world feedback.
DevRel works in both directions: you speak for the company to developers, and for developers inside the company. How do you balance the two, and when have you pushed back on your own team for developers' sake?
When I speak for the company, my job is to explain what we build clearly and honestly, in the language developers use. When I speak for developers inside the company, my job is to bring back what they are actually experiencing (their questions, friction, misconceptions, and unmet needs) as well as positive feedback. Internally, I try to turn developer feedback into actionable input: what is blocking adoption, which part of the documentation or onboarding is unclear, and what would make the product easier to evaluate and use.
One example is during workshop onboarding. Even when a workshop or demo is technically correct and aligned with the product, it can still ask developers to spend too much time on setup before they reach the idea being taught. I have pushed for simpler setup, clearer instructions, and a faster path to get them to work.
Tell us about your community. Who's in it, how big is it now, and what helped it grow?
The Redis developer community is global and includes application developers, open-source contributors, architects, engineering leaders, learners, and AI builders. Two important parts of it are:
1. Redis Meetup groups: We've got local chapters running across APAC, North America and Europe. We use these local groups to organize sessions and workshops to bring developers together for technical deep dives, hands-on labs, AI-focused sessions, demos, and community activities. You can look them up here:
- https://www.meetup.com/pro/redis-community
- https://www.meetup.com/redis-london
- https://www.meetup.com/redis-bulgaria-meetups-society
- https://www.meetup.com/new-york-redis-meetup
2. Redis Discord community: An online forum where developers and Redis staff discuss projects, use cases, questions, and ways to build with Redis.
Over time, our communities grew through open source, hands-on events, and many ways to participate (from documentation and tutorials to meetups, workshops, Discord, conferences, and contributions). AI topics such as RAG, vector search, and agent memory are now bringing more developers into the ecosystem. We’re always looking for volunteers to help organize sessions, and for experts to share their learnings - so if that sounds like you, feel free to connect with me on LinkedIn.
What's a launch or campaign you ran that you're proud of? What happened, and what did you learn?
One campaign I'm happy about was a community growth initiative around Redis Meetups and workshops in India. Together with my colleague Bhavana, we approached it as more than a series of one-off events - local meetups created the initial connection, hands-on workshops gave developers something practical to build, and Discord kept the conversation going.
We focused the programming on problems developers were actively exploring, including real-time systems, AI and RAG, vector search, and agentic workflows. The result was a more repeatable engagement loop. Someone could discover Redis through a meetup, attend a hands-on session, ask follow-up questions in Discord, share what they were building, and eventually help organize or speak at a future session.
What we learned from this process is that community growth is less about broadcasting more content, and more about designing the next participation step. People return when they get practical value and can see a clear path to becoming contributors, speakers, or community leaders - not just attendees.
In a product-led world, the product is the marketing. How do docs, onboarding, free tiers and sample apps fit into your DevRel work, and what's one change that measurably improved developer adoption?
Free tiers should make it easy to evaluate the product. And sample apps should show how it works in a real application.
I also think we need to distinguish between two types of sample apps / demos:
- Learning examples are small and instructional. They help developers understand a concept and get started.
- Polished demos are designed for presentations, workshops, and customer conversations. They show what a complete product experience can look like.
These serve different audiences and should be evaluated differently. Learning examples optimize for completion and time to first success, and polished demos are meant for clarity, engagement, and how well they communicate the product's value.
One change I worked on was taking isolated demos and turning them into more discoverable journeys with a simpler setup. Instead of sending developers across scattered repositories and documentation, the goal was to give them a clear starting point, working examples, and a next step. We identified workshop completion and sample-app engagement - clones and forks, issues, pull requests, and repeat usage as the signals we should track.
What's your favorite piece of content your team has shipped, and why did it work?
One piece of content my team shipped that stands out to me is our AI Workshop: Build a RAG chatbot. I was one of the instructors, so I also had a close view of how developers experienced it.
What made it work was that it did not stop at explaining AI capabilities using Redis. We combined short sessions with hands-on learning, covering vector search, RAG, semantic caching, LLM memory, and agents. Participants had a concrete application to build, which helped connect the concepts to something real. It also made the content useful for a mixed audience of engineers, developers, and architects because people could go from the high-level idea to a working implementation in the same session.
How do you measure whether DevRel is working? What do you track, and what do you ignore?
When I first joined Redis, we relied on an internal tracker that mainly measured activities such as talks, workshops, events, social posts, content pieces, impressions, views, and MQLs or handraisers. It was useful for showing what we produced and how much attention it received, but it did not always show what changed for Redis.
Now, we still use those numbers for planning and reporting, but we now treat them as inputs rather than success metrics. We focus more on developer acquisition into number of Cloud sign-ups, agent recommendation rates, developer sentiment, third-party advocacy, and the influence of specific programs. For educational 1-to-many event, attendance is still a reasonable measure. The outcome is whether our work helps Redis get chosen, recommended, and trusted by developers.
"Talk is cheap. Show me the code." Linus Torvalds wrote this on the Linux kernel mailing list in 2000. How does that idea shape the way you reach developers?
In our talks and events, we usually make that idea very literal. We usually include demos so developers can see the finished experience and understand the problem the technology is solving. Then we give a high-level walkthrough of how the code is structured and how the main pieces work. We are not trying to read every line on stage. We are showing the path from the user experience back to the implementation.
That format works because it gives people both the motivation and the mental model. The demo answers, "What can I build?". The walkthrough answers, "How was this put together?" Developers can see where Redis fits, how the data moves through the application, and which parts they would need to change for their own use case.
We then follow-up with sharing github repositories that people can explore after the talk. That is important because the talk creates the initial understanding, but the repository gives developers something concrete to clone, run, modify, and use as a starting point. They do not have to rely on a slide or a recording to reconstruct the example.
There's a well-known saying that "developers are allergic to marketing." Do you agree? How do you reach developers without it feeling like marketing?
I agree with the spirit of the saying, but I would phrase it differently: developers are allergic to being marketed at. They do not want hype or vague claims. So when marketing to developers, credibility comes from being honest about the trade-offs. We should explain the setup, the architecture, the limitations, and when a different approach may be better. Developers can tell when a talk or a tutorial is really just a sales pitch. They are more likely to trust you when you respect their judgment and give them enough information to make their own decision.
Kathy Sierra argues in Badass: Making Users Awesome that the goal is to make users awesome, not to make the product look awesome. How does that idea show up in your work?
I strongly agree with that idea. In developer advocacy, the product should be the means, not the hero. A successful talk is not one where people leave thinking, "Redis has a lot of features". It is one where they leave thinking, "I understand this problem better, I think Redis can be a good fit, and I can build something useful with it".
In a talk, we show a working demo, then give a high-level walkthrough so developers understand how the application was put together. In a workshop, we do not extol a list of product features. We have participants build an exciting application themselves and leave with something that works - something they can show to a colleague, continue improving, and feel proud of. We also pay attention to where people get stuck and improve the instructions, examples, and prerequisites. That is part of making users awesome too (reducing unnecessary friction while still helping them build real understanding).
How did you first come across HackerNoon, and is there a story you've read or written here that stuck with you?
I first came across HackerNoon through Medium back in 2016. I subscribed because I wanted to read more writing about technology and AI, and I liked the mix of practical engineering articles, career stories, and personal perspectives from people building things.
One article I wrote there was "The Idea of an Invigorating Startup Life can Often be an Illusion". The article was about how startup life can feel exciting and innovative, but can also become exhausting if there is no room left for learning, family, hobbies, or life outside work. I feel that the central lesson is still relevant today. Being busy is not the same as growing, and intensity is not the same as a sustainable career.
Whose DevRel work do you admire most, whether people, companies or programs, and what do they do that others should copy?
One person whose DevRel work I admire is swyx, or Shawn Wang. I like how he turns emerging technical ideas into clear mental models through his writings. I have also learned a lot by working with my colleagues Bhavana, Samuel, Raphael, Ricardo, and Guy at Redis. Each of them has helped me think more clearly about technical depth, practical developer education, and how to make content useful and credible for developers.