Made by
Made by
I started my career as a software developer and I loved doing that as a full time job for six years. However, I also love teaching and two years after joining OutSystems, I started switching to other activities, such as educating and training internal developers with OutSystems.
Quick context: OutSystems is a platform to build software. Being a product company, we also provide professional services, meaning we eat our “own dog food” and deliver software using our technology. So I was in charge of training and creating accelerator programs for the new developer hires in professional services.
One day I received a call from someone in the Product team asking me “Vera, do you want to change the world?”; and without hesitation I immediately said “Yes!” So, I moved from Professional Services to Product Management to start a new team called “Ignite” – because our purpose was to ignite the community of developers. This was in 2016 and it was the first time I heard that we were going to start focusing on developers. I still remember my manager’s words, “There’s one thing that can kill this company, and that is a lack of developers with the skills to build with our product”.
This was a very pleasant twist, because until that moment the company was hyper focused on the buyer persona, not the end user developers working with our product.
So, I took a very active part in supporting OutSystems developers, while preparing enabling programs and defining the evangelism strategy to grow the community, and remove initial objections about our product.
The range of my activities was wide and fell into different “usual” jobs:
OutSystems is an enterprise-grade software development platform. This means our customers are companies who want to solve business problems through software, so we need to help these customers, and make sure they are using the product and they are getting value out of it, and they are going to stay with us.
And to build software they need developers! So, having a strong and educated developer community helps our customers to be successful. We also realize developers today have a lot of influence. In other words, developers make decisions on what software to use and buy.
Currently we live inside of Portfolio Marketing (inside of Marketing), side by side with Product Marketing, and we cover two of the core parts of DevRel – Developer Advocacy and Community Management. Developer Marketing also lives in Portfolio Marketing.
On the community management side, we focus on enabling and retaining developers by nurturing the online community, hosting community events, handling developer communication, and running Developer Champions Programs.
On the advocacy side, we focus on content creation and delivery (such as talks), coding, community support, and developer experience. Our broad purpose is to get developers excited about OutSystems and to educate them on how to get the most out of it.
In OutSystems there is a dedicated documentation and training team called Technical Knowledge. So, although the advocacy team has a target of education, we don’t provide training.
When it comes to developer experience, although it is not a big focus for our team directly at this point, we play our part by acting as the a channel for developer feedback to get to the appropriate Product Manager and Product Designer. We also facilitate sessions and interaction between the Product team and developers working with OutSystems.
A few months ago I became the manager of the global developer advocacy team, so I had to shift my mindset from achieving results on my own to achieving results with and through others. And I’m still learning on the job.
The most important part of my role is to help my team members get clear about the “why” behind the “what” and to support them in the “how”. Besides that, I also report and follow-up on activity execution, collaborate with different teams and departments on initiatives targeting developers, and do some field activities myself, like giving talks, participating in the online community, interacting with our champions, and so on.
My DevRel philosophy says that you need to build trust with developers first, before you roll in there playing the “evangelism” game.
Every product company targeting developers is seeking developer adoption and developers just want to use those products in the most efficient way. So, there is the need to find the delicate balance between providing the right support when developers need, but also let them do their own stuff by themselves at their own pace, without being bothered. The key differentiator and important element for a successful adoption is having a responsive and healthy community, so it should be part of a strong developer relations strategy.
I believe one of the biggest challenges is balancing the interests of the company and developers.
For example, more and more, we see DevRel teams moving to the marketing department. DevRel combines two very different worlds: marketing and engineering. So, you need to marry the best of marketing to the best of engineering.
However, that becomes a problem when the best of marketing is something that makes developers nervous. The excessive use of superlatives is what marketers excel at, and it is also what developers hate. And we know this because we are in constant contact with developers, so we know them well. We need to constantly remind the internal teams how they should talk with developers and the things they value most, and whenever possible, to support arguments with data.
Another challenge is keeping an authentic voice when communicating with developers. DevRel is getting more visibility and that could lead to more pressure to do things that eventually could impact the authenticity of DevRel’s voice.
The role of the developer is changing. They have more influence and autonomy in choosing their tools, and for this reason, the role of developer relations will become more and more relevant. This will make the practice grow, bringing more definition around developer relations teams and functions, clarifying career paths, and defining common patterns with specific guidelines for success.