Category: devrel

Maximizing Impact: Travel as a Developer Advocate

I almost titled this post “Wasting Company Time & Burning Yourself Out” considering some of the interactions and involvement I’ve seen in the DevRel Community of late. But I’ll get to that drama and angry frustrations later in the post, but immediately let’s get down to brass tacks.

As I dive into the nuances of traveling as a Developer Advocate, it’s crucial to clarify that this post isn’t just about logistics or coping mechanisms, but about the larger strategic picture beyond just the tactical underpinnings of day to day travel, airports, train stations, and the like. Instead, I aim to delve into what underpins the demand for travel as a developer advocate. Travel is far more than just getting from point A to point B to partake in an action. It’s about positioning myself—and by extension, the organizations and efforts I represent—to make meaningful connections, drive impact in decisions, and stay ahead in a rapidly evolving industry.

Strategic Travel: Guiding the Future of Major Projects

When it comes to strategic trips, the stakes are high. These aren’t just any industry conferences or casual meetups; they’re focused events where the future of a project might hang in the balance. Take, for example, a situation where a software fork of a major open-source project is on the horizon. The decision to fork isn’t taken lightly—it’s a move that could redefine the project’s trajectory, influence developer adoption, and ultimately shape the software landscape for years to come. Being on the ground and having built connections with the people involved face to face is irreplaceable. Having just had few meetings or video conf calls doesn’t cut it, one can’t replace the built trust of time spent face to face builds. This is where traveling to where people are, as an advocate, become priceless.

In these scenarios, my travel is centered around influencing and guiding these pivotal moments. I’m there to represent the interests of my company, to ensure that our vision and goals align with where the project is heading. This might involve meeting with the core contributors, understanding their motivations, and providing insights that can help steer the project in a direction that benefits both the community and the enterprise. It’s about being at the table when decisions are made, rather than reacting to them after the fact.

Continue reading “Maximizing Impact: Travel as a Developer Advocate” →

Effective Developer Advocacy: Prototyping, Open Source, Community Building

Having worked specifically in Developer Advocacy in the past, I have well-formed opinions about how it should work and some data-driven insights into what makes Developer Advocacy effective. My experiences and observations have led me to a clear vision of what I’d like to see in DevRel teams and, more specifically, from developer advocates as a sometimes fellow developer advocate and an all the time software solutions developer/engineer/etc.

Prototyping and Problem-Solving

One of the primary areas where Developer Advocates (DAs) can shine is by creating prototype applications that tackle specific problems. Regardless of their experience level, DAs should be hands-on with the technology they are advocating for. For instance, a Developer Advocate focused on logging should dive deep into tweaking logging mechanisms. This could involve demonstrating advanced configurations, optimizing log formats for better readability, or integrating logging frameworks with monitoring tools.

For security-focused DAs, I’d make the case that attention to detail should be even more pronounced. They should not only explain the fundamentals of OAuth implementations or JWT tokens but also delve into the details that often trip up developers and be familiar – in general – with the infosec area of the industry. For example, demonstrating best practices for token storage, handling token expiration, and ensuring secure communication channels and why you should do these things would be immensely valuable.

Contributions to Open Source

Another critical aspect of an effective DevRel team is active participation in Open Source Software (OSS) projects. Developer Advocates should regularly contribute to OSS, not just through code but also by writing articles and creating content that highlights their experiences. Sharing what works, what doesn’t, and the lessons learned during these contributions can provide invaluable insights to the broader community.

Imagine a DA working on integrating two popular tools. Documenting the journey—right from initial setup, through the challenges faced, to the final implementation—can serve as a roadmap for others attempting the same. Articles that cover these real-world integrations, the hurdles encountered, and the solutions devised would be a treasure trove of knowledge for developers worldwide. They’re something, that often, is simply not available. When they are, they’re often short, rudimentary, and rarely offer insight beyond the simple happy path.

The Right Amount of Travel

I am generally supportive of the operational situation, backed by data, that Developer Advocates should keep travel engagements to around 10-25% of their work. Excessive travel—anything more than 25%—is a red flag for several reasons. These aren’t reasons I’m just making up either, because I have seen some advocates manage excessive travel pretty well, but the vast majority of people just simply don’t have the bandwidth and ability to mitigate the risks:

  1. Disruption to Focused Work: Traveling takes most Developer Advocates away from focused work on building prototypes, learning a technology, or exploring tangential aspects of what they’re advocating for.
  2. Loss of Technical Expertise: It starts the process of pulling an advocate away from their technical expertise and focus time, causing a lapse in hands-on technical work.
  3. Perception of Detachment: This can perpetuate the idea that many Developer Advocates don’t really work with the tech or have a solid understanding of what they’re advocating.
  4. Erosion of Credibility: Building on the previous points, this tends to render an advocate’s reputation useless in working as an engineer/developer/programmer, as people become highly doubtful of their technical acumen.

Building Community Through Collaboration

Effective DevRel is not a solo endeavor; it thrives on collaboration. Developer Advocates should foster a sense of community by working together on projects, sharing knowledge, and supporting each other’s efforts. They should write articles and create content that speaks to their experiences of working together. Highlighting what tools and techniques that mix well and identifying common problem points can pave the way for more streamlined development processes, spearheaded by developer advocates showing exactly how to do this at a tactical level.

For example, a series of blog posts or videos where DAs from different specialties come together to build a cohesive application can be incredibly insightful. For example at Amazon, seeing a security DA work alongside a logging DA and a front-end DA (do those exist at Amazon?) to tackle a comprehensive project would not only showcase their individual expertise but also their ability to collaborate and create a unified solution.

Improving DevRel

In my humble opinion, there are several ways DevRel can improve and amplify its impact:

  1. Hands-on Demonstrations: More live coding sessions, webinars, and workshops where DAs build and troubleshoot applications in real-time. This hands-on approach makes the learning process more tangible and relatable.
  2. Transparency in Learning: Sharing not just successes but also failures and lessons learned. This transparency can demystify the development process and make it more accessible to developers at all levels.
  3. Inclusive Contributions: Encouraging contributions from developers of all backgrounds and experience levels. This inclusivity can lead to a richer, more diverse set of solutions and ideas.
  4. Focused Content: Creating content that addresses specific, granular aspects of development. Whether it’s a deep dive into a niche feature of a logging tool or an in-depth guide on securing OAuth implementations, focused content can provide deep insights that broad overviews often miss.
  5. Collaborative Projects: Promoting and participating in cross-functional projects that bring together DAs from different domains. This collaboration can lead to more holistic and robust applications and tools.

In conclusion, Developer Advocates play a pivotal role in bridging the gap between technology and the developer community. By focusing on hands-on prototyping, active OSS contributions, and fostering collaboration, DevRel teams can significantly enhance their effectiveness. Transparency, inclusivity, and a commitment to continuous learning will ensure that DevRel not only keeps pace with the rapidly evolving tech landscape but also helps shape its future.

Note! All of these points, I’m absolutely open to debate about. This is my findings, there are a limited number of studies around this topic, and I’m more than happy to change my mind based on new data! If you’ve got any data or a different take on any of these points, I want to hear them! Let’s get a conversation going over at @Adron on Mastadon or Threads or LinkedIn!

Building Content: Corporate Channels or Personal

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.

Continue reading “Building Content: Corporate Channels or Personal” →

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.

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.