20 February 2023
This, like so many other pattern languages before it, looks to catalog, categorize, and through that effort, provide some clarity and/or guidance on the various activities practiced by the various members of a Developer Relations team. As with all pattern languages, it's not intended to be a tutorial, but more of a reference, and as such could easily see additional edits and clarifications as time progresses.
The first part of this discusses some meta-elements about this particular pattern language; if you want to jump straight to "the good stuff", jump to the Activity Catalog.
Note that many of these activities will depend on other, non-pattern activities, such as developing a target persona, that will help drive most (if not all) of the activities--for example, knowing DevRel's target persona/personae will help identify which conferences, which session topics, the articles to write, and so on.
The most basic pattern form I prefer is the simplistic one that states that "a pattern is a solution to a problem within a certain context that yields certain consequences". This then yields the four-element Problem-Solution-Context-Consequences tuple, consisting of each element described (and adapted slightly for our purposes here) below:
Name: preferably short, descriptive, and memorable.
Building Blocks: from my earlier ontology: Code, Presentation, Social, Writing. Often a given activity will be made out of two or more of these simultaneously, in a rough order of criticality; for example, a Code, Writing pattern will be better assigned to somebody who has stronger code skills, while a Writing, Code pattern will probably yield better results to somebody who has strong writing skills. (Ideally anybody would have strong skills in both, or all of the above, but then we get into the Full-Stack Developer Fallacy, this time for Developer Advocates.) In addition, I've added a new building-block category, Budget, meaning non-trivial monetary amounts that the activity will require; a Budget activity is generally one that's amenable to "throwing money at the problem".
Problem: a (preferably brief) description of the problem a team faces. Note that in many cases, the problem section in a pattern will be duplicated in another pattern--this is not in error, because a given problem can have multiple solutions to it, and both the context in which the problem lives and the desired consequences will help determine which pattern is most appropriate for use.
Solution: a (preferably brief) description of the solution to the problem.
Context: this will generally be certain constraints or additional elements around the problem that will influence the outcome--a common one, for example, being employee bandwith (the amount of time a team has to devote to the activity) or budget (the amount of money).
Consequences: the consequences are those that can be expected from application of the pattern's solution to the problem within the given context. Note that not all consequences will necessarily be positive--much of the benefit of the pattern approach is the realization that there is no "perfect solution" or "best practice", and that certain negative elements may arise out of the use of the pattern. Part of the decision-making criteria, then, is to examine the consequences, and determine if the positive consequences are what the team is aiming for, and the negative consequences "livable" or not really negative in the company's particular case. Additionally, many of these activities can overlap in their execution--creating a presentation for a conference session can also be repurposed into an article or blog post, and many presentations can come together to form the spine of a book. Where some synergy exists with other patterns, this will be mentioned in the consequences section.
Additional elements to the pattern form are possible/likely, depending on the individual pattern: