Tag: devrel

Dev Rel Thoughts, Observations, and Ideas

Dev Rel = Developer Relations

First, I’ve got a few observations that I’ve made in the last 6 months since joining DataStax (which I joined ~10 months ago) about a number of things. In this post I’ve detailed some of the thoughts, observations, and ideas I have about many of the aspects, roles, divisions, organizational structure, and related elements of DevRel.

Refining the Definition of Developer Relations

Over the last few months a lot of moments and conversations have come up in regards to DevRel being under the marketing department within an organizational structure. Which has made me revisit the question of, “what is DevRel and what do we do again?” Just asking that question in a free form and open ended way brings up a number of answers and thoughts around what various DevRel teams and even groups within a DevRel team may have as a mission. Let’s break some of this out and just think through the definition. Some of the other groups that DevRel either includes or works very closely with I’ll include too.

Developer Advocates

At the core of DevRel, somewhere, is the notion of advocacy to the developer. This advocacy comes with an implied notion that the advocates will bring solid technical details. These details then are brought to engineering and in many cases even contribute in some technical way to production advancement and development. Does this always happen among advocates, the sad honest answer is no, but that’s for another blog entry. At this point let’s work with the simple definition that Developer Relation’s Advocates work from a technical point of view to bring product and practice to developers in the community. Then take the experience gained from those interactions and learning what the community of developers is working on back to engineering and product to help in development of product and in turn, messaging. To be clear, I’ve broken this out again just for emphasis:

“Advocates work from a technical point of view to bring product and practice to developers in the community. Then take the experience gained from those interactions and learning what the community of developers is working on back to engineering and product to help in development of product and in turn, messaging.”

I feel, even with that wordy definition there are a few key words. For one, when I write community in this definition I have a specific and inclusive context in which I use the word. It includes customers, but also very specifically includes non-customers, users of similar competing products, prospective customers, and overall anybody that has some interest in the product or related topics of the product. In addition to this, product needs clearly scoped in this definition. Product means, for example in the case of the Spring Framework. Product wouldn’t stop at the finite focus on just Spring and it’s code base and built framework product, it would also include how that framework interacts with or does not interact with other products. It would include a need for at least a passing familiarity, and ability to dive in deeper if questions come up, into peripheral technology around the full ecosystem of the Spring Framework.

If there’s any other part of that definition that doesn’t make sense, I’d be curious what you think. Is it a good definition? Does adding specific details around the words used help? If you’ve got thoughts on the matter I’d love your thoughts, observations, ideas, and especially any opinions and hot takes!

Curriculum

Curriculum Mission: How to Effectively Learn and Share Product Knowledge

Often a developer relations team either includes, might be part of, or otherwise organized closely with curriculum development. Curriculum development, the creative and regimented process of determine how to present material to learn and teach about the product and product ecosystem is extremely important. Unless you’re selling an easy button, almost every practical product or service on the planet needs at least some educational material rolled into it. We all start with no knowledge on a topic at some point, and this team’s goal is to bring a new learner from zero knowledge to well versed in the best way possible. Advocates or dedicated teachers may be tasked with providing this material, sometimes it’s organized a slightly different way, but whatever the case it’s extremely important to understand what is happening with curriculum.

Let’s take the curriculum team at DataStax for example. They build material to provide a pathway for our workshops, all day teaching sessions, the DataStax Academy material and more. Sometimes the advocates jump in and help organize material, sometimes engineers, and others. They do a solid job, and I’m extremely thankful for their support. It gives the teachers, which in many cases it’s us advocates, a path to go without the overhead of determining that path.

However…

It is still extremely important, just like with the advocates’ roles of bringing community feedback to engineering in an effective way, we need to bring student feedback and ideas to increase the curriculum effectiveness back to the curriculum team itself. As we teach, and learn at the same time, we find new ways to present information and new ways to help students try out and experiment with concepts and ideas. Thus, again, advocates are perfectly aligned with the task of communicating between two groups. Ensuring that this communication is effective as well as curriculum material is one of the many core skills for developer advocates.

