Where should Developer Advocacy sit? With Vera Tiago from OutSystems

Vera: And I really believe, because if you need to prepare, to teach a subject, you investigate that subject, right? You validate that your assumptions are right. So you'll get the data right. You'll. Deeper in order to prepare yourself to teach. So I think teaching is a great way, to also build knowledge for you.

Jack: Hi everyone. You're listening to Skating Dev Tools, the show that investigates how dev tools go from zero to one. I am joined today by Vera who is developer advocacy manager at OutSystems. Vera, thanks so much for joining.

Vera: thanks for having me, Jack.

Jack: I've listened to a lot of your stuff on different podcasts and, on Twitter, and I know you put out like some amazing kind of thoughts and, knowledge in developer advocacy.

So really excited to have you on today. Could you tell us a little bit about yourself and about out systems and, and your background?

Vera: I have a computer science, engineering degree. I started my career by being a PHP developer. then I did a bit of.net in the past, and a certain point I realized that. I wanted to try out something new. so I decided to join out Systems as a software developer, and get an excuse to learn, you know, a different tool.

so out systems for everyone, that don't know what it is, is, um, is a developer tool, is it has a visual language essentially you program, you do your, you. Development in using visual widgets, which represents. Lines of codes under the woods. So I did professional services for three years, and then I start moving to, areas that lead me to this role.

So I start by becoming a trainer, you know, teaching, how to develop without systems. And at a certain point, someone call me, uh, you know, from product management saying, Vera, do you want to change the world? You know, ah, of course, yes. And, and that's when we started, the developer relations team in our systems.

Um, just two of us. By that time, we didn't call ourselves developer relations because it was not something that we were very, very familiar with. We call our team Ignite, which was, you know, our main purpose was to ignite. The community of developers. , that's my path until I become, developer relations, person, developer right now more focused on developer advocacy.

Jack: And I know you've been like really a driving force and OutSystems is one of those companies it's not like a household name, but they're, you know, absolutely huge. I think you've got like 6,000 employees or something like that,

Vera: Yeah. You know, it's big

Jack: Yeah. That's amazing.

And could you tell us a bit about what developer advocacy looks like at , OutSystems?

Vera: Yeah. I can share what it looks like right now, because it changed over the time. Right. Developer advocacy. It's part of our bigger developer relations team. So essentially we have, community management, community grow and engagement. and then we have developer advocacy, which is. A technical pool of people.

And then we have developer marketing inside our marketing department. We are not in marketing anymore. We are in products again, in the product organization. Yeah. And, and our main goal right now is to build credibility among developers. So our team develop relations team as a, the whole team.

We have. three main pillars. One is growth, right? Bringing more developers to, the community, to the ecosystem. Another one, is retention, right? Is, is keeping developers engaged, and being, you know, productive with our product. And then we have this third pillar, which is credibility, which is more about how do you, Bring visibility to your, you know, to our tool, to the developer community.

And I know if you, and if you feel this, there's a lot of noise nowadays, right? So there's a lot of developer tools out there because everyone is trying to simplify, the work now of developers because, you know, there's a sort shortage of developers around the world, uh, for, for the business needs. So, um, people keep trying, Tools out there. But yeah, so we essentially are trying my team develop advocacy, spread the word, create brand awareness, but also, you know, make developers see us as a serious tool that it can use, to be successful on, on, on their job.

Jack: Yeah. And kind of you touched on that, like, departments and, and now you're in product. But you were in like the marketing department before. could you talk a bit about like kind of why you kind of were moving around there

Vera: yeah. It's crazy. So developer relations, they can have an impact on many areas of the organization, right? So they can, you know, help marketing, help customer success, uh, you know, support. So, We can help in, we develop, relations can help in many areas. The thing is, you should focus on one area at the time.

Right. And that's why, the, the area that is screaming at the time that it needs more help or support is the one that we go. So for example, when it started, our main goal is, uh, was building a sustainable community. So Essent. Putting our end users, helping each other online through forums. Right. but also contributing to the, product for, you know, for evolving the product that was, you know, in products.

