Fishing for Developer Relations

Apologies, Mortimer & Whitehouse fans, this isn't a blog about fishing.

Instead, even though it may be less perfect than that awesome show, this is a checkpoint blog, laying down what I, Peter Marshall, Developer Relations Director and source of facial expressions, believes organizations have to do to have an effective community. And what I think it stands for is "CASTS".

Hence, the fishing.

I am not the first to try and crack this nut / spin this yarn / tackle these Klingon dingleberries. DevRel as a function is ever-developing; I will not be the last to throw in my pennies unto this fountain of opinion.

Yet, in an unnervingly radical departure from my usual inner-critic, I feel that perhaps I may be uniquely positioned to offer up this model to you for your kind consideration.

In 2019, I was fortunate enough to have been thrust headlong into Silicon Valley, rather like an uncontrollable forklift entering a hedge in a field. I was gifted the opportunity to observe major players in the space. Recognizable community leaders who have worked at Informix, Confluent, Fivetran, SAP, SAS, Overstock, Vertica, DataStax, Qubole, Amazon, Elastic, Cloudera, Hortonworks, Sun Microsystems, Gridgain, Imply, Yelp, Teradata, Microsoft, and Decodable. I started knowing nothing, an outsider on the inside track, and now, four years later, DevRel has become my passion, too.

It starts with you.

Steve Halladay and Mark Herrera are educators. In 2022, we met in Salt Lake City with a documentation expert, Charles Smith, and an awesome advocate Sergio Ferragut with a seemingly simple task:

"What is the developer's journey?"

Three days and thirteen 18-feet-wide whiteboards and a detour into the world of Wheeler Dealers later, we came to answer a core question:

"Who is our customer?"

We found ourselves present at a real-life Eureka Moment: the birth of the "Cool Kid".

• They have intense enthusiasm and high energy for topics of interest and exhibit highly developed and highly specific language.

• Inquisitive by nature, they absorb a wealth of information on topics they find intellectually stimulating before others do, and can apply this knowledge to various situations.

• Rapidly processing a vast amount of information, they demonstrate advanced comprehension and abstract thinking.

• They enjoy complexity, generating original ideas and solutions to problems, as well as discovering new ways of approaching problem-solving. They can identify patterns and connect concepts in unique ways.

• Desiring freedom, space, and a bit of peace and quiet (!) they learn and solve problems autonomously.

Like Beatles fans around a PanAm Boeing 707, we all jumped from our proverbial bathtubs and screamed:

"That's it! that's our developer!"

This is no made-up persona. Within the boundaries of "reasonable creative license", it's based on a paper from 2006 by Sandra Manning called "Gifted Students". And the list of traits you will find therein is itself an aggregation of research stretching back nearly 30 years.

Together with the journey map, something magical happened: CASTS was born.

CASTS

Capability.

This is what gives community members a topic to obsess about. In our case, it's the "core" of an Open Core Community Company – Apache Druid.

It's the core that enables people to solve a problem in their work or at home. It's the spatula you never knew you needed. It's the manifestation of hope.

This is what developers want to spend hours sitting in libraries reading about. The art of the code and how it's been put together. The people who built it. The use of MMORPG character names for classes (sorry – an inside joke). It's the possibility that this thing could be connected to a beautiful web of possibility, stretching from Apache Datasketches to IoT and back again via graph theory.

DevRel is there to be the voice of the repository: come to us, and we can uncover what it is, how it fits, how it works...

...and how it could change your life!

Autonomy.

Autonomizing activities in Developer Relations get past all that rhetorical fluffy nonsense and makes it applicable and actionable.

Remembering that developers are more than capable of using personal experimentation and research to apply core capabilities, DevRel provides the community with reliable and well-known authors who provide practical content that works, building a tome of knowledge for the Cool Kids to read.

Informal and formal training focuses curiosity on the practical. DevRel is a Remmington Fuzzaway that gives developers tools and content that addresses the mundane and allows developers to focus on their passion: intricate problem-solving.

Hands-on labs, tutorials, and certification programs - anything that brings knowledge and experience. Tips and tricks, cookbooks, implementation patterns, data architectures, outline experiments, diagrams, tables, matrices – anything that allows our hero to understand the functional behaviour and make sure of the services offered by the core on their own, in the dark, where it's nice and quiet.

The DevRel aspiration is to turn first-time developers into expert practitioners - people who are ready for any battle. When they move from one problem space to another, from one org to another, from one project to another, they will take that knowledge with them. They will connect the dots and make it happen.

Cool kids work hard; their brains will not let them rest. When they've reached the summit, DevRel celebrates their success. They might even get a cool bit of swag! This isn't because brand matters.

No.

It's because success matters.

Seeing.

Being a Cool Kid can be lonely.

DevRel exists to see that isolation and – at speed – address it. People need to now that their requests and concerns are heard – that they matter as a person. "Seeing" activities reduce the fear that comes with the unknown. Things like:

• Implementing the core capabilities to solve a problem,

• Speaking in a public forum,

• Writing something practical to help other people,

• Solving problems or answering questions, and

• Contributing some code.

A seer might spot someone raising questions and problems for the community to solve in a forum. They make introductions to exactly the right person to guide and coach. Someone who's been on that road before who can talk them through the pitfalls, hurdles, and barriers.

They might meet someone having great success documenting what they did but keeping it to themselves. They shake hands and talk about red socks (a strange custom in the United States that still baffles me) and within a few days, they are pals.

