Fireside with Voxgig for Professional Speakers

Aravind Putrevu

Episode:
137
Published On:
29/11/2023
Aravind Putrevu
Podcast Host
Richard Roger
Voxgig Founder
Podcast Guest
Aravind Putrevu
Engineer and Tech Evangelist

In this episode, we’re taking a break from our artistic stint of authors and podcast hosts, and moving back into solid DevRel territory with our guest Aravind Putrevu. Aravind is a developer advocate turned angel investor, but to leave it at just that would be a disservice. He has his fingers in many pies, including DevRel consulting, where he helps companies with their product marketing and strategy.

And of course, as any good DevRel or engineer should, he also has an itch to build something valuable, so he’s working on a SaaS tool that he’s still keeping in stealth mode. Aravind speaks to us about his transition from DevRel to angel investing and his propensity for startups and working with founders.

When it comes to the world of consulting, Aravind walks us through his role with a company, from strategy, to marketing, to introducing their brand to the public as a DevRel. He speaks about the culture of DevRel, how all too often a singular person gets hired to do the work of an entire DevRel team, both code and community, and how this overload leads to the inevitable cycle of burnout that he sees frequently.

We also chat to him about his work as a senior developer advocate at Elasticsearch, where he had the benefit of a large developer team working with a popular product that had insane traction. He says that Elasticsearch is a classic example of how DevRel can work when the founders are the first developer advocates.

Aravind is also a speaker who has given talks at many large conferences, and he tells us a little about how he coordinates a team where five people have all signed up to speak at the same conference. A happy problem to have!

Reach out to Aravind here: https://www.linkedin.com/in/aravindputrevu/

Find out more and listen to previous podcasts here: https://www.voxgig.com/podcast

Subscribe to our newsletter for weekly updates and information about upcoming meetups: 

https://voxgig.substack.com/

Join the Dublin DevRel Meetup group here: www.devrelmeetup.com

See Show Transcripts

Interview Intro

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

Today’s guest, Aravind Putrevu, is an angel investor who started out in developer relations. Now he helps startups in the dev tools space execute developer relations the right way. And in particular, we try to answer the question: is developer relations right for your business? [0:00:35]

Main Interview

Aravind Putrevu

Richard Rodger:  [0:00:36] Hello, and welcome to the Fireside with Voxgig Podcast. Today, we are speaking to Aravind Putrevu, who does a lot of things; Aravind, you’re a busy man. I’m going to let you explain to our audience all the different things that you do, some of which is to do with developer relations. [0:00:55] 

Aravind Putrevu:  [0:00:58] Staying busy is a subjective thing; I would say that. Because I’m not busy at all when you compare with the likes of Microsoft CEO, who is doing multiple things. [0:01:08] 

Richard Rodger:  [0:01:08] He’s a little bit busy at the moment, for sure. [0:01:10] 

Aravind Putrevu:  [0:01:14] At this point of time to your – I’ve already – I’ve been an engineer and did a lot of things. Built things and also been an evangelist, working founder. I do three primary things that are related to developer communities and founders. I do dev rel consulting as part of professional consulting, helping with product marketing, product strategy or community development. I would not say community building, but also development and more of that sort of thing, and content – doing some content around that. 

And after that, I also have an itch to build something over the years and then really want to build something valuable, productive and help people. I am building something in the SaaS area, and it’s more of a tool that helps the go to market teams. It’s a work in progress but I’m going to unveil really soon. And- [0:02:21] 

Richard Rodger:  [0:02:21] You’re still in stealth mode, but it’s going to come out. [0:02:22] 

Aravind Putrevu:  [0:02:23] Yeah, exactly. And then the third and recent thing, maybe it’s brewing for some time, but then I have not done a lot of stuff, is angel investing. I discovered that myself; I am very interested in startups and working with founders and markets and analysis and doing a lot of that. 

And I want to work with few founders who are amazing at what they do, their ideas, and probably help with my skills, and then also see if they could leverage my skills. So, creating a win-win for everyone, because I could probably introduce that brand, the developer brand, to the public. And also, where I invest in them and then I – the founder also finds that I have skills, so it’s a good partnership that I build. [0:03:13]