So our focus was mainly community. And then we moved to the marketing organization because we realized that we needed more, brand awareness. Right. And, this was one, one of the most underserved areas because we have essentially two personas in our scenario, which is we have someone, which we call the IT decision maker, who are the ones who find us and know, evaluate us, and, and make the decision to buy us.

And then we have the end user, which are the developers. And most of our, you know, marketing efforts right now are. In the past went towards the R T D M, persona, right? So they needed our team to help, you know, essentially building content, right? And then defining tactics, to create brand awareness for developers.

So, One of our pillars was, video content. So it was the first time I do started creating video content for, for developers. And we already, you know, had, and we have training, uh, online training, which you know, are. Content, video content for developers, but we start creating, you know, bite size, videos, so that we could address, problems that developer have today, right?

And they could solve, you know, By stumbling in one of our contents, for example, consuming REST api, right? We have that content. Actually it was one of our most popular contents on YouTube, which is how to consume REST API without systems. And everyone was, oh my god, this is so easy enough. Thank you, , right?

But it was something very, very simple. But that is One of the examples, right? Why we are, driving more interest to our citizens and, and creating brand awareness. so we moved from products, you know, from to marketing and, and our, you know, our focus was more acquisition.

I think it's. Probably a bad, you know, word, but yeah, we want to acquire, right? Bring more developers to our ecosystem. But then we move to product again, . So right now we are on the product side. Again, brand awareness is still important and it's one of our pillars. but yeah, we are doing, you know, other stuff, uh, in the product organization.

And it's good to work closely to engineers, product managers, because we can influence, , more, the roadmap, the product roadmap, and, you know, bring the developer's voice into inside

Jack: That's like super interesting. So do you think like a developer advocacy team should almost put like wheels on their desk or something so they can like easily just move around departments, like as the company changes?

Vera: Yeah. So, yeah, so I think. We were not the ones, you know who, who push that transition. Right? Because, you know, management changes, you know, they are reorgs, right? And, and we, sometimes we look at the structure and it see, okay, this is a team, what they are doing, right. How they can, how we can leverage them, right?

Ideally probably would have, you know, people in every department, right? Probably a distributed develop relations team went, okay, so this team focus on acquisition. This team focus on product ideation. This team focus on customer success, right? And you cannot distribute the work.

Right? But I don't know how this would work, like, okay, we are the developer relations team, but we work, you work in this department, that department, that department. But yeah, this is an idea that I. I don't know. In the future, maybe in 10 years, we will see more distributed teams across the company because again, like I said, this can have impact on different areas.

Right. And probably areas, depending on the area, you need more help or not. so it's just a matter of identifying the priorities. But yeah, we didn't push for these reorgs and moves. I think it was the result of our work, that brought us visibility, uh, on the things that we can help.

Right. So someone made the decision essentially

Jack: Yeah, it was a pool situation rather than

Vera: Yeah.

Jack: That's really cool. So one of the other things that you mentioned, around like, kind of the decision makers being different between, the developers, so like the people that use it are, are not the same as people that buy it.

This is a challenge that a lot of people face. And I just wondered if you could like kind of dig in a bit more. Cause I know it's something that you have a lot of thoughts on.

Vera: And I'm about to create a new, definition in the developer relations area because let, let me explain a bit. In this, developer relations space, we consider essentially two scenarios. One is the developer first scenario, which for example, Twilio, right? It's is a good example, which is, A product that is meant to be used by developers, right?

So we are the ones that choose to, to use Twilio, right? And then we have, this is developer first, and then you have Developer Plus, which are, products who are not meant to be used by developers, but developers can extend and, you know, improve end user experience. For example, slack, right? Slack is a conversation. Platform, but developers can build, you know, apps for Slack in bots, right? And things that could help, will help, user experience. So everyone who is, using Slack. And then we have, you know, situations like, our product, which is an enterprise tool where we built enterprise software. which the benefit will be for the organization itself, right?