In the next post on this topic of refining, defining, and learning about the best way for DevRel to operate here’s some topic thoughts:

  • Twitch Streaming – How’s it work and what’s it give me? What’s it give the prospective customer, community, and related thoughts.
  • Github – What’s the most effective way to use Github from a DevRel perspective? Obviously code goes here, but how else – should we use wikis heavily, build pages with Github Pages to provide additional information, should it be individual domain names for repos, what other things to ask? So many questions, again, a space that doesn’t seem to be explored from a DevRel perspective to often.
  • Twitter – This seems like the central place for many minds to come together, collide, and cause disruption in positive and negative ways. What are some ways to get the most out of Twitter in DevRel, and as Twitter becomes a standard, basic, household utility of sorts – what value does it still bring or does it?
  • LinkedIn – It’s a swamp of overzealous and rude recruiters as much as it is a great place to find a job, connect with others, and discuss topics with others. How does one get value or add value to it?
  • StackOverflow, Hacker News, and Other Mediums – What others sources are good for messaging, discussions, learning, and related efforts for people in the community that DevRel wants to reach out to?
  • Value for DevRel – DevRel provides a lot of value to the community and to prospective customers of a product. But what provides value for us? That’s a question that rarely gets approached let alone answered.

I hope to get to these posts, or maybe others will write a thing or three about these? Either way, if you write a post let me know, if you’d like me to write about a specific topic also let me know. I’ll tackle it ASAP or we can discuss whatever comes up in this realm.

Summary

This is by no means the end of this topic, just a few observations and all. I’ll have more, but for now this is what I got done and hope to contribute more in the coming days, weeks, months, and years to this topic. DevRel – good effective, entertaining, and useful DevRel – is one of my keen interests in industry. Give me a follow, and I’ll have more of these DevRel lessons learned, observations, and ideas that I’d love to share with you all and also get your feedback on.

Adding and Returning Value to the Community via Twitter, LinkedIn, and Twitch

Twitter-512Twitter

Goal: Grow our follower count and reach, entertain, laugh, make hot takes – as one does on Twitter, educate, and get value out of it ourselves.

Don’t!

  • Don’t buy followers (i.e. don’t pay anybody that promises X followers, market share, or whatever it is they’re selling). We can’t trust this method as it’s often just a pile of Russian bots or other garbage followers. This does nothing to increase visibility and penetration to those that want, are interested in, or need to communicate with us (i.e. customers and fans).
  • Do not just repost things via RT or use tooling to just post arbitrary things. People notice this and won’t follow or will unfollow you. It’s a sure fire way to be blacklisted as *marketing* which will involve going to zero eyeballs, even when the account statistics keep showing people see it.
  • Do not post identical or similar content one tweet after another. i.e. Don’t post a marketing blurb with one image, then post another marketing blurb with another image that’s exactly the same size, theme, and fill up the entire tweet stream this way. The followers you get will not be active, will not be who you actually want to speak with or interact with, and don’t really add value over time if this is all that is done. It’s similar to those blog theft sites that just re-post the exact RSS stream and then, by proxy, get blacklisted and erased from Google/search results.

Do!

  • Just make it about you. Grow your personal brand first and foremost. Such as “Dern this is a wicked awesome band.” or “Wow, best burger in the world” and add pictures, content, and other interesting things for people. It doesn’t have to be “I just cured all diseases yo, check me out!” you can, and people will follow based on honesty, integrity, taking a stance, being informative, and providing useful information of all sorts. But more than anything they’ll follow the person not any specific *thing* you’re selling, pushing or what not. So be yourself, share, and be involved with the network you create.
  • Build things you’re interested in, especially when they’re related in some way to products and services you like to use and find interesting – i.e. Apache Cassandra, DSE, Databases, Application Development, etc. Build on these things via threading, via initiating discussion with others that are discussing these things, and among all this find valuable fellow Twitterers that you want to be connected to. This helps all involved, you, your network, the company, the people and companies you connect to, and more. Bringing the network wide with an on point effort around topics will dramatically increase your collective opportunity but also anything and everybody around you.
  • When retweeting, intersperse it among other things, and happily add content to RT’s. In other words don’t just make it endless retweets, but just throw in a few retweets for things you’re interested in or support, and then have your regular stream of tweets, links, and other content.
  • Use emoticons, use pictures, and definitely blurt memes out there. Aim to have fun with Twitter.

Examples of good Twitterers that really provide high value to followers, but also back to the Twitterer themselves in the way of speaking opportunities and all sorts of other things:

LinkedIn-512LinkedIn

Goal: Build an extensive professional network and return value to the LinkedIn Network of connections you have.