Richard Rodger:  [0:03:14] At the-

Aravind Putrevu:  [0:03:14] That’s not everything, but that’s what the trend is going on, that side. [0:03:18] 

Richard Rodger:  [0:03:19] Awesome. At the risk of destroying your inbox, are you mostly looking at startups in the developer tooling space, because that aligns with your skills in developer relations, or is it anything and everything? [0:03:33] 

Aravind Putrevu:  [0:03:35] My strong area is open-source data security and developers, so this is the area. I’ve done quite a bit of work for Elastic, for five years or so, and Elasticsearch is omnipresent, as you could see. And because of the nature of the product, I built relationships with several people, several communities, several domains in that space, use cases, whatnot. So, I have a very big-picture understanding of how people would want to pursue some things in the developer areas, and if we’re finding something really interesting, that’s when I think – I understand this is a niche and – it’s a space that needs to be solved. [0:04:19] 

Richard Rodger:  [0:04:25] Let’s focus on developer relations for a little bit, because that’s your background and where you gained a bunch of experience. One of the – I don’t know if it’s a controversy, but one of the things there might be a concern about these days is – is developer relations something that only coders should do or is it becoming more like an influencer – a YouTuber type role. I’m really interested to hear your thoughts on that, because we want to be as inclusive as possible; we want to get more people into this role. But is it – are we ultimately just influencers? Is that all we are? [0:05:10] 

Aravind Putrevu:  [0:05:14] Developer relations is for everyone; I would not say that – just like programming is not restricted. I would just want to tell one backstory. In the initial phase of my career, I used to think, you need to be a CS grad to understand and write distributor systems programming or something like that. But it’s a point; I found out an electrical engineer who excelled at building something that’s so complex, an algorithm. 

And it’s a really popular tool; several developers use it, or several companies use it. I realized that it’s also not about what study you do; it’s about the entire craft and the skill that you like to learn with. But that being said, I want to say that it’s not just for – developer relations is just not specifically for coders, but it’s also not just a pure play marketing technique. 

You need to know the art of – you need to invest in time to learn about the entire chain and then contribute some sort of value from your skill point of view to that. Maybe it is more about creating content or maybe it’s about strategizing and executing events, solving the logistics problem of going to events, network, social media, whatever, but it’s not just only one thing; it’s not just distribution. It’s more than that. And that’s what I find- [0:06:41] 

Richard Rodger:  [0:06:41] Yeah, I often think it’s a good job for bad coders. I don’t have computer science either; I did mathematics, but that doesn’t make me a good coder. It feels like it’s a good – it’s a great role for people who might be more generalist or might have an interest in more than just coding. Because you do events and public speaking and all that type of stuff. You do public speaking as well; you were – you’ve been in Toastmasters and- [0:07:11]

Aravind Putrevu:  [0:07:13] Yes, I did-

Richard Rodger:  [0:07:14] -you’re super professional and all that stuff, right? [0:07:15]

Aravind Putrevu:  [0:07:16] Yes. I did Toastmasters; I ran a club and it was amazing. I learned a lot about public speaking. I want to make sure that, like I said, everything that I tried to do, I do it at smaller places. I learn the skill to get through; get to know. And then I enter – because I know that developer relations, which I am aspiring, needs a lot of public speaking. I have spoken at more than 300 developer events: India, South-East Asia and Europe. Many places, even US. That’s what is very important. I just want- [0:07:48] 

Richard Rodger:  [0:07:49] Is that one of your – would that be one of your important pieces of practical advice for someone who is in a developer relations role or trying to get into one? Join Toastmasters. [0:07:59] 

Aravind Putrevu:  [0:08:01] Very much. It really helped me a lot. If you are aspiring to be a public speaker, which is part of your entire thing of developer relations. I just want to point out one thing, Richrd, here is. You said your have – your bad coder is a generalist who joined this, but one special skill you need to have is if you are able to articulate a story, learn something and convey in a matter. 

