• DevRelX Blog

Episode Transcript: Between the developers and the business

This is a transcript of the DevRelX podcast episode with Vera Tiago. If you prefer to listen to it, click on the player below, otherwise keep reading!


Stathis: Hello, and welcome to the DevRelx Podcast, I'm sure you noticed the new name and image. In case you missed the announcement, I will just quickly bring you up to speed. We changed the name as DevRelx is more than a collection of resources. It is a community of developer marketing relations and advocacy professionals. It is still full of resources and the bi-weekly digest in your inbox, with a few addons. The episode format will remain as you know it, welcoming guests and learning from their experiences. Only now, you have the opportunity to get together with awesome people like yourself and talk to them. Announcement over. Let me introduce today's guest who by the way, is a super awesome member of the DevRelX community. And it's Vera Thiago, the Developer Advocacy Manager at OutSystems. Vera, welcome to the show.


Vera: Hi, and thank you for the warm welcome, Stathis. I'm very happy to be here today.


Stathis: And I'm very happy to have you. So, let's get to know you first. As a child, what did you want to be when you grew up?


Vera: Oh, tough question. You know, I never had a super passion for anything in specific. I remember when I was a young kid that I wanted to be a veterinarian because I love animals, dogs, cats, horses. But then when I was finishing high school, I was not sure what I wanted to be. So, my mom wanted me to be a nurse, like my sister or a teacher, but I was not sure. There was one thing that I was passionate about, which was computers, and I was very good at it. I was the go-to person in high school regarding computers. So yeah, I didn't know what I wanted to be. So, I decided to go to computer science engineering. So, I was a software developer.


Stathis: Yeah, that's great. I think you know when you're a child, you kind of like everything. So, everything is possible. Loving animals is great. But yeah, it's computers that won your heart after all. So, do you want to walk us through your journey, from child loving computers and becoming a software developer to all the way to your current role?


Vera: Yes, sure. So, after finishing college, I got my first job as a software developer. So, I did PHP for a while and some .Net. And then I decided to move to another company because I wanted to have new projects, new languages. So I was kind of moving to different companies to embrace new technologies and learn new things. And at a certain point, I decided to join OutSystems, which is where I am today. So as a full-time job software developer, I was also able to embrace another part-time job, which is giving classes at the university. And that is because I love to code, but I also love to teach. This is important because I think this explains why I ended up in this area of developer relations. So, at OutSystems, I was a Senior Software Developer and Technical Lead for a while. And at a certain point, I did a move to become more like a trainer. So, for two years, I was in charge of training developers, new developers, that were joining OutSystems, I was the one doing the training, the hands-on training, as well. So, kind of teaching them how to code with OutSystems. And then one day – this is really funny because I still remember that day like it was yesterday – my former manager called me on the phone and asked me this question: “Vera, do you want to change the world?” And I was like, “Yes, of course. Tell me the details.” Even without knowing the details, I said yes because I knew that was something exciting, that was coming. And then he said; “So, Vera this is the thing, there's one thing that can kill this company, and that is developers not wanting to use our product.” And I was like “wow, yeah, that's true”. So, I joined my former manager and the product management team and we created a small team that we called Ignite. Because our goal, our main goal was to ignite the community of developers. And we started together in this journey. So, I was a solo Community Manager for a while, developer evangelist. I was doing a bunch of stuff, while we were putting our programs in place. By that time, we launched many programs, there was one in specific that was fundamental for us to be able to grow the team to the point that we have today, which was we created a super users program or developer champions program, or what the name, you know, the field want to call it. But it was the MVP program, so most valuable professionals in OutSystems. That was a team of 20 people, community members. So, developers were part of our community, who joined efforts with us and became our extent. They were the ones organizing user groups, meetups, replying on forums, creating content, etc. And that allowed us to have more bandwidth to do the other stuff and to be able to grow our team. So today, I am a manager, so I still do some heavy lifting, like joining my team in doing presentations, creating content, etc. But yeah, I'm more on the management world right now.


Stathis: I'm sure there are many developers out there are who are happy that you answered yes to this phone call. Sounds like it's been a great journey already, but still, there are a lot of things to do. So, this is really great to hear. Thank you for sharing it. Now, I do love data, and this is not new. So, let's talk a bit about data. Can you please pick a graph from devrelx.com/trends, and tell us what and why it stands out to you?