So a large bank needs to, you know, create some home banking solution or something like that. They need, they need us to solve their problem and build the software fast, right? We kind of help business to be more successful and you know, and tackle that challenge. But then the ones that can drive this success, which are the indigenous of our products, are developers, which are the ones that will build those solutions, right?

That will solve the business problem. to me is a, is a different situation. Although I was, you know, just sharing this with one of my team members, he, he was saying, no, but this is a developer first situation because the end user is, is the developer. Yeah, yeah. But you know, it's enterprise space developers have some influence in this precise decisions, but Cannot, influence if you are in the enterprise world.

Like it's the same that gaming industry, let's consider a big game. They have their technologies defined where probably there's a CTO who takes decision on where to go, but the ones do build up game , I think it can influence, but they don't have much influence. Right? So it's, I don't know. It's a, it's very challenging world.

To work, right? Because I think we don't identify ourselves as a developer first, neither, developer plus situation. So we kind of in the middle . but yeah, just putting out there that is, different scenarios and there's the repo developer relations people and developer advocates working in , these two spaces.

Jack: That's actually really interesting because even like for instance, a cto, would be I guess at that point so far removed from writing code like a big enterprise.

Vera: If you think about the CTO or the role, the cto, it needs to be, you know, a person who takes decision. And, you know, needs to keep informed of the technologies out there and how again, they can be useful or not for their scenario. Right? And the motivations and the way that person sees things is different, right?

Because you probably think about, you know, efficiency and how you can make your team more, you know, efficient If you think about a develop. , and I believe the developer or the mindset is slightly changes with the new generations,right? Developers think about how can I be more successful, right?

How can I succeed, in the software development world, right? How can I go to the next, to the next level? And until now, I think, or my generation, we were focused on our current stack, right? Oh, Expert in net, so I wanna do.net because I want, you know, consider an expert, right? Instead of if I move to another stack, probably I, you know, I have six years of experience with net, and then I move to another stack and suddenly I'm a junior again.

Right? Developers don't want that. The same thing with a tool, learning a new tool can be tricky, right? And, and you are so used to your tool set, so to your, to the tools that you use today. Or you have a pain that's probably, you are looking for other tools to make this better, right?

So, because that exists, right? That's never exists. So that's where developer go out there, you know, and choose, a new tool to try out and see if it solves their problems.Otherwise, if the developer's happy with the tools that they use, they will, continue to use that, right? So developers won't look, you know, for tools like our systems, which are, you know, very expensive, it's like a, something that is, it feels big, but people actually don't understand how it works, right?

So there's a long way for us in the software development space, namely enterprise, for us to grow. The CTO mindset. Persona who uses the product, the persona who builds the software. Motivations are different. The way they see things are different, right? That's why we need developer relations to tackle, you know, the end users and to help them to make informed decisions, right?

And actually in this situation that I just mentioned, that they are not the ones who decide to use a product. How can we make their experience better when adopting our product? so yeah, depending on the scenario, your team can have different, you know, focus or priorities.

Jack: So it's like, it's never gonna be like a, a developer just trying it out and then like, oh yeah, let's just

Vera: Yeah, use this.

Jack: It's gotta come like from the top. And what kind of strategies do you do when it's like someone gets email like, yeah, we're using OutSystems now, go set it up.

Or like, how do you make that kind of experience great for.

Vera: No. Yeah. So one of the things that is important in that scenario, right? When. Teams get informed that suddenly they are going to use new tool is developer onboarding, I you provide, a safe space, for people first, for people to understand, how they can use the product. Second, what are the resources available to help throughout their journey?

And. There's a, a, a side thing, which is more horizontal, which is the way we can communicate with developers, , to show that, okay, this is just another tool. As a developer, you'll be perfectly fine, you know, in learning this because it's okay. It's just another developer tool. We, we don't, we are not saying that you need to forget all your other skills with our products, right?