And again, articulating doesn’t need to be speaking, but also, you could write it and probably put it visually. Toastmasters makes you do all of this as well, so the – and raise it as well. It’s not just about speaking – yes, that’s a major part, but also, it’s about putting the text together. It’s putting and probably finding out – remove fillers from your speech, and how do you make sure that you use special words in your – there’s a lot of – how do you make sure that you can do a one-minute pitch [inaudible] Time: 0:09:09 – 10-minute session. More interesting things around public speaking and- [0:09:17] 

Richard Rodger:  [0:09:17] It’s quite technical; isn’t it? It’s not just get up and be confident on stage. Because specific technical things you need to worry about to do it correctly. [0:09:28] 

Aravind Putrevu:  [0:09:30] Yes, definitely. And it hasn’t come up in any podcast or any interview that I have done, but you brought in a right point. It’s technical, and Toastmasters is quite helpful for me in terms of thinking clearly and getting onto a stage and doing that. In fact, each Toastmaster club instance is like a play, and you need to prepare for it. There is roles that people take for it, and it’s very interesting. [0:10:00] 

Richard Rodger:  [0:10:00] Awesome. And I’ve spoken to other people in the past on this podcast who’ve been in Toastmasters or found it extremely helpful, so I always highly recommend it, even though I haven’t done it myself – I really should. I want to put a scenario to you, maybe two scenarios, two – a scenario – we’ll break it into two parts. 

Based on your experience with developer relations, based on the consulting work you do – and you’ve worked in Elasticsearch like you said, but also with startups. Let’s say I have a developer tooling startup and we’ve got an API and an SDK, basic website. We’ve got a seed round, so we can finally afford to hire a consultant. 

This is the startup scenario. Let’s – walk us through how you would help that startup. They’ve just hired you, day one, and they’ve built the system, but apart from maybe the founder tweeting or having done a few conference talks, they don’t have developer relations as an activity; they’re starting from zero. [0:11:19] 

Aravind Putrevu:  [0:11:20] Yeah, very interesting. One of the things with startups especially is, they have a shop window to find the PMF, and you get the runway from a seed. And then you should find PMF and you should find that repeatable, executable thing that is – I would not – if you are selling, it is considered negative. But everyone needs to make revenue and everyone needs to sustain. 

So, they should find something that is valuable, but also monetizable. And that’s where, whenever someone talks to me about, how do I go across, probably amplifying this. If they’ve already found the PMF and they know that it’s valuable, I would ask for their goals, in respect of this way or that way. You benefit; they don’t find whatsit. 

But if they have to take it to the developers and want to introduce it to the larger market, it’s about goals, and what are those goals that they want to do. Because at the end of the day, if they are raising A or B or C, the next round, it’s important that they understand that. The investors will eventually ask about, let’s say, stars or some metrics around that. Contributors, if it’s an open-source project, or if it’s an API- [0:12:36] 

Richard Rodger:  [0:12:36] Do you think, Aravind, that you need to have product market fit for series A? Series A doesn’t happen without product market fit. [0:12:43] 

Aravind Putrevu:  [0:12:43] Yeah. It’s a very interesting question, because with the times, it kept changing, the zero interest rate phenomena, which happened. [0:12:53] 

Richard Rodger:  [0:12:54] Easy times. 

Aravind Putrevu:  [0:12:56] It is – it doesn’t matter. All that you need to have an idea probably something on the web, and you get funded. But now, even established startups which has quite a bit of traction – I meant to say quite a bit, maybe a million developers, in using them, and a lot of engagement – needs to justify that yes, we can make probably 10-20 million revenue out of the first few years. It’s quite a big situation to raise money at this point of time. [0:13:28] 

Richard Rodger:  [0:13:30] What we’ve seen sometimes in our work is startups that have struggled a little bit with that. They might have a great technical product, and I know of one in particular that took a very developer first approach, so they had a lot of developer relations activity. And that didn’t work for them. 