Vera: That's a challenge because there's so much good data in there. Okay, so I will pick one. So, I will pick is the first one or one of the first ones that are on the page, which is related to the most important features that companies should offer to support developers. And this is great data, because essentially, what it tells us, is what you need to provide developers for them to be successful. And this goes back to fulfilling the basic needs. So, if you look into Maslow's framework, you need to fulfil the basic needs before you fulfil the psychological needs, right? If you look at this data, it says that the most important thing is documentation and sample code, and then tutorials and how-tos and then development tools, integrations and libraries, which is kind of an extension to your product, or a way to implement with our product. And this is really valuable for someone that is doing developer relations because there are so many fresh ideas that we can run into and I want to do this and this, I want to tell developers about my product, but essentially developers are not interested in the benefits of your product, and we usually go into the trap of “okay, these are the benefits, but first they want to understand how they can use it”. “Am I going to be able to use this, how can I use this, will this bring benefits?”. This is the third question. So yeah, documentation and sample code are obviously the baseline or the thing that will address those basic needs. And we should have that in mind. That there should be a core practise on developer relations teams. Because then it comes to all the other things that you can offer on top of those basic tools that will serve them. So, I really like this data. It’s kind of a sanity check. Sanity check that we are doing okay, we are doing right, so let's continue to do this.


Stathis: Yeah. I really love the way you connect it. I don't think I've heard it before and I really liked it, you know, the parallel with Maslow's hierarchy of needs, like the pyramid and then documentation in the bottom, you know, followers of this podcast, definitely know by now how many times this has come up, how documentation is your starting point, and how it should be like, the first thing you do. I also like the other point that you made, you know that they don't really care about their features, about the features of your product. And we already how allergic developers are to marketing or promotion, I’ll use promotion, as a more specific term. They're trying to solve problems, right? So, they will look into your documentation to see how long it will take them before they can actually start solving the problem they're trying to. So yeah, this has been great, and thank you for sharing it. Moving a little bit past data to talk about developer relations. We just started talking before the recording, And I want to mention, how we were saying that developer marketing, developer relations, developer advocacy, and evangelism are actually different things. You know, there are a lot of differences in what each person in each role does, but the ultimate goal is the same: to help and empower developers. So, for the purposes of this episode, we'll be using the term Developer Relations, more like an umbrella term about the whole process of working with developers and helping them do their best work. So, with that out of the way, what is your favourite thing about developer relations?


Vera: Can I say two things?


Stathis: You can say as many as you like.


Vera: So, I have two favourite things, and I'm not sure what is the one that I like most. One is obvious: connecting people. Being in his field means that you are constantly meeting new people and engaging in very interesting conversations. But it also brings other things, which is, you can go from ‘I love people’ to ‘I hate people’, right? Because it can be a really exhausting job. But yeah, overall, this is one of my favourite things. It is about getting to know people, creating a community, you know, being involved in this community, because as soon as you gain that trust, they become part of your family, and they become very active on a daily basis, and they work with you. So, it's really awesome to be able to explore these energies and these relationships. Another thing is the opportunity to learn new things. This job requires us to be learning new things every day. So, this is a job related to technology, right? And technology is in constant evolution. Every day, you get new technologies, new ways of doing things. And as a professional in the Developer Relations area, of course, you need to master your product right. So, you need to understand how your product can help developers whether it is on their professional life or pet projects, but you also need to be aware of how it compares to other offers, that are in the market. We need to be informed people so that we can have informed conversations because otherwise, you will look like you have been brainwashed. Like, oh, you only see your product, so, what about this in this, this? Why should I use this rather than this? What are the benefits? So, you should be able to have informed views, you should be learning new things. And so, one of the things that keeps me motivated every day on my job is, I have so many things to learn. I have so many things that need to be done and so many things to learn that I keep being super engaged in these fields and wanting to learn more, not just about products that are out there that can serve developers, but also tactics that you can run to help developers succeed. For example, there's a huge conversation online about developer education, because there's a lot of noise online, there's a lot of streams, documentation, blog posts, samples in ways that you can go, and help developers to learn. So, there are also cohort-based learning courses that are something that many teams are trying to explore. I've always tried to understand how we can leverage different initiatives or ways of doing things to help developers be successful, and learn our technology. So yeah, connecting people and learning things. Two very exciting things that I love about being in developer relations.