It's just heading on top of your skills. Right. And I think the important piece here, which. where we can provide value is, is in how you communicate with developers, right? Because again, marketing people out there, I know you do the best that you can, but you know, for developers, traditional marketing techniques and the way you talk about things is. sometimes it's not the best way, when you go to developers, right? It doesn't resonate to them. It's just another email, another communication, in that scenario, it's developer onboarding. It's very important, that heads in, , to the experience of learning, and becoming productive with the tool.

Jack: That kind of like reassurance, that yeah, like the kind of fear that comes in or like, am I gonna get a pay cut? Am I like gonna get sacked or replaced or like, will I go stale? Will I forget how to code?

Vera: And you know, Again, because of our marketing team says that okay with our systems and it's easier and it's faster. People assume that, is that, I don't know, probably less skill developers is not target for less skill developers and it is not that. Yeah, it's more, it's faster, right?

And it's easier. It has a learning curve, but you still have. to have your skill. Right. And depending on the skill that you have, you can go into more complex situations or building complex applications or not, right? Because it's depending on the complexity, right? Autisms can be a better fit or not.

And for everyone that has, you know, been developing developer tools, I think it's important to understand. What is the use case that your tool addresses, and how you can help, you know, people to discover your tool, but also be successful in while using it, right? So the use case is actually very important to understand how you communicate to your target persona.

Jack: On that, topic, and I know it's kind of related to education, but like when people are looking at like, or out systems, like another tool to learn and stuff, how much kind of thought is there about Showing people that they could use this skill like another job as well if they

had like, it's in demand.

Cuz I know, like for instance, I have friends that develop tools for Salesforce and stuff like that. And they're kind of happy to do that as well. Like where they're cuz I know that it's a really lucrative and everyone wants to hire them.

And is there that kind of thing of out systems about showing that actually this is really in demand skill as well.

Vera: And then you see, right now, I don't know, more developers. Talking about the career, right? So how this will impact my career, right? What is the next big thing, . One of the things that, I get from when I talk with developers is most of them are looking for the next big thing,

so where can I head value and where, how will my skills be valued, depending on the things that I want to, that I start using. Right? And one of the things that you mentioned is the demand, If you offer skills in an area that has more demand, you will build more valued. So, and I think developers, I don't know if everyone does this exercise, but they look out there and, you know, they look probably to job posts and they try to understand what are the biggest, gaps, right?

And I think they, , plan accordingly. Understanding, you know, the demand, and, and you know, getting them to know where they can head value probably that we will influence, the decision, whether it go that way or that way, or adopting this tool or this tool, right.

One of techniques that you, you know, as marketer, you can use is or actually create that procession that is a demand for the skills, because you know, right, you know that your customer or, what is the business asking, right? So you should, you know, expose that to, to the developer audience so that they understand the demand for, that,

because that will put your developer tool in front of.

Jack: Have you got like any examples where big problems that out systems is like solving and how you kind of,

Vera: Yeah. So e essentially is, we, one of the problems that we aim to tackle is technical debt, right? Big enterprises have a lot of legacy. . Right. And no one wants to touch those products because, oh no, we don't want to touch that. We will not to break that, but because it's working, I know we need to prevent, but it's working just.

let it go, right? And it continued to head on top of Legacy. So one of the things that we want to solve all this is technical debt on these back big companies, right? Because without systems is easy to prototype, So it's kind of show rapid value, to the business and then, extend,

easily revamp a legacy system in a couple of months, and we are talking about big systems, because one of the things that we do on, one of the things that we, we offer is the ability to, you know, use the data that already exists. So you have your data, right? So you don't need to move data.

Anywhere else, and you just connect, right, to that data. Another option, right? And this has to do with accessibility, is, okay, so you have your legacy systems, why don't you expose, , web services and we can create a new, A new interface, a new application consuming from your, legacy system system until we can disconnect it.

This is one of the problems that we tackle, which is, legacy systems in technical depth that

Jack: And I think that is gonna make a lot of sense to like every developer. They're like, oh yeah, I know that.