They have repositioned now to be much more enterprise-sales focused, more traditional. They have SDRs and all that sort of stuff. I don’t know whether it was the type of product or who they were selling to, but it’s a little bit of a case study in – their developer relations execution was pretty good. 

How would you identify that situation where – let’s assume the root cause was, it was the wrong route to market; they shouldn’t have focused on developer relations. If a startup comes to you and says, “We need to do developer relations,” under what scenario would you say, “No, this is not right. This is not the right approach.” [0:14:40] 

Aravind Putrevu:  [0:14:43] First of all, how you exactly put it out. If it’s a top-down sales product, if nothing is accessible right from day one. And people need to give away their – not just email, but book a 30-minute call with SDRs to understand what the product is. Then the product is not consumable off the shelf. Like I said, I have a lot of background from open source and data security that – but that being said, even Slack, which is a SaaS platform, proprietary – it’s not open source. But they have a marketplace of apps and they sell an API; they have apps and all – a lot of that stuff. 

If you see for them, at the end of the day, they are doing top-down sales probably, or PLU, product-led growth motion. They still have an API that they sell to developers, and then they potentially have a motion.  But then if you have completely closed, and that’s something that may be not exact fit for developer relations, you could still do some sort of product marketing, which is doing some content around – top of the funnel content. More in the marketing sense, content marketing, building some brands, learning new stuff. 

Somewhere between this community led growth, bottom-up motion in the marketing area, this area, and then the top-down sales, there comes the PLG flow, wherein people can sign up. And that’s something still – it’s evangelizable; it’s something that developer relations is still needed and doing that. One fine example in recent times. There are many companies, but then obviously, they are all as a developer tool, very popular, very awesome. Twilio, very popular developer tool. Bunch of companies, they have executed around this really well, and quite popular for what they do. [0:16:33] 

Richard Rodger:  [0:16:34] The other scenario is – and that is probably more important for you in terms of putting bread on the table, because startups tend to have constrained budgets, is – and this is a question around your developer consulting work. Which is where you have a more established company and maybe they have sufficient traction, but they now need to professionalize their developer relations. 

How would you approach that scenario? I’m hiring you – the company’s three years old and we have users. We have product market fit, break even; we’re probably looking at a series A soon. But I as the founder have been doing all the developer relations personally and now I need to start professionalizing it. So, is that – maybe that’s a better match; maybe that’s more of an ideal customer for you, because they have money. [0:17:27] 

Aravind Putrevu:  [0:17:28] Yeah, but most of the times, folks like this, they are still not sure that they need to hire a head of dev rel, a head of community, if they have a community, a Slack group. And then I need to hire a developer advocate, who could do this. Both are ideal, but it depends on the longevity of the entire initiative. 

If you want this to be a perennial thing and that continues to stay relevant to whatever the enterprise thing that you’re going to pursue. And putting up a head of dev rel and then hiring people and few GOs, very apt for someone like databases, data platforms. Because they have to grow and they have to continue to be in the market. But not so for a lot of companies that has one API and one SDK. Orr a bunch of SDKs around the API, but their entire platform is closed-source. They’ve still got quite a lot; CRMs are not very much there. 

For that area, you could get away with consultant for initial time and then eventually hire a few people and then they could still report to the go to market. Or it depends, because it’s still a top-down sales model. But for the open-source area, you could start at either hiring someone from the community, customer community or open-source community, whatever contributing, 

I would 100% recommend, please consider hiring someone community that does a lot – goes to the user base that you have. Shows that the goodwill nature, and you also give somebody the opportunity to build their career on something that they trusted initially. So, it’s a lot of good things that happened together. 

Also, a lot of – many people over-index when they try and do developer relations. Thinking about, do I need to get somebody in the experience area. Even though they are really good developers themselves, they don’t give another chance to someone who could – who’s been a developer and be able to articulate and probably do these events. They could put someone like an engineer still in this rule and tell these are the things that we need to do as a company. And need to- [0:19:40] 