Stathis: It’s great to be able to have connections you can build with people in this field. And you know, because you're tackling problems together, it can be a real bonding experience. And, of course, as you said, it's the industry itself, that changing every day, and it's the whole mission of the industry to like to change to bring new things to make our life, make our work easier. So, yeah, I don't think the learning process ever stops.


Vera: Yeah, and you know what, and this is something that will continue for a while because there are not enough developers, and there never will be enough developers. The number of companies and startups creating products to increase developer productivity will continue to increase. New products will appear, new APIs, new frameworks, just to help developers because there's not enough, right? So, while that's not enough, we need to make sure that the ones that exist, use their time efficiently, they are productive. So yeah, so this world will continue to explore.


Stathis: Yeah, it will. And now, I’ll change the subject a bit, because we're just talking about the things you love, things that are great. Let's see the other side of the coin, what have been your biggest challenges in developer relations?


Vera: Biggest challenges. So, one of the biggest challenges that I had, and still have is about balancing the interests of the company, and the developers. So, you need to serve your company, but you need to serve your developers. And I would say, you need to serve developers, but at the same time, serve your company. So, for example, more and more, we see DevRel teams moving to the marketing department, and developer relations combines two different worlds: marketing and engineering. So, you need to marry the best of marketing to the best of engineering. And because you are the one that knows best this audience, there's a challenge in keeping an authentic voice when trying to communicate with them. As DevRel is getting more visibility in companies, they will want to leverage DevRel to marketing to developers, which is a good thing. You usually say that developers hate marketing, but I think developers hate bad marketing. We are the ones that should be able to help marketing and speak to developers with an authentic voice. This is one of the biggest problems, which is balancing the developer’s interests and the company's interests. From a personal point of view, and as a professional myself, one of my biggest problems and something that got me stuck for a while in my career was, I was not a data-driven person in the past. So, I struggled a lot in getting management buy-in and justifying what I was doing. I was getting very offended when people say, ‘so what is the risk of us killing this initiative?’ And I was like, ‘What do you mean killing this initiative? This is super important.’ And then I was not able to justify why this was super important. I was the one that believed that what's more than a click, and I still believe in that. I still believe that creating meaningful connections, in authentic relationships with developers is the most important. But at the same time, I think there needs to be evidence of the impact that your work is having. So, you need to have data to measure the success of your new initiatives, while you are building these meaningful relationships. So, I think I overcome the challenge over time. So, I learned to love data. And right now, I simply adore dashboards and having, going into deep conversations about data. It's a new me today.


Stathis: All I can say is ”woohoo”. We're data people here at SlashData. We love dashboards, we create tons of them, we're really happy when you can actually use this data that can help you in your career, like help you make decisions, or, as you just mentioned, justify to upper management why you need to do this effort, why you need more budget. So, that data-driven is actually in our culture, in our internal company culture. So, we love data-driven people all around the world.


Vera: Yeah. Data is awesome because data tells you the story, right? So, if you embrace data and learn how to observe it, yeah, data tells you many things. Of course, if you are a good feeling person like me, I always rely a bit on my gut feeling. And then I go after data to prove that my gut feeling is right, I think you need to balance these two worlds. Good feeling and data.


Stathis: Yeah. But when both are aligned, it's like, the best green light you could ever get.


Vera: Yeah, for sure. True.


Stathis: So, we talked about challenges, but you know, with challenges come like, also lessons that you learn. So, can you tell us one thing that you tried and failed at, but actually taught you a valuable lesson?


