In this post, I think about what it means to me to be a part of the Developer Relations team, and talk a bit about evangelism, outreach and advocacy.
It's been just over four months since I joined SAP's Developer Relations team, and it's been a great experience so far. Primarily because of all the awesome people I now call my colleagues, but also because it helps me move towards being a better version of myself, which is what one should strive for in life, right?
Developer relations is relatively new in the world of software, so it's a subject that we can almost continue to define, or refine, as we progress. It's a discipline that I first heard of almost 10 years ago, about the same time as the advent of one of the early web-based development tools, Bespin.
Bespin
The Bespin editor, from https://blog.mozilla.org/labs/2009/02/introducing-bespin/
I remember being totally awestruck by the fact that there was a very usable editor that ran *in the browser*. Back then, it was unheard of, and for many, way beyond what we thought possible in a browser.
That early version of Bespin was, as described in the post that introduced it, an experimental prototype demostrating concepts and the possibilities that it opened up. And my goodness did it open up possibilities. Shortly after Bespin we saw the advent of another great online Interactive Development Environment (IDE) in the form of Cloud 9 - I remember going to talk to the developers of Cloud 9 at their booth at Google I/O in 2011, before they were eventually acquired by Amazon Web Services. Of course, this laid the path for what we have in the SAP world in the form of the great SAP Web IDE (and yes, I am a fan).
Anyway, I digress.
One of the folks behind Bespin was Dion Almaer, who wrote a piece on developer relations around that time, called "Developer Advocate versus Techncial Evangelist; When names change the tone" (I had to dig into the Wayback Machine to find it).
That short piece makes some points that resonate with me even today, and in my new role I try to keep in mind the thoughts that these points - about the different meanings of "evangelism" and "advocacy" - conveyed. First and foremost, they're only words, and actions speak louder. But the words have connotations that might influence those actions, if one is not mindful.
Evangelism and advocacy
Developer evangelism is a term now widely understood, as of course is the more umbrella term "developer relations" (which resonates very well with me). Developer outreach, or, more commonly, developer advocacy, is a term that is possibly less well known but to me better fits what the activities are within the Developer Relations context.
Evangelism has possibly a broadcast tone, even a religious one. To me (not necessarily to everyone), outside of the developer relations context, it suggests more speaking and less listening.
On the other hand, advocacy immediately conjures up the concept of "on behalf of". Advocating on behalf of developers. Fighting their corner, relating directly to them, acting on their behalf. Essentially, being their advocate.
Developers
But there's one question that one should consider here: Who are the developers?
For me, there are two main groups, and the goal is for them to work as one, learning from each other. The first group represents the developers that are using the software. There's a good chance that you, dear reader, fall into this group. The developers within (and beyond) the SAP ecosphere that work on a daily basis building solutions at customers and partners to solve business challenges using SAP software. This group is the most obvious group with which a member of a developer relations team has, well, a relation.
The second group are the developers inside of SAP, the teams building the software that you use, or the platforms upon which you build. I had the good fortune a couple of weeks ago to visit the mothership (also known as SAP Walldorf), and popped in to building 03 where I had coffee and chats with various people, including carine.tchoutouodjomo and then rui.nogueira (with whom I chatted about the new Application Programming Model, the interview of which can be found here in transcription and audio format, courtesy of the excellent Coffee Corner Radio podcast: Interview with Rui Nogueira on the new Application Programming Model for SAP Cloud Platform).
I also got a chance to go and meet the teams behind two of my favourite SAP Cloud Platform services: Workflow (see my Discovering SCP Workflow series) and Business Rules (one of my sessions at UI5con@SAP this year was on using the Business Rules service in UI5). I got a chance to chat with them for pretty much an entire hour, and we discussed all sorts of topics related to what they were building, features, priorities, hopes, fears, and more besides.
Meeting some of the Workflow and Business Rules team at the mothership (11:12 AM - 21 Jun 2018)
Reading back that last sentence, it strikes me that the image it conveys is that of normal people. And that's the point I guess I'm trying to make.
These folks are developers, just like you and me. And that is something that I'm mindful of in the context of advocacy. All developers, regardless of where they sit, need guidance, need representation, need a channel over which they can communicate and share knowledge. If, in my role in developer relations, I can help with that, through two-way advocacy, then so much the better.
I strive to represent the external developer, advocating for them, helping to start or improve in their understanding of various technical areas and technologies. But alongside that, I try not to forget the internal developers, for whom advocacy is also needed. Perhaps not in as strong or direct a way ... but they're not machines, they're not robots that build software, either.
Keep on keeping on
In order to do this, there's something that is critical that I continue doing. That something is developing. The more I continue to develop, the better I can function as an advocate. If my development activities dwindle, so does my ability to directly relate to the people I'm trying to help.
So one of my aims is to continue being curious, continue building, and continue learning. That's something I've done since starting with SAP technologies over three decades ago, so I don't think I'll be giving that up any time soon.
So those are my thoughts on developer evangelism, outreach and advocacy. I'm extremely lucky and very happy to be a part of the developer relations team at SAP, and I hope that I be effective in helping developers inside and outside of SAP alike. I'd love to know what your thoughts are on this. As always, comments and thoughts are more than welcome.
This post was brought to you this morning by Pact Coffee's Planalto coffee, a breezy but warm early Monday morning, and the quieter sound of my new Logitech K380 keyboard.
Read more posts in this series here: Monday morning thoughts.
It's been just over four months since I joined SAP's Developer Relations team, and it's been a great experience so far. Primarily because of all the awesome people I now call my colleagues, but also because it helps me move towards being a better version of myself, which is what one should strive for in life, right?
Developer relations is relatively new in the world of software, so it's a subject that we can almost continue to define, or refine, as we progress. It's a discipline that I first heard of almost 10 years ago, about the same time as the advent of one of the early web-based development tools, Bespin.
Bespin
The Bespin editor, from https://blog.mozilla.org/labs/2009/02/introducing-bespin/
I remember being totally awestruck by the fact that there was a very usable editor that ran *in the browser*. Back then, it was unheard of, and for many, way beyond what we thought possible in a browser.
That early version of Bespin was, as described in the post that introduced it, an experimental prototype demostrating concepts and the possibilities that it opened up. And my goodness did it open up possibilities. Shortly after Bespin we saw the advent of another great online Interactive Development Environment (IDE) in the form of Cloud 9 - I remember going to talk to the developers of Cloud 9 at their booth at Google I/O in 2011, before they were eventually acquired by Amazon Web Services. Of course, this laid the path for what we have in the SAP world in the form of the great SAP Web IDE (and yes, I am a fan).
Anyway, I digress.
One of the folks behind Bespin was Dion Almaer, who wrote a piece on developer relations around that time, called "Developer Advocate versus Techncial Evangelist; When names change the tone" (I had to dig into the Wayback Machine to find it).
That short piece makes some points that resonate with me even today, and in my new role I try to keep in mind the thoughts that these points - about the different meanings of "evangelism" and "advocacy" - conveyed. First and foremost, they're only words, and actions speak louder. But the words have connotations that might influence those actions, if one is not mindful.
Evangelism and advocacy
Developer evangelism is a term now widely understood, as of course is the more umbrella term "developer relations" (which resonates very well with me). Developer outreach, or, more commonly, developer advocacy, is a term that is possibly less well known but to me better fits what the activities are within the Developer Relations context.
Evangelism has possibly a broadcast tone, even a religious one. To me (not necessarily to everyone), outside of the developer relations context, it suggests more speaking and less listening.
On the other hand, advocacy immediately conjures up the concept of "on behalf of". Advocating on behalf of developers. Fighting their corner, relating directly to them, acting on their behalf. Essentially, being their advocate.
Developers
But there's one question that one should consider here: Who are the developers?
For me, there are two main groups, and the goal is for them to work as one, learning from each other. The first group represents the developers that are using the software. There's a good chance that you, dear reader, fall into this group. The developers within (and beyond) the SAP ecosphere that work on a daily basis building solutions at customers and partners to solve business challenges using SAP software. This group is the most obvious group with which a member of a developer relations team has, well, a relation.
The second group are the developers inside of SAP, the teams building the software that you use, or the platforms upon which you build. I had the good fortune a couple of weeks ago to visit the mothership (also known as SAP Walldorf), and popped in to building 03 where I had coffee and chats with various people, including carine.tchoutouodjomo and then rui.nogueira (with whom I chatted about the new Application Programming Model, the interview of which can be found here in transcription and audio format, courtesy of the excellent Coffee Corner Radio podcast: Interview with Rui Nogueira on the new Application Programming Model for SAP Cloud Platform).
I also got a chance to go and meet the teams behind two of my favourite SAP Cloud Platform services: Workflow (see my Discovering SCP Workflow series) and Business Rules (one of my sessions at UI5con@SAP this year was on using the Business Rules service in UI5). I got a chance to chat with them for pretty much an entire hour, and we discussed all sorts of topics related to what they were building, features, priorities, hopes, fears, and more besides.
Meeting some of the Workflow and Business Rules team at the mothership (11:12 AM - 21 Jun 2018)
Reading back that last sentence, it strikes me that the image it conveys is that of normal people. And that's the point I guess I'm trying to make.
These folks are developers, just like you and me. And that is something that I'm mindful of in the context of advocacy. All developers, regardless of where they sit, need guidance, need representation, need a channel over which they can communicate and share knowledge. If, in my role in developer relations, I can help with that, through two-way advocacy, then so much the better.
I strive to represent the external developer, advocating for them, helping to start or improve in their understanding of various technical areas and technologies. But alongside that, I try not to forget the internal developers, for whom advocacy is also needed. Perhaps not in as strong or direct a way ... but they're not machines, they're not robots that build software, either.
Keep on keeping on
In order to do this, there's something that is critical that I continue doing. That something is developing. The more I continue to develop, the better I can function as an advocate. If my development activities dwindle, so does my ability to directly relate to the people I'm trying to help.
So one of my aims is to continue being curious, continue building, and continue learning. That's something I've done since starting with SAP technologies over three decades ago, so I don't think I'll be giving that up any time soon.
So those are my thoughts on developer evangelism, outreach and advocacy. I'm extremely lucky and very happy to be a part of the developer relations team at SAP, and I hope that I be effective in helping developers inside and outside of SAP alike. I'd love to know what your thoughts are on this. As always, comments and thoughts are more than welcome.
This post was brought to you this morning by Pact Coffee's Planalto coffee, a breezy but warm early Monday morning, and the quieter sound of my new Logitech K380 keyboard.
Read more posts in this series here: Monday morning thoughts.
- SAP Managed Tags:
