Where should Developer Advocacy sit? With Vera Tiago from OutSystems
OutSystems' developer relations team has moved from product to marketing and back to product twice, chasing whichever part of the org was "screaming" for help. Vera Tiago's read: that's not organizational chaos, it's what DevRel is supposed to do when it actually has cross-functional impact.
Vera Tiago is developer advocacy manager at OutSystems, a low-code visual development platform, where she helped start the company's developer relations team — originally called Ignite — from two people.
We get into why OutSystems' end user (the developer) and its actual buyer (the IT decision maker) are often different people with different motivations, why she thinks OutSystems occupies an awkward middle ground between 'developer-first' and 'developer-plus' categorizations, and why she treats teaching as a way of building her own knowledge, not just distributing it.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did you end up in developer relations at OutSystems?
I have a computer science engineering degree and started as a PHP developer. At some point I wanted to try something new, so I joined OutSystems as a software developer — partly as an excuse to learn a different tool. OutSystems is a visual development platform: you build using visual widgets that represent lines of code underneath. I did professional services for three years, then moved into training, teaching people how to develop with OutSystems. Eventually someone from product management asked if I wanted to help change the world, and that's when we started the developer relations team — just the two of us. At the time, we didn't even call it developer relations; we called the team Ignite, because our purpose was to ignite the developer community.
What does developer advocacy actually look like at OutSystems today?
It's part of a larger developer relations team that also includes community management and developer marketing, which sits inside our marketing department. Developer advocacy itself is the technical arm. We're currently back inside the product organization rather than marketing. Our team has three pillars: growth — bringing more developers into the ecosystem; retention — keeping developers engaged and productive with the product; and credibility — building visibility and trust in the tool itself. There's a lot of noise in the dev tools space right now, since everyone's trying to simplify developers' work given the global developer shortage, so credibility matters as much as raw reach.
Your team has moved between product and marketing more than once. Why does that keep happening?
Developer relations can genuinely impact many parts of an organization — marketing, customer success, support — but you have to focus on one area at a time, so we've ended up gravitating toward whichever part of the business was 'screaming' loudest for support. When we started, our focus was building a sustainable community, end users helping each other in forums, plus feeding product feedback — that put us under product. Then we moved to marketing because brand awareness was seriously underserved, especially for developers rather than IT decision makers. Now we're back in product, working closely with engineers and product managers so we can influence the roadmap directly and bring the developer's voice into that process.
Do you think developer relations teams should be built to move around the org like that deliberately?
We didn't push for these moves ourselves — they came out of reorganizations, where leadership looked at what we were doing and decided how best to leverage it. It was a pull, not a push, from us. I do wonder whether, eventually, developer relations becomes a genuinely distributed function — people embedded across departments, one group focused on acquisition, another on product ideation, another on customer success — rather than one central team that periodically gets reassigned wholesale. I don't fully know what that would look like in practice, but it's the direction I could see this heading over the next decade.
You've talked about defining a third category beyond 'developer-first' and 'developer-plus.' Can you explain that?
Developer-first products, like Twilio, are chosen by the developers who use them. Developer-plus products, like Slack, aren't inherently meant for developers, but developers can extend them to improve the end-user experience. OutSystems is enterprise software — the actual benefit lands on the organization, like a bank needing to build a home banking solution fast. Developers are the ones who drive that success by actually building the solution, but they typically don't have much influence over the purchase decision itself — that's closer to how a gaming studio's CTO decides on core technology while the people actually building the game have some, but limited, influence. So we sit in this uncomfortable middle: not developer-first, not developer-plus, and developer relations work in that middle space looks genuinely different.
How does that difference in motivation between a CTO and an individual developer actually play out?
A CTO thinks about efficiency and how to make a whole team more productive. A developer, especially in newer generations, thinks much more about their own career trajectory — how do I succeed in this field, how do I level up. My own generation tended to stay deeply invested in one stack — if you're a .NET expert with six years of experience, switching stacks means becoming a junior again, which is unappealing. Developers actively go looking for new tools when they're already unhappy with their current setup; if they're satisfied, they won't go looking for something like OutSystems, which looks expensive and unfamiliar from the outside. That means there's a long road ahead for us to build the right mindset both with the CTO buyer and the developer who'll actually build with the tool — and since developers often aren't the ones deciding to adopt it, our job becomes making their experience of adopting it as good as possible regardless.
When a team gets told 'we're using OutSystems now, go set it up,' how do you make that experience good rather than resented?
Developer onboarding matters enormously in that scenario — creating a safe space for people to understand how to use the product and what resources exist to support their journey. There's also a communication piece: reassuring developers that this is just another tool, that they're not being asked to abandon their existing skills, just add to them. Traditional marketing language often doesn't resonate with developers — it reads as just another email. Onboarding focused specifically on the learning experience and becoming productive quickly is where we can add the most real value.
Is there a specific fear you're addressing — that using a low-code tool signals someone is a less skilled developer?
Yes, exactly — because our own marketing says OutSystems is easier and faster, people sometimes assume it's built for less skilled developers, and that's not accurate. It is faster and easier, and it has a learning curve, but you still need real skill — depending on your skill level, you can tackle more or less complex applications with it. For anyone building developer tools, it's important to understand the specific use case your tool actually serves, and to communicate clearly with your target persona about that use case rather than letting an oversimplified pitch create the wrong impression.
Do you actively help developers see OutSystems skills as valuable for their broader career, not just their current job?
More developers now think explicitly about career impact — what's the next big thing, where can I add the most value. If a skill is in high demand, you become more valuable holding it, and I think developers actively look at job postings to spot the biggest gaps and plan accordingly. As a marketer, you can help by clearly surfacing that demand — showing developers what your customers and the broader market are actually asking for puts your tool directly in front of the people deciding where to invest their learning time.
What's a concrete business problem OutSystems solves that also genuinely benefits the developers involved?
Technical debt. Large enterprises accumulate legacy systems nobody wants to touch — everyone knows it needs revamping, but it's working, so it keeps getting built on top of instead. OutSystems lets you prototype quickly, show rapid value to the business, and then extend or revamp a legacy system over a couple of months rather than years, often by connecting directly to existing data instead of migrating it, or by exposing legacy systems as web services behind a new interface until you can fully disconnect the old system.
Why does solving technical debt resonate with developers specifically, beyond the business case?
Because we're not just solving a business problem, we're improving developers' actual working lives — nobody enjoys pure maintenance work or being stuck working in someone else's old code. Developers want to build things; they're creative people. A lot of developers get stuck maintaining the same legacy application for years, and that's genuinely bad for both their health and their career. Freeing people from that is a real, human benefit on top of the business case.
You've taught evening classes at universities in the past. How does that experience shape how you approach developer advocacy?
I'm a teacher at heart — my mother wanted me to become one, though I took the computer science route instead. I started giving evening classes at a local university early in my career, alongside my day job as a programmer, and kept some relationship with local universities even after I stopped actively teaching. When I interview candidates for developer advocacy roles, I pay attention to whether they say they like to teach, because teaching for its own sake is a real signal, but so is the version where someone teaches because it makes them learn more deeply — preparing to teach a subject forces you to investigate it properly, validate your assumptions, and dig deeper than you otherwise would.
Do you think of your day-to-day job as fundamentally teaching?
Yes, at the core, even though the job also includes gathering product feedback and evangelizing the product. To have a genuine conversation with a developer, you can't just talk about your own tool in isolation — you need to be able to compare it honestly against other players and understand the broader software development landscape. In the end you're teaching technology generally, not just your specific product, and that's the piece I find most worth continuing to invest in.