Don’t!

  • Don’t use LinkedIn like Facebook. This is obvious but for some reason much the world doesn’t seem to get this, so it feels like it needs stated for the LOL’s. i.e. Don’t hit on people, don’t ask people out on dates, just talk business. Ideally leave politics out of it too.
  • Ideally, don’t send droves of InMail messages to people unless that’s specifically the game being played on LinkedIn. For more grassroots and non-marketing community focus, just interact with people directly, that you know, and don’t arbitrary chase down people you do NOT actually know. This is another thing that decreases authenticity, and makes an individual – even if not – appear like they’re shilling for something.

Do!

  • Post content regularly about what you’re working on, provide links, and provide respective researched content for other mediums you might have like Medium, a blog, Twitter, and all that jazz.
  • Talk about your professional achievements and whatever else that might come up related to your work, hobbies (pending some business relation or something you do/did professional, i.e. like the music you play, or other hobby of sorts). Sometimes hobbies count too, so put that content into rotation now and again too. But do remember, if it fits better on Facebook than LinkedIn, just don’t post it on LinkedIn.
  • Reach out if there is legitimate business that you are both involved in. Start that as a simple conversation, not a sale, not something pushy, just simple, friendly, curious conversation.

Examples of good LinkedIn Accounts, that use their accounts for benefit for themselves but also provide benefit directly or indirectly for all of us:

iconmonstr-twitch-5Twitch

Goal: Grow our follower count and increase our collective content and work material to show, teach, work, and hang out with viewers to build tomorrow’s best, most kick ass, wicked awesome applications, data science analysis, and more!

Don’t!

  • Not a whole lot here yet. Twitch is kind of wide open and not a lot of no no’s here. Don’t do illegal things is all I’ve got at the moment.

Do!

  • Setup your OBS or streaming process so that you have chat on screen, chat somewhere you can monitor it, code is clear and fonts are readable, you add all the interaction content you can for new follows (alerts), subscribes (alerts), and whatever else comes up.
  • When on stream, take your time, interact with people that follow, subscribe, or chat/whisper with you.
  • Don’t worry about making mistakes, just work through them, let the audience help if they offer it. Even if you know that they’re wrong, work through things with them and let them get involved. Then lead into the correct fix, etc. This is a great way to teach and build involvement on stream so that everybody gets a win, and you get an advocate to your own advocacy.
  • If you’re going to heavily curse or do anything even slightly liberal/conservative/religious/ideological etc it’s probably best to mark one’s stream as 13 or older (I think that’s the setting).

Some excellent Twitch streamers to reference for their involvement, OBS setup, configuration, and general awesomeness in the community.

That’s it for this post. Got more do’s or don’ts? Lemme know, will start a repo!

A little lagniappe for ya, that hygge feeling.

4 Discovered Axioms of #DevRel

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!

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Behind the Scenes @ DevRel Week in Santa Clara & San Francisco

The following are some lagniappe, a little extra, about the behind the scenes adventures I’m off on when I travel or am in between coding. Ya know, coding being life and all.  😉

The first episode in this series I posted a while back on my gear I use to record the Twitch sessions and pretty much everything else. These are the story of the first half of the trip to Santa Clara and San Francisco. The rest, are still in post-production, and will be out real soon. Along with videos on a host of other adventures that will offer you good information on where the good food is, the best coding places, best meetups, and all that stuff. So subscribe on my Youtube Channel and on Twitch – the shows are coming to Youtube, and now and again I’ll pre-watch one with my Twitch audience. Cheers!

DevRel Data: Presentation & Deductions

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?

chart

What specifically do you, or would you like to watch in video? Screencasts, short videos, conversational, or some other type of videos?

  • Screencasts/tutorials
  • 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.
  • Screencast
  • 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)
  • conversational
  • Short videos.
  • 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.
  • short videos

What kind of written material do you like?

chart2

Do you like other material mixed in that details the reason for the tech, the story, or such?

chart3

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

Deductions

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?”

  1. Make screen casts.
  2. Make screen casts generally short.
  3. 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?”

chart

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!

End of story.

For more on this information, why I asked, and what I do check out my article titled “Evangelism, Advocacy, and Activism in The Technology Industry” and for some of the big victories for big corporations check out “The Developer Advocates – Observations on Microsoft’s New Competence“.