Before getting into this topic, let’s get clear definitions for Corporate Channel and Personal Channel for the context of this article with an added specific detailed definition for “advocate” and “advocacy”.
Corporate Channel: This is the channel of communications that falls within the realm of a corporate blog (like Digital Ocean’s Blog which is one of the best, HashiCorp’s, or New Relic’s are all examples), corporate Twitter account (the best of course are one’s like Wendy’s), and the normal slew of stuff on LinkedIn and Facebook. Largely, in all honesty developer’s rightfully just ignore the huge bulk of junk on both LinkedIn and Facebook. The other part of this channel is of course the plethora of ads that rain from corporations, but those aren’t anything to do with advocacy as you know except in a disingenuous way.
Personal Channel: This is the channel that often advocates work with most. This is advocacy that they work with and build up within the community that is largely autonomous of the corporate channel. However there is always a corporate entity – their employer or otherwise related – that will of course benefit also. But first and foremost the personal channel is one that an advocate builds for themselves, the community, and a particular technology, language, or other thing that they’re interested in. Above all things, from an external point of view this is where people who follow or consume an advocates gain trust for that particular individual.
Advocate/Advocacy: In this article, note that I’m using an expanded notion, simply put if you’re on Twitter or Github or somewhere public in even the slightest way you are indeed an advocate and providing advocacy for some technology product or platform. This includes people with titles like Developer, Engineer, Architect, or whatever else that has a professional presence online.
The idea of DevRel, or Developer Relations and the position of Developer Advocates in the industry has become more defined in the last decade than it traditionally has been. In getting to this point there are several key points that have come up that are practical axioms in industry. Some people don’t agree with all of these, and I’d infer that they’re probably just wrong, but the vast majority in industry and specifically working in DevRel itself have these axioms that they’d often stand by. If not march up on the hill to fight for!
Developer Advocates and Developer Relations should NOT exist under any marketing hierarchy. Microsoft killed off this organizational structure, Google never let it happen, and AWS also insured this isn’t how this operated. If anything it’s either it’s own branch feeding directly into the executive team under the CTO, or it is a breakout of the engineering group usually under a VP of engineering or related structural organization. Having Developer Advocates under marketing tends to bring out bad habits (forced talks at trade shows that are just the company spiel) or topics that just don’t align to anything (like talks on X feature that nobody uses implemented in a way that is broken). The end product of having Developer Advocates and Developer Relations work and report up to a marketing leadership hierarchy devalues their work, what they can and indeed do provide that is valuable, and can diminish the credibility that advocates have to fight for so diligently in the first place. For further ideas around this axiom, Francine Hardaway also wrote a great post on just this issue, asking where DevRel should exist.
DevRel & Developer Advocates need to be self-disciplined, build, show, and be technically inclined as much as any software engineer, coder, hacker, or related individual is expected to be. I’m not talking about “make nonsense deadlines and work to death” like some development teams get stuck with, but we advocates do need to build solutions that parallel or innovate on the designs that are in place, in production, and giving us value today. Developer Relations at its core is there to bring value and show value in what X solution can do but needs to provide example and take what exists in industry and build on it.
Developer Advocates serve a two way street of communication, one to developers and users and one back to the internal engineers, product, and leadership working on building products and services. Advocates collect, or as I sometimes call it, perform reconnoiter or reconnaissance, and bring that data back to the various teams within company to determine actions to take. I personally love this part of the job, since I like to make sure that the development teams have the information they need to build products and services that are really needed, valuable, and will get the most bang for the buck. I’ve also never met a developer that doesn’t want to know the direction their developing in is the right direction. This kind of direct data is an invaluable information base for the development teams.
Developer Advocates do not always work directly with customers, but we do indeed and should be communicating with them on a regular basis. Helping to organize discussions, conversations, and future directions of research for product and services usage is very important. We can act as that individual or team for companies that often don’t have enough time to put somebody on a research project, where as we can do that, and provide general information deducting what is or isn’t’ the right path to travel. As developer advocates we have the freedom to often take the path of risky research. We provide an extremely valuable service to the companies we work for, the customers we communicate with, and the industry as a whole by doing this research and making it available (i.e. blog it!)
Got anymore axioms you see in industry around DevRel work? I’d be happy to put together a larger list, this is just the beginning so far as I begin the first steps of a journey into understanding future directions and detailed specifics about how advocacy can increase its value for company, customer, and personal efforts.
Before diving into conclusions, let’s take a look at some answers to questions asked. This is a slice of answers, with totals for the charts and such. After a few months of answers I’ll have another follow up to see how things may or may not change.
Do you like video material?
What specifically do you, or would you like to watch in video? Screencasts, short videos, conversational, or some other type of videos?
I love both screencasts going through big topics and short videos that cover smaller tips and gotchas.
Videos with a specific outcome as the goal, whether achieved or not. Showing the process of something.. like hey, here’s how you building out a Postgres cluster using streaming replication and repmgr and pgpool… Kind of thing.
Bite sized content, maybe 2 minutes, to teach me one thing.
Editing. No jokes, no “hey what’s up guys” with 60 second intros. Discuss the problem, then solve it.
Demos, learning a new way of doing something
Doesn’t matter short or long, but has to be deeply technical with code examples that I can actually apply
I watch videos mostly for fun.
Short videos of say 5-10 minutes each covering different concept of the subject matter
(videos work best in a classroom setting where time/attention is precommitted, or as part of a tutorial)
If it’s too long, it ends up on my todo list forever (not good). So shorter is better. And something that benefits from visuals, rather than something that could just be written.
I also watch LinkedIn Learning when just starting a new tech. to get a general overview and pick up a tip or tow, then I read books and the Internet from there.
What kind of written material do you like?
Do you like other material mixed in that details the reason for the tech, the story, or such?
Is there anything that comes to mind, that you’d like to have me or the team I’m working with (@ DataStax) put together that you’d find useful, entertaining, or related.
Place priorities on designing materials for more depth (i.e., more linked material) as well as less attention-nuisance. That’s no criticism of your work, merely the gestalt of where we work — so less noise is a better way to stand out and make materials useful.
Maybe focus more on written material – code & architecture material (books, articles) rather than videos and twitch. It is much easier to consume and is easily googlable. Also I’d suggest making blog posts target a specific common issue or question – sometimes I see posts that I don’t really care about or the problem is so narrow that I don’t want to read about it. I’d read about building resilient and highly available architectures in various configurations.
Database reliability, scalability, migrations and such stuff is interesting.
Anything to do with machine learning.
Data model examples, starting up a Cassandra node, configuring YAML, etc
I’m going to go backwards through the questions and discuss what I’ve deducted, and in some ways what has surprised me among the answers!
First there’s the “Is there anything that comes to mind, that you’d like to have me or the team I’m working with (@ DataStax) put together that you’d find useful, entertaining, or related.” request and questions.
The answers here didn’t surprise me much at all. Within DevRel from Microsoft to DataStax to Google to many other organizations we have this ongoing battle between “write a whole book on it” or “make it 2 minutes short”. It’s wildly difficult to determine what format, what timing, and what structure material needs to be in for it to be most useful to people. So when I saw the answer that reads, “Place priorities on designing materials for more depth (i.e., more linked material) as well as less attention-nuisance.” I immediately thought, “yeah, for real, but ugh…” it’s difficult. However, I’m working on more thorough material, some of it will be paywalled via LinkedIn Learning or Pluralsight and other material may be available by book in the coming months. But there will be other material that will indeed be long form how to material on how to really put things together – from scratch and from the basis of “we have X thing and need to hack it so we can add a feature”.
The next answer I got in this section that I completely agree with is increasing the focus on written material. I’m making tons of video, and I’ve got that down to the point where it’s actually easier and faster to do most of it then it is to write things down. However I realized, especially from my own point of view, that written material actually ends up being vastly more useful than video material. That’s also why, even with the video material, when I’m covering specifics I aim to provide a linkable timeline and a blog entry with the code and other changes shown in the video. Thanks for reinforcing these efforts and giving me that indirect encouragement to make this process and the results even better. More written material is on its way!
As for the database reliability, scalability, migrations, machine learning, data modeling, Cassandra node starting, and all that it’s in the queue and I’m getting to it as fast as I possibly can.
Next question I asked is, “Do you like other material mixed in that details the reason for the tech, the story, or such?”
It appears, albeit not a huge contingent of people, some people are curious about biking, train coding, and making good grub! Hey, that’s groovy cuz I’ve got a show coming out which is basically the behind the scenes videos about all those topics that make the coding and technology hacking possible!
The one outlier in this set however is clearly the request for “Ways to simplify life to dig through those algorithms faster, easier, better?” which I didn’t suspect would be any different then the other answers for this questions. Which left me surprised and ill-prepared on what to do about fulfilling what is clearly a demand. I’ll have to up level my blog posts around algorithms. I did do a couple a long while ago now in “Algorithms 101: Big Sums” which I completed in Go and another I wrote up “Algorithms 101: Roads & Town Centers” which I have 90% of the answer complete but I’ve never finished the blog entry! I guess it’s time to get the algorithm train coupled up and ready to depart!
Then the question, “What kind of written material do you like?”
Two options lead by a healthy margin for this question: Demos w/ Write Up and Blog Articles. With this coupled up to the first question it’s clear that written material via blog and demoes via blog should and ought to be top priority. They are, however they’re a whole helluva lot of work, so I only get them produced but so fast. Got some gems coming on Go, Bash, Cassandra, and a few other demo, tech, and historical information.
Next up was single page cheat sheets and documentation, followed closely by books. I kind of expected documentation and books, but wow that single page cheat sheets option is higher rated than I would have suspected and by proxy I’ve immediately added that to my produce this type of material list! I put it in as a very secondary thought but it’s going to get into that increased focus queue.
The last one with some semblance of demand is pamphlet size short form. This one almost seems like a fluke, but I’ll ponder putting together some of these. I know O’Reilly has their short novelette size books which cover a particular topic. They hand these out for free at conferences and seem pretty solid. Maybe I’ll work one of those into the queue? Maybe.
The other three options scraped by with 1%, so somebody was choosing them. So the vi mug isn’t a priority nor the short explainer videos. Which seems in contention with video content demands around shorter content. I guess, explainer videos just doesn’t sound useful!
The next question I just put together a top three of the results, “What specifically do you, or would you like to watch in video? Screencasts, short videos, conversational, or some other type of videos?”
Make screen casts.
Make screen casts generally short.
Make screen cases that are short and on a specific and deep dive into a topic.
This seems kind of in conflict with itself, but I’m going to aim for it and try to hone the skill further. So that I can produce screen casts, screen casts that are generally short, and make sure that these screen casts that are short are on a specific and deep dive into a topic. Whew, got it.
Finally, “do you like video material?”
At this time, 53.8% of you have said yes. I had guessed it would be around 50%.
I had guessed no would be about 25%, and at 23.1% I wasn’t to far off.
The other respective mishmash of answers made for interesting depth to the questions that followed this question.
Article Summary & TLDR
Produce more topic specific, detailed material around screen casts and blog entries!
I’ve got a few thoughts and ideas I’m going to write about here. These thoughts will connect the reality of evangelism and advocacy with the often imagined notions of what advocates and evangelists may do in their respective roles.
I’ve spent a number of years working in what is commonly referred to as evangelism and advocacy in the technology industry. Most of it has been focused around software development, development practices, and related topics. In addition to the years I’ve worked around evangelism and advocacy I’ve also done a fair bit of it on my own for my own purposes around community development, conferences, and other related things. The companies I’ve worked with as advocate or evangelist include; Basho, Tier 3 (now Century Link Cloud), Home Depot, and others.
Recently a whole slew of people got hired at Microsoft. Many of us have taken notice. It’s left a lot of people with questions like:
Why would Erik, Ashley, or Jesse work at Microsoft?
Doesn’t it seem suspicious?
I wonder what kind of cash they allocated to that payroll budget?
Does Microsoft hire anybody that actually uses Microsoft tooling anymore?
I’m confused, what is even going on?
The answers may be more obvious for those of us that have kept an eye on Microsoft. There has been this grand upheaval and cultural change that has occurred. CEO Satya Nadella has legitimately shifted the culture in a way that much of the company has wanted to go. Somehow, he’s also managed to start changing the culture even for those that weren’t sure or didn’t want to go.
Satya has taken what core individuals like Scott Guthrie, Scott Hanselman, and many others have hoped for and pushed for over the years and started to enable the people within Microsoft to make this happen. You can read plenty about how Microsoft has gotten it’s groove back, and about the work the Scotts and others have done to get that groove going. But I’m not particularly writing about that, but it has inspired this article in a big way. I’m going to elaborate on what I’ve observed and what I know to make a strong, effective, useful, and community focused developer advocate and developer advocates team.
The developer advocate team over at Microsoft is led by Jeff Sandquist, Brian Liston, and a few others. They’re solid individuals with good ideas about how to build and have an advocate team contribute effectively to the community in which it works. Here are the top three obvious things they’ve done that have made the team effective, relevant, intelligent, and useful.
The team is diverse. I’m not even going to play around, diverse teams with many ideas and a range of people do better. End of story, it really ought not to be complicated these days. But one can’t just start a team and say “I want my team to be diverse”. That’s a start, but the important part is does one know how to build a diverse team? In technology, if one doesn’t have insight into actual human begins this doesn’t pan out so well. One has to have the ability to communicate effectively to people out of the tech nerd guy stereotype trope in order to actually build this type of team. Jeff, Brian, and crew appear to have this ability. I’ll write more on this later, but suffice it to say, this is a top skillset of a developer advocate team’s leadership.
The team has to be skilled at a variety of complementing technologies. If someone knows X, and the next person knows X, and nobody knows Y, then the team is going to be fairly weak and likely broken in representing and providing value around Y, and in some sense even around X. At this point the Developer Advocates that have been introduced have some pretty extensive skillsets around key technologies that the Microsoft Technical Evangelists have traditionally been extremely weak in. This current team has some skills in the Windows space, but there’s been a big focus in filling the massive skills gap around Linux, cloud technology (ironic there’s traditionally been such a gap on the cloud team), non-MS languages like Go, distributed systems, data analysis and intelligent (or data science or whatever one may call these roles), and more. The Advocate team (also not called evangelists anymore, finally) is finally in a good position to actually start doing advocacy around actual cloud technology. I’m excited for the potential of the prospects!
The third thing that has stood out, is that they’ve hired people that know how to do the advocacy thing already. They’re not trying to define or redefine it on Microsoft’s terms but instead have brought people onboard that are already natural advocates of things they find interesting. Take Erik St Martin (@erikstmartin) for example; co-authored a book, “Go in Action“ with Brian Ketelsen (@bketelsen), co-hosts Go Time FM. That brings up another great example with Brian Ketelsen. Both of these guys are hug advocates in their own right, without connection to any specific big company or what not. These are the types of people that bring huge strength to a team with already proven ability to delivery. Then there’s Jesse Frazelle, but seriously, I really don’t even need to mention the work she’s done with containers (cough cough, docker, etc). Another person you should be watching is Anthony Chu (@nthonyChu), who’s been a steady Azure and great technologies advocate over the years, also joined up. You can read more about the individual team members here, and I hear through the secret grapevine that there are more en route to join. Simply put, Microsoft isn’t pulling their punches!
Now the thing to wait and see is if the team and the team’s leadership can direct all of this energy into their respective efforts. The team is big, lots of people, lots of focus points. How will they use each others’ strengths while building up along core competencies? How will they provide value without detracting from product and push product without losing community value? There are a lot of questions to be answered and I’ll be keeping a close eye on their efforts. As I do with all of the advocacy teams I find fellow interests in. The advocacy, effectiveness, and reasons for it all has been an interest of my own for some time. So much so you can expect more than a few more articles on this topic, until then, cheers!