"Did you know Hellmar Becker? He puts all that kind of stuff on his blog. Do you want to meet him?" Hey presto, our lonely developer is connected with someone who can help them put that content in a public blog. Huzzah! Let the UGC program commence.

They recognise educational needs, talk to them about what they're trying to achieve, and signpost them to a specific tutorial or course that they need.

An important lesson learned on formal training. Not everyone completes a course that they enrol for. They may start a course only to think they do not have the prerequisite knowledge, may start but find the answer to their specific question mid-way through a course, may feel that they’re covering ground they already know and stop, or may just feel that it’s become too much of a commitment. For this reason, it's not just a question of saying, "oh yeh! take this course!" Formal training requires monitoring and active engagement.

They check back in and follow up: "How was the course?" We look at the data: "I saw you got 90% in that certification... congratulations!" We talk about their next steps: "Would it help to meet someone who's built a real-time dynamically introspected front-end user-facing transcendental directed acyclic graph clickstream interface in AJAX before?"

Note that the developer persona for CASTS has likely already completed a POC you thought they were doing all in their mind. They're already on to the next problem. Project plans, validation events, and risk logs? Well, it's the seer's duty to track and report on that – not because it's pipeline (though of course, we know that does matter!) but because they're passionate about everyone's process of adoption being smoother and less arduous.

A community needs to understand itself, too. It needs to gather and share intelligence to remain healthy. By making it conscious of places that it needs to get better, it can respond to threats, identify risks, and do something about damage.

Take engineering. Seeing enables feedback on contribution processes and on feature issues. Or take marketing and sales: has there been a rise in potential for a particular use case in a particular geography?

A Seer maintains a big-picture view of the developers and where they live and work, recognising the needs of the global developer community and its aggregated potential. Surveys and short questionnaires, analysis of conversation topics, even configuration files, helps everyone stay sharp.

Journey traversals might also be tracked. Seers measure and inspire velocity amongst developers, working out what motivates and stifles innovation, and what interactions do and do not add value. They spot patterns and trends in issues, questions, and problems, and have begun to discuss their findings to make things better. They work to build and improve tools and processes the community uses to answer questions and solve problems.

Tutoring.

Tutoring provides developers with a buddy to help them on their adoption journey.

And not just a person who can do one-on-one root cause analysis, but someone who can calm the stage fright of first-time speakers, who can review blogs when the author doesn't have English as a first language, who can be a tester of their most recent PR. They have a wisdom that makes them a source of best practices, and they share them in lots of ways in lots of places - exactly the places that our (so far) autonomous developer has been looking at.

And beneath this surface of service is something more: a person who wants to encourage individuals to give back. They want them to create and improve the very materials that they were using in lots of places, times, and media. They want their new friend to become a participant in using more and more of the core in more and more places – and in getting more people involved in the effort.

This is exactly the place for personal brand-building to go full tilt. Our tutors shouldn't rely on the seer: they need to share content that stimulates interest in themselves as a tutor.

Without effective and proficient role models like this, you may be left with a globally distributed group of highly intelligent individuals who feel they've been misled. And for developers, there's nothing more gut-wrenchingly destructive than the guilt and embarrassment that comes from believing you misled yourself.

Social Interaction.

Seeing and Tutoring are only part of the process of combating isolation. Developers need to have places to meet people, and to build relationships with other developers.

Connecting people on a similar stage of their journey, with people who share common needs and interests, or even just people who live near them, is a critical mission for DevRel.

Socialization is all about flexing and understanding the power of individuals and networks to generate – as Mark Herrera put it – "fanatical goodwill". The intellectually stimulating social situations it is involved with get people together to activate key persona traits.

Discussion forums are where people find causes to fight for (like a big feature project), community meetups are where they find a place to tell campfire tales, and hackathons give the opportunity for group problem-solving.

Yet there is a big barrier here. And this one affects me personally...

Us developer-types find social situations unnerving. Ice-breaker activities are the stuff of nightmares. What I look for is other people saying "I'm OK, you're OK". It's OK to tell people what happened when you tried to build that acyclic graph and it didn't work first time. It's OK to tutor other people even though you're not as experienced as that person over there. It's OK to celebrate your successes. We're all OK.

Developers who have never had their potential and successes recognised, who have never met someone and connected with them intellectually, who do not recognise people at the event as someone worthy of their time and attention, do not join the club. It doesn't matter how flashy the registration page for the event is or how many times you send an email asking them to join Slack.

DevRel therefore must stand up first, and it must be the beacon of role modeling – people with extreme levels of credibility who consistently display attitudes and behaviours exemplifying what it means to be a part of this OK Community.

Take tutoring: DevRel must make itself available to answer questions, solve problems, and share knowledge. It must encourage isolated individuals (who hardly ever respond to other people’s questions, complain when documentation fails them, and sternly tell authors that their code samples don't work) to be people who freely and willingly give back because that's what they do.

Socialization provides the loud-hailers of credibility. Without these programs, there's no public celebration of those core capabilities and characteristics that the community professes to be founded on. The relationship between developer and tutor, perhaps first facilitated by the seer, increases awareness - it's a different recipe to product / technical / field marketing.

And, more seriously for open-source projects, it threatens to reduce the code to nothing more than an unloved cactus, consigned to the bin one cold morning.

Socialization provides the creative, energized spaces where capabilities are abstracted, where their applicability to other situations is expanded, where new approaches are generated, where patterns are spotted... where a fireworks display of brainpower keeps the core capabilities thrilling, exciting, and alive.