Vera: One thing that I failed? So, I don't have a specific, you know, a story in mind. Of course, there's plenty of them about things that went wrong. Yeah. But essentially, one of the things that I think I failed in the past was, and I still struggle to avoid that today, is about embracing too many things at the same time. So, at Dev Rel we tend to think that everything is our job, right? Because we understand developers, we know what is best for them, we think that we can solve everything. And that makes us sometimes fall into the trap of getting involved in too many things, like minor things, and then none of those things will bring a huge impact. And they are just draining your energy. So, I really like this analogy of, if you have a glass and if you keep filling in with sand, there's no room for big rocks, right. First, you need to fill in that glass, or that bottle with the big rocks and then fill with sand, which is the minor things that you should be involved in. I was not able to prove the value of the work that I was doing. And I almost quit this area, because of that, because I was feeling very overwhelmed. I was drained. And then, as the things evolved, I started to realize that, yes, so I am the one that should be able to identify; Okay, we need to fix this. But I also should be the one in charge of “okay, I know this needs to be fixed”. I will give a heads-up to the right team. Identifying the right team to pick this is also a skill, it's something that you need to learn as a DevRel. Because not everything is in your hands. And probably there are other teams in the company that you should work with. It's important that you don't work in a style or it's important that you have this collaboration, this cross-functional collaboration with other teams, and you understand how you can hand over those problems to that team. And of course, that brings a new skill to DevRel, which is how you build influence internally. This is also a lesson that I learned which is: your work is not just about the work that you do for the external community, but the work that you do with your internal teams and colleagues, it needs to be a collaboration. You need to be able to identify when that problem should be addressed by the Customer Success department. Because there's a high-level journey, developer journey which is “try, trust and transform”. They try your products, they trust your product and they keep using it and they evolve. When they go to this, okay, they already trust your product and evolve. Maybe that is a responsibility to other teams like customer success. So that's an example. Unless your team sits under Customer Success, which is a different conversation, which is where the DevRel team should sit, and depending on where it sits, you probably will have a different focus. Having a focus ties back to what I was saying, which is embracing too many things at the same time. If you identify where you can bring value, and where you should focus, you can easily overcome this challenge. This is one of the lessons that I learned along the way. And I still try to carry it with me because it happens today. Every week, there's a new team reaching out; “Oh, can you help with this? Can you help with this?” And our immediate reaction is “yes, of course, we can help because we know how to help”. But sometimes we need to say no, in a way that it's not “no, I won't help you”. But “okay, this is what you can do to handle this situation”. Then we kind of provides such support rather than jumping with high touch support to the team. So, it's a balance.


Stathis: Yeah, wow, I got to say, this is pure gold, everything you shared. If I may add just one small thing. You mentioned earlier that developer relations sits, more or less, in the middle between engineering and marketing. I would add that, it's like in a Venn diagram, there's like five circles, which are marketing, sales, product, engineering, and, you know, developer relations are exactly in the middle. The work that you do, and being in between the developers and the company, might really have you doing all sorts of things that might apply to a different team. What you're saying is great, because you might get overwhelmed at some point. So, the analogy with the jar and the rocks, and the sand is one of my personal favourites. So, I was so happy to hear that. And yeah, you should focus on your big rocks first.


Vera: Yeah, great minds think alike, by the way.


Stathis: Thank you. We just talked about lessons learned. So, I'm going to ask you something which we have already gone through in the DevRelX Community Voice, I want to repeat it, because some of our listeners might not have joined the community. So, the community voice is about questions that we ask the community people share their input. And then we share it with one another, trying to learn from each other. So, the one that you responded to, and I thought was great, was “what advice would you give your younger self who is just getting started in developer relations?”.


Vera: Yeah, so that advice ties back to the challenge. The challenge that I learned over 12-10 years, which is essentially being busy doesn't mean that the work that you are doing is bringing impact, whether it's for the community or for the business that you are serving. Also, urgent is not the same as important. Sometimes what we feel it's urgent, because sometimes, someone reached out to you on Slack or asks your help to do something, and you immediately jump in. And suddenly you just realize that your day is gone, and the important tasks that you were supposed to handle, were not handled. So, it's important that you're not confusing “urgent” with “important” because the tasks that are that important, are the ones that will prevent you from achieving your goals. And like you said, yeah, we can help in many aspects of the business, but it's essential to challenge the support that you can give because, in the end, you want to focus on what you want to achieve. And instead of being incredibly busy with shallow tasks, focus on those that will bring in a lot of impact. It's about focus rather than task overload, essentially, as my advice to someone that is looking to get into this field. Another piece of advice if you allow me is, when sometimes you get into the job, you feel that you need to do everything by yourself. But it's important that you nurture relationships with internal teams, right? It's important that your goals are also aligned with other teams' goals and everyone understands the purpose because everyone has a job in nurturing and engaging with the end-users, which are developers. So, it's important to have that alignment. So, try not to do everything by yourself, and develop these cross-functional teams and relationships across your company.