Vera: Yeah, you need to think about it. We are solving business problems, but also actually we are improving developer's life because no one likes to, do maintenance, right? No one likes to work in others code, developers want to build stuff. Developers are creative, right? So we are simplifying and hundred benefit to them because, you know, many developers of there are stuck, in applications and, software solutions for ages.

And the only thing that they do is maintenance. Just get off debt because there is no that is not good for your health. Not, not, not good for, you know, for your career

Jack: I couldn't agree more. So you're freeing people, you

Vera: Yeah. Free people.

Jack: Yeah. Yeah. That's really cool. I know that, in one of the other podcasts that you're on, you were talking about how in your previous life, you'd done a lot of education, in terms of like, helping like new joiners, like onboard in in the team and , and you'd also taught evening classes at universities in coding.

I just wondered like kind of. Use those skills that you've got, in developer advocacy.

Vera: Yeah. So I, I usually say that I'm a teacher by heart. , my mother wanted me to be a teacher, and I, you know, follow a different p was computer science engineering, but yeah. I always like to teach people. When I started my career as a programmer, I also, started, giving classes and at a local university, so I always, you know, did these contributions, right?

Uh, so teaching students, Doing my job, right. So during the day, during my job at night, you know, teaching classes, and I kept that for a while, I still have some, you know, relationships with local universities, but I, I'm not teaching anymore,

I think it's important for our job or. For a developer advocate job is they like to teach, right? Every, every time that I'm interviewing people for, , job positions, when they say they like to teach, whatever is, you know the reason, you probably, you like to teach because you like to, To teach others and, and, you know, to give away your knowledge, but also some people like to teach because teaching, makes you learn more, right?

So it's kind of, and I really believe, because if you need to prepare, to teach a subject, you investigate that subject, right? You validate that your assumptions are right. Right. So you'll get the data right. You, you'll. Deeper in order to prepare yourself to teach. So I think teaching is a great way, to also build knowledge for you.

At the end of the day, being a developer advocate, yes, you follow up, you know, feedback for the product. Yes, you are evangelizing your product, right? Spreading the word. But I, I think in the end you are educating about technology for you to have, , a conversation with a developer, you you should not just talk about your tool, right?

You should be able to compare how your tool, I know compares with other players, right? Where essentially, you know, your tool can be leveraged, right? And you need to understand software development world in generalized. So we are teaching technology. Our product. I, I would say so.

Maybe when I retire , I will be a teacher full-time again, But for now, it's, it's so much to do and so much to learn in this space that I, just want to continue doing this journey.

Jack: Everyone needs you in this space right now, I think

Vera: Oh, thank you. That's so nice.

Jack: Vera, thanks so much for joining. Where can people learn more, about, Vera and about out systems and.

Vera: I'm around some, I'm mainly active on LinkedIn and Twitter, so everyone that, you know, wants to change some ideas, , get help on a specific situations because, developer relations is pretty broad, but depending on the product that you have, the situation, the service, it's different.

And to me, . it's very useful to have those conversations because it makes me go out of my vortex. Right? I, I was born at Dre out Systems, right. I know my context, but I'm always eager to learn more about other situations because it's the way. That I have to help others, but at the same time help me, you know, validating my assumptions and also learn more about the ecosystems in general.

So people out there feel free to reach out to me, via Twitter or LinkedIn.

Jack: Yeah, amazing. And you've ridden quite a few things on Medium and given a

Vera: Yes, I want to get back to writing, right? I have a few block. I always try to share, you know, insights or learnings, uh, and mostly because again, I like to share while it work for me. , but I also looking for validation in, if that makes sense for others. Right. . So I have a few articles on Medium, as well.

I have more that I want to publish soon, as soon as I get time

Jack: So follow, follow Vera on Twitter and then you'll, see as soon as they come out,

Vera: So feel free to follow me on Medium as well.

Jack: Amazing. Well, thanks Vera for joining and thanks everyone for listening. We'll be back soon.