Richard Rodger:  [0:19:40] And some engineers volunteer for it, because they’re attracted to the – doing the developer relations. One – I don’t know if it’s a mistake. One – but one thing that I’ve seen happen – and people have told me this has happened them – is they get hired, not as a head of dev rel but just as a developer advocate, the first and the only one. And then they’re expected to deliver all of the work of a developer relations team – code and content and community. And there’s sometimes a very unrealistic expectation on one person. Have you come across that? Have you seen people – have you seen that happening to people? [0:20.24] 

Aravind Putrevu:  [0:20:24] So much, so much in the dev rel area. There’s a lot- [0:20:26] 

Richard Rodger:  [0:20:27] Burnout is a thing, right? 

Aravind Putrevu:  [0:20:28] Yeah, there’s a big boulder that everyone tries to push out in respect of what about the state of company that they were in. Because there’s too much, but also, you should think about from the founders another angle. It’s like there’s too little to hire somebody to do some of it, even text, unless they are doing a tail. Unless they could also find, fill in that position from marketing angle as well, so that someone could get on the loan and do 30% of the work for dev rel, helping the dev rel – developer teams and all. It's a big thing and it’s ongoing and quite a few people still feel that. [0:21:09] 

Richard Rodger:  [0:21:09] Yeah. It’s a lot of work; developer relations is a lot of work. I’m interested in your personal journey into this space and how you managed to end up as a developer advocate, and now as a developer relations consultant. You learned an awful lot. You worked at Elasticsearch for quite a number of years; I guess you learned a huge amount there. If you don’t mind, I’m interested in how Elasticsearch structured their developer relations activity, if you can talk about it much, in terms of how bing were the teams and how did they do measurement? 

And did they – were they happy with it? Did they keep reorganizing and trying different things? Did they move it from – you’ve heard of people moving developer relations. It’s from engineering and it moves to marketing and then it moves; it’s – reporting to the CEO. So, I’m interested in what Elasticsearch and you learned from those years. [0:22:10] 

Aravind Putrevu:  [0:22:12] Now it’s nearly – not nearly one year past. I exactly don’t know the structure and everything, but when I was there a year ago, it was a large scheme. It always have been, and we are – Elasticsearch itself is a very popular product that was built by developers and pushed by anybody of us. It has insane traction, and create a developer cred, that everyone wouldn’t think of using. It’s which solution I would use it for? Can I use this now for making bread, a baguette, or whatever? It’s in different forms. The founders themselves have done quite a bit of this developer work. And- [0:22:56] 

Richard Rodger:  [0:22:54] Yes. And it’s a good case study of the founders being the first developer advocates, right? [0:22:59] 

Aravind Putrevu:  [0:22:59] Right. And one of the very first advocates literally got all the training, education, deep dive knowledge. David Pilato was advocate measure of France, and he got directly from Shay Bannon, who was the creator of Elastic at that source. And it shows the efforts the founders have made. 

And even still today, one of the founders runs the – one of the conferences, if I’m not wrong, Berlin Buzzword. I don’t know if it’s still urning or not, but such conference very popular still in certain circles. And that shows that it’s evolved, that they put in the community of developers; it’s a strong brand. 

We were 20-25-people team at its peak, and we were structured geographically; each one were individual contributors. And I was looking after India and South-East Asia for the initial days, and I have a co-worker alongside, a colleague of mine, and she used to look at a program from the program’s perspective. 

She used mange all the programs; I’m more like a technical counterpart. In the enterprise world, you could call a field CTO, someone who looks at the thing, helps with identifying events. While she could probably do more things around it, I would do more – this is how this event is not a good fit for us, right fit for us. Less price, right fit. That’s worth more money. More of the idea and strategy behind it, and I would eventually go and speak. 

But we discussed – I used to do – initial times there were no-one around me, and then I have pushed all the things myself. I used to do 40% of the programs, content, sometimes 20%, maybe less. And then a lot of travel events, where undermining. It was really hard. I used to travel for 70% of the time, including- [0:25:03] 

Richard Rodger:  [0:25:03] Wow, that’s hard; that’s a lot. 