Stathis: This is some piece of advice that I will be taking for myself, too. So, I kept nodding, as you were talking, these are good reminders for me too. But yeah, thank you very much for sharing and for sharing another one. Now, well, you know, when we talk about Developer Relations, obviously we need a developer program in place. So, what would you say is a “must-have” for every developer program?


Vera: Well, a must-have for every developer program… The DevRel team should be responsible for the developer journey, which goes from awareness to advocacy. So, making sure that people know about your product or API until they are promoted or advocating for your product. So, your program or any developer program must be created with the purpose of leading the developer through this journey, from awareness to advocacy, and you should be able to measure each step to determine where developers are getting stuck. Because that will tell you where you should focus. So, it's important that you look at this entire journey, you tie your program to each step of this journey because probably there will be programs that will play an impact on awareness, but also on the activation part. From awareness to activation, which is when they give your product a try, you should be able to measure and you should be able to identify where you need to focus. I will give you an example. So, last year, we were looking into this journey, and we identify that we were losing a lot of people on the setup page, or on the setup first step. We are doing a lot of effort to bring people into the OutSystems vortex, and then we are losing these people on the setup, that can happen. And we developed initiatives to kind of accelerate and simplify that process, the setup process because our focus for a while was that specific challenge. Of course, we didn't stop doing what we were doing. So, again, we have many, many developer programs that address different stages on the developer journey. But you need to be able to reassess your priorities. This quarter, we will make an effort to improve these programs or to bring in a new program to address this stage and we will continue to run all the operations in the other ones. But yeah, there will be a big effort and focus on this one. So, if you want to refactor your developer program, or if you are thinking about launching a new program, it's important that you identify where this program will have an impact on the developer journey, or at what stage. You should be able to define what success looks like. So, for example, probably, if you identify that you need a program to address that specific stage, you have specific data. So eventually, you need to come up with other data, right? So, the things that you want to measure, things that you want to improve, and most importantly, identify if you have things to measure. Because sometimes, we want to improve this, but are we be able to measure this? How we will be able to measure this? It's important to have tools in place to allow you to measure. I would say this is a must-have. How this will impact the developer's journey? What will success look like? Do we have a way to measure it? So, three fundamental pieces for any developer program.


Stathis: And I like that you mentioned the journey, which the way I understand it, it's definitely super important. What you just said kind of leads nicely into my next question that I want to ask you: what are your top three points of focus in your DevRel strategy?


Vera: So, the three points of focus, will depend on the things that your team wants to address. For example, if you consider this simple four-step journey, which is Awareness, Acquisition, Activation and Retention - it can be a bigger journey, of course, but you need to identify where you want to focus. Build your entire strategy around where your focus should be. Is it educating your developers on how to use your product, is telling the world about your product? What should it be? Depending on the focus, which is one of the things that you should consider when defining the DevRel strategy? So, what is the focus, what are the priorities? It's making sure that your strategy is serving the end-user. So, it's serving the target persona, which is developer, and at the same time, is it aligned with your company goals? Because you won't be able to sell a strategy and get management sponsorship if this doesn't align with the company goals. So, a perfect strategy, I would say, is something that is bringing value to developers, and at the same time, will bring value to your company, which is most likely to main KPIs, which is money, revenue, and customer success or customer satisfaction - NPS. So, it's about customers loving you, and data that are generated by that: those are the company's top metrics. But at the same time, your strategy to address developers needs to be measured as well, which is not easy. It's really hard to come up with a strategy. Because even after you identify these rights, how we are going to serve developers, how this aligns with company goals, what are the priorities, after you identify this, you still need to bring your narrative. I usually say that storytelling is a skill that we all need to acquire in this world because you should be able to explain and the story should stick with people. So, you should easily explain your strategies by using some visuals, which I always recommend - to use some visuals and sketch to explain your strategy - but also have a good narrative in place that you use over and over to evangelize not just the management, but everything inside it. You need to establish a relationship, you need to be able to talk about your strategy. So yeah, all of that.


Stathis: What you just mentioned is having both the business goals and the customer goals served, and storytelling, yes, is I do believe that it's a vehicle that actually can help you. Help you towards both ways, as both in your speaking to your customers and developers. And at the same time explaining and justifying all your efforts to the management of the company. Now, what are you most looking forward to? What is the future going to bring for developer relations? Is this something that you're looking forward to?


