I proposed this sessions as I was interested to discuss the idea of developer advocates and how that relates to developers looking to move into that type of role. I was also interested in the difference between advocates that are paid/funded and someone who is advocate for their own brand/project’s sake. Please feel free to add any thoughts on Twitter #jalbaAdvocacy.
What is an Advocate?
It made sense to start off by defining what an advocate is and Matt kindly took the role of scribe. It was broadly agreed that an advocate is a champion of a specific technology or idea. They champion their perspective over various media channels and are often regular conference attendees. The term evangelist came up and it was an open question as to whether this was the same as an advocate. Like many things in our industry there is some overlapping and terminology that isn’t well defined - so it’s probably safe to assume they are the same.
It was broadly agreed that the advocates are often role models for developers and respected as a thought leader.
Open Source Advocates
In the community there are several advocates that are not paid/funded. Examples that come to mind is the Java Champions and Robert Scholte who advocates and works on Apache Maven. There’s also a baseline of advocacy for Java itself happening at a user group near you.
Community engagement is a core attribute required of advocates. Though it is interesting that the community is also somewhat self advocating through their members. Simon Maple is an example of someone who has consistently put the London Java Community on the global JUG map.
Internal vs External Advocate
The conversation turned to talking about the idea of an internal developer advocate. It was pointed out that some of the larger companies in the world have 10,000+ engineers, which is a huge community in itself. Trying to justify the cost of any specific role in a company can be tricky, a recommend read is The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success. The book contains guides in justifying value, but also more practical topics such as how to run a meet up.
When discussing the idea of an internal vs external advocate one point that came up is feedback bias. Internally you may not get a true representation of the idea, and perhaps be bias towards existing solutions and technologies. In the converse external community the feedback may not be as direct as perhaps internally. Overall it was felt that you’d be likely to get more honest feedback from the community. One option is to host meet ins where the community comes to the company, overall this boosts group numbers from your own staff.
How (and why) Would You Become an Advocate?
From a few of the stories in the room many advocates had become an advocate by accident. In the examples presented both had been developers on a team with a motivation to present, share and participate in the community. In one example it had lead to the developer becoming a full time advocate, as his company and team did not see the value. In the other situation it lead to the developer becoming a full time technical trainer for several years.
One question raised is now advocates are more familiar roles can you become one without any programming experience? It was generally felt that this would be really tricky and would probably represent more of a sales role.
One advantage of becoming an advocate is building your own brand as an expert in a particular field. We all start with limited knowledge in a particular area and are on a path to technical excellence over time. Once you hit the point where you are actively demonstrating this to a community you are likely an advocate by accident or a drive by advocate.
There are advantages to building internal technical communities, especially if you can get board level support for this. Ensuring that there are active feedback points will ensure that the community remains relevant to the technology group.
One point made was that blogs, creating talks and coding examples can put a lot of pressure on a developer. Usually something gives, one possibility was to go independent - but this can be a daunting prospect depending on personal circumstances.
Some people (myself included) have a personal/open source backlog that they look to take topics from and explore. Some of the tasks may be within your comfort zone, other tasks might stretch your understanding. Coding and demonstrating this in front of a bigger audience had mixed value, depending on the delivery. We all agreed that Josh Long’s style is awesome for this kind of demonstration.
Many people mentioned the idea of not being able/wanting to emulate someone else. This is completely fine, in fact you should not try to be someone else, but like with any mentor or role model you can take a little bit of everything you like and form your own style.
One final question posed was more around the balance of developing and advocacy:
If working on blogs, teaching and personal development had been supported by your manager would you have left for full time advocacy?
It revealed a key point that managers tend not to focus on the value demonstrated by learning, tinkering and becoming an expert. Interestingly this idea of opportunity, personal development and in some cases advocacy is an active line of thinking in our team.
Summary
- The definition of advocate and evangelist is a little hazy. It would always be worth reviewing what the role entailed before jumping to any assumptions.
- Community engagement is key to becoming an advocate. In a non paid or community style advocacy the community becomes somewhat self advocating.
- Advocacy has historically happened by accident, it will be interesting to see if this continues now more roles are available. There will always be advocates by accident or a drive by advocate.
- If your internal community is big enough having an internal advocates program could be an advantage.
- Maintain your own personal/open source backlog, keep an eye on what you want to do.
- Advocacy and advocacy types of activity take time, this has often lead to developers leaving their current role to become advocates. Support and understanding from management can help retain and foster a team of technical excellence in different fields.