Aravind Putrevu:  [0:25:06] Yeah, it’s very hard. 

Richard Rodger:  [0:25:06] That’s a lot. 

Aravind Putrevu:  [0:25:07] But it’s a fun and engaging enterprising career for sure, those five years. And at this moment- [0:25:16] 

Richard Rodger:  [0:25:16] One question I have for you. With the travel, you were travelling to speak at conferences mostly. How did Elasticsearch choose which conferences that you spoke at? Did you – did they just say to you personally, apply to – just pick the conferences yourself? Was there a strategy, or was it just, “Great, we got a speaking gig at a random conference, so we’re going to go.” Was there a plan? [0:25:42] 

Aravind Putrevu:  [0:25:42] Yeah, there was elaborate plan at the end of the day. There wasn’t any specific strategy – let’s go and target these. Maybe it’s now happening across the brand, even for Elastic; they’re doing more AI stuff as you could see now, right now. But then otherwise, it was not exactly like just get any target or something, or let us target these conferences. But we did have some plans, and that’s driven by someone like me, in this area. David for French and someone else for the German-speaking audience and someone else for the UK and someone in the US, West Coast, East Coast. 

All of this is divided, and another one that looks at what are the popular dev ops conferences that developers would go, and what are the sponsorship tiers. And these are events – I mean t to say developer events. And there are events which still qualify into developer and marketing, where marketing would want to say, “No, I’m going to be there,” like say, RSA, and say KubeCon. It still falls under developer thing, but also, it’s a brand and everything. So, more of that. 

We have these quarterly budgets, and we used to – before fully dividing into GO and all, we used to have docket land reporting, where there is a programs leader for the entire program, people that all report to a developer advocate leader. And eventually, both programs and developer advocate leaders report to our director of community. That’s how it used to work. But then eventually, we also divided as we grew as a company and graduated; we spread GO-wise and we had the same structure applications- [0:27:16] 

Richard Rodger:  [0:27:16] I’ll ask you about a particular problem that happened to me once. I was – when I was working as a developer advocate, I used to put in CFPs to speak at conferences. And one day I got a call from a conference organizer, saying – and he was unhappy. And he said, “You guys are spamming me,” he said. Because in my company a number of other developer advocates and engineers who spoke at conferences had also submitted to the same conference. 

And he’d got five different proposals from one – from the same company. And I had to say sorry, because we don’t coordinate. Did – how did Elasticsearch solve that problem? Because for us, everybody had their own personal spreadsheet that they were planning with. Was there some way to coordinate things in Elasticsearch or did you just all do your personal planning? [0:28:09] 

Aravind Putrevu:  [0:28:10] What we used to do is pool up all the events in a centralized GitHub repository, and we have a specific structure wherein we track all the events. It’s common across many brands. I’ve seen people build custom tools; some companies in Europe, they have built custom tools for doing these things, and also track CFPs. But otherwise, we used to pool all the events. At some point, it also manifested into an Airtable doc as well, but then otherwise, we have this GitHub where we post any events, say CFP and say that, “I have some of it here. And then you know that the colleagues- [0:28:46] 

Richard Rodger:  [0:28:46] And then you can see. 

Aravind Putrevu:  [0:28:47] Yeah. And we see about – we would go first and check that. An we would – if someone discovers, they’d check. If not, test what it’s like, and put it up in the GitHub or place, and that’s how it used to work. Now other thing I want to say is, we are all GOs at the end of the day, and- [0:28:47] 

Richard Rodger:  [0:28:47] Yes. That helps as well. 

Aravind Putrevu:  [0:29:06] And then would not eventually find some event, interesting one and do it, unless I specifically want to speak at Strange Loop, which is a very interesting, popular conference in the US. And I would want to go on my own and I would ask my manager, say, “I just want to participate, speak at it.” [0:29:23] 

Richard Rodger:  [0:29:24] Yeah. This is the sort- 

Aravind Putrevu:  [0:29:24] Something like that, which is a thing that I really want to do, or something like that. [0:29:30] 