Vera: The way I see this is, the role of the developer itself is changing. So, you know, as you think about developers, like in the past 20 years, like they were the ones working alone in a very distant room, and today, they have more influence and autonomy in choosing their tools. And for this reason, the role of the developer relations will be more and more relevant. We will be the ones creating relationships with this audience. So, this fact of the developers having more influence, they become the decision-makers on adopting technology. This will make the developer relations practice grow. This is the way I see and the way I hope to see this evolve. And this will allow bringing more definition and clarification around Developer Relations and Developer Relations teams and functions and programs, which will be also more about clarifying career paths, identifying patterns, what works, what doesn't work. We see developer relations as an umbrella term for many different things like you said. But even considering that there's specific contexts where some tactics will apply and other tactics will apply to other contexts. For example, we have these two scenarios, which is companies that are Developer-Focus, and companies that are Developer-Plus. Developer-Focus is the one that are building products, which the target user is developers. Developer-Plus is about the companies where the buyer persona is not the same that the end-user persona, so you sell to one specific persona, but then the person that can bring value is the developers, because they are the ones that are using the product, which, by the way, is the scenario where I am. So, I think as we evolve this field, I think there will be more clarification, more people joining the conversations. I love seeing new people popping into this world talking about the things that they tested, and they failed, but also talking about the things that they tested, but it was a huge success. This really gives me the inspiration to think about the next thing that we are going. So, I'm looking forward to seeing more definition, more patterns, more frameworks around the Developer Relations world.


Stathis: Yeah, this is definitely something to look out for. Unfortunately, we need to wrap up. And I say, unfortunately, because you've shared so many great things today in this episode, that I'm also sure a lot of people will want to hear more from you. So, if someone wants to reach out to you, how can they do so?


Vera: Thank you, thank you so much for your kind words. I'm using Twitter and LinkedIn. On Twitter, I develop my Developer Relations presence. So, in my network there, there is mostly people that are doing developer relations like me. I'm also on LinkedIn, but I use LinkedIn to reach out to my target audience. So, my network there is mostly about developers. But yeah, so on Twitter, I'm @VeraTiago. It's just my name, okay, with no space. And LinkedIn is the same. That’s just me there, feel free to reach out, I'm happy to have these conversations. Because to me, I’ve been doing Developer Relations for a while, but at the same company. One of the strategies that I use to evolve my skills is connecting with other people that have the same challenge. But the context is slightly different. So, I love to engage with people that are doing the same as me and learn from them. And also, if possible, be able to help and provide some insight as well. So, feel free to reach out.


Stathis: Yeah, and I got to say, Vera is also a member of our DevRelx community. So, I'm sure people can reach out to you there too, and learn from each other there. So, to close on… Definitely positive note, and also maybe things to consider, what's something that you watched or read right now, or, you know so recently and got you excited?


Vera: Okay, so, right now, I'm reading a new book. So, I was looking for my next book. So, I have like a big list of things that I want to read next. But right now, it ties to the momentum where I am, which is about redefining our priorities, planning, strategy. I'm reading a book about negotiation, which is, so the title is “Getting to, yes, negotiated an agreement without giving in.” This book is written by Roger Fisher and William Yuri. So, it's a negotiation skills book. It gives you a lot of insights, some of the things you already know, but it's more like a confirmation. It gives you a lot of insights into different situations, and also examples of how to deal with those situations. So, for everyone that is in the same stage as me, which is about planning, strategy, defining strategy and negotiating with the management. So, I really recommend this book, I'm enjoying it a lot.


Stathis: Perfect. Thank you for sharing this. This book is actually on my list too. And a book wish list somehow always keeps growing and they never become shorter. It's good to hear that you've also read it and you suggested. Vera, it's been great having you. Thank you very much for joining us.


Vera: Thank you so much for having me. This was super fun. Thank you.


Stathis: It was great. Thank you. And thank you to our listeners for listening to the DevRelX Podcast, the podcast devoted to developer marketing and relations. You can listen to all episodes, find free resources and the latest news and also join our community at their Devrelx.com. You can subscribe to our bite-size bi-weekly digest or follow us on Twitter @SlashDataHQ. Thank you very much.