Richard Rodger:  [0:29:30] And when you would – one of the things I would also do is, it wouldn’t just be me going alone – there would be a team and they would have a booth. Was that part of your work as well in the developer relations? Did you have to organize booths, or was that- [0:29:47] 

Aravind Putrevu:  [0:29:47] No. 

Richard Rodger:  [0:29:47] Or did – was that – did marketing do that, and then you coordinated with marketing? Or how did that work? [0:29:51] 

Aravind Putrevu:  [0:29:52] I want to divide this into an answer one – answer each. Every CFP event that I submitted or I got a chance to speak at every conference, it’s not official or it’s not sponsored at all. It’s just that I individually go and present and do the talk, meet developers; network, engage, build connections. That’s the subject; that’s how it ends up. 

Now on the other hand, if it’s something like already someone is sponsoring, we are sponsoring, we also have a speaker slot where we could – it’s something else sponsored, but I submit a CFP, it’s selected and we speak at it. And there is probably somebody – when there is a booth, I’m not the only one. 

There’s going to be someone else as well, at least two people, even in the same GO or device. We have engineering team who could join or who could have joined us or my other co-worker who is in the area as well, so they would join us. Or the community members who are very excited, like community ambassadors who are there; they would join as well. [0:30:52] 

Richard Rodger:  [0:30:52] They come with you as well. But who coordinates all that? WAS it the marketing department who coordinated that activity? [0:30:58] 

Aravind Putrevu:  [0:30:58] Like I said, in developer relations, we have this program called Natural Program Measure. [0:31:03] 

Richard Rodger:  [0:31:03] Gotcha, okay. There was a specific person. 

Aravind Putrevu:  [0:31:03] Who is that person, with logistics around the event, sending the banner for the booth and preparing that. Discussing all of those aspects and not the technicalities of what should the dev rel be or what are the things that we need target. What content to be there on the booth? On what value should do. 

They spar ideas and then come out with something. Sometimes to be honest, the program colleagues are awesome, and they don’t need anything from me, and I’m just there to do the technical and developer work I used to enjoy. And they used to lift all the non-technical area, which is a thing. And I did do- [0:31:40] 

Richard Rodger:  [0:31:40] But sometimes you have to do it all yourself as well. 

Aravind Putrevu:  [0:31:43] I did, which I did for the initial part of 2017-ish, 18 time, I did. Until they hired someone, which is really cool. [0:31:50] 

Richard Rodger:  [0:31:51] That’s the thing about developer relations as a job, because sometimes it involves physical labor of moving cardboard boxes and swag around. It’s an interesting job. [0:32:01] 

Aravind Putrevu:  [0:32:01] As we speak, I still have a bunch of candies and table cloths,  stickers, all those. [0:32:09] 

Richard Rodger:  [0:32:10] You never have to buy T-shirts again; it’s one perk of the job. 

Aravind Putrevu:  [0:32:15] I’m wearing a project T-shirt right now. Sometimes, it’s like my colleagues always say, “You take half of the cupboard space all the time.” [0:32:21]  

Richard Rodger:  [0:32:21] I know. Aravind, it’s been really fantastic talking to you; we’ve come to the end of our time. I have one final question. If you could go back in time to the start of your career, would you choose developer relations again? [0:32:36] 

Aravind Putrevu:  [0:32:38] Very much. I would choose developer relations. I even want to do more, structure it more; maybe I do more content. I’m envious of a lot of people who have structured it really well. And also, aspirational and admire their efforts in organizing themselves really well. I was not really good at some of these things, and that’s what I always continue to improve. [0:33:05] 

Richard Rodger:  [0:33:07] Fantastic. There is hope for us yet; there’s hope for us yet. Thank you so much, this has been fantastic. Take care. Bye-bye. [0:33:13] 

Aravind Putrevu:  [0:33:13] Thank you, Richard. 

Richard Rodger:   [0:33:13] Bye-bye. 

Aravind Putrevu:  Lovely. [0:33:14] 

Endnote

Richard Rodger:  [0:33:15] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time.