Originally published on Medium in July 2023.
“So how does someone with a film degree end up working in tech?”
That’s a question I am frequently asked. To me, the transferable skills are obvious: a movie is the culmination of many teams, talents, and technologies pushing towards a singular vision. Often, the vision that audiences see on screen is vastly different from the original vision from the pages of the screenplay; the result of challenges, obstructions, blockers, and feedback during production. As the vision evolves from script, to storyboard, to a set with actors, and to an editor’s hard drive, the director must navigate the perspectives and expertise of a diverse set of professionals. Without collaborative problem-solving, the movie may die, or worse — flounder in theaters and reviews. Plus there is always an executive producer in charge of the money, demanding to know why production is behind schedule, even though no one could have predicted — or controlled — a storm sweeping through the location, shutting down production for a week.
Even after traversing those challenges, it’s impossible to know how general audiences will receive your hard work. You made it look so easy that they think they can do it better, but they would have no idea where to start!
When it comes to developer relations, my unconventional path to tech is actually pretty typical. This field is populated with people for whom tech is a second or even third career, or who stumbled into it unexpectedly. I don’t have definitive evidence for why this is, but I have some theories and anecdotal evidence.
- Developer relations is about relationships, so those drawn to it tend to have an affinity for people, whether it’s teaching, demonstrating, supporting, or — as in my case — just genuinely liking humans.
- Developer relations is inherently cross-functional, and the responsibilities require a diverse skillset. So our prior experiences as social media managers, biology students, and artists mean we already have a broad collection of tools at our disposal and can easily shift frames of reference to tailor our language according to context.
- People in developer relations often have a thirst for knowledge and learning, which means we’re practiced at quickly picking up new concepts and skills.
In my case, I’m driven by a congenital dopamine deficiency that compels me to seek out novelty, fixate until I achieve mastery, and then joyfully share with anyone who will listen!
Moreover, as novices traversing the equally triumphant and despairing path of learning repeatedly, we are closer to the beginner’s mind perspective. It’s imperative to access the beginner’s mind to create relationships with developers that organically evolve into community champions. We empathize with our users because we are always in their position.
Another trait shared across developer relations is trying to answer the pervasive question: “What exactly is developer relations?”
An Evangelist, an Apple, and George Orwell walk into a sushi bar: The history of Developer Relations
Although developer relations may seem like a recent specialization, the concept has been around since the 1980s when Mike Murray coined the term “software evangelist.”
Murray was studying for his MBA at Stanford Graduate School of Business in 1980 when he first encountered Apple Computer’s Steve Jobs. Murray was inspired by Jobs, and after a summer internship with Apple and a short stint at Hewlett Packard, Murray joined Apple. Jobs named Murray the Macintosh division’s interim marketing director until “they could find someone good.” That never happened, and Murray was tasked with usurping competitor IBM’s emerging hold on the burgeoning personal computer market and claiming it for the Macintosh.
The year was 1984 and the place was a 60-second Super Bowl XVIII TV commercial slot. In what could have been a complete marketing disaster, Murray was placed at the helm of a $750,000 television ad the Apple board of directors hated so much they almost fired the ad agency responsible for it, but ultimately, begrudgingly permitted it to air. Directed by Ridley Scott of Aliens fame, the minute-long cinematic feature stars an English discus thrower as the radiant champion of free thinking in a shadowy Orwellian dystopia. In his 1983 Apple sales kickoff session, Steve Jobs prefaced a preview of the commercial with the following:
“It is now 1984. It appears IBM wants it all. Apple is perceived to be the only hope to offer IBM a run for its money. Dealers initially welcoming IBM with open arms now fear an IBM-dominated and controlled future. They are increasingly turning back to Apple as the only force that can ensure their future freedom. IBM wants it all and is aiming its guns at its last obstacle to industry control: Apple. Will Big Blue dominate the entire computer industry? The entire information age? Was George Orwell right about 1984?”
![Apple’s 1984 Macintosh television advertisement.]
The commercial was a hit both internally and externally, rallying Apple’s sales team and earning critical acclaim. But it was only the beginning. If Apple was promising to free users of the shackles of IBM, what was the tool of their liberation? The “sledgehammer” in question was the Macintosh 128k. Murray now needed to convince third-party developers that the computer’s $2,495 price tag (about 6,508 USD today) was worth it and inspire them to write applications for users. That’s when Murry enlisted the aid of Mike Boich who hired Guy Kawasaki, and Boich and Kawasaki became known as “developer evangelists.”
The rest, as they say, is history. The success of Boich and Kawasaki is evident in Apple’s present domination of both the developer and consumer markets.
Developer evangelism, which falls under the broader scope of developer relations, has since evolved into a professional area of expertise concerned with “building and nurturing a community of mutually beneficial relationships between organizations and developers (e.g., software developers) as the primary users, and often influencers on purchases, of a product.” Notable modern developer relations programs are implemented at Twilio and Stripe, and since 2015 developer relations professionals have been coming together at DevRelCon once a year in different parts of the world.
While almost every developer has interacted with developer relations at some point in new product onboarding, we still struggle to define exactly what it is.
Your Yoda in a backpack
You learn a lot about telling stories in film school because every decision you make is based on whether it helps convey the narrative. From the direction of the light to a specific sound effect to whether or not a shot makes it into the final cut, the story is the thread that pulls it all together. One of the easiest stories to tell is the hero’s journey.
Existing since stories were first told but popularized by American writer Joseph Campbell, the hero’s journey is exemplified in George Lucas’ Star Wars. In the original trilogy, Luke Skywalker transitions from a naive farm boy to a wise Jedi knight with the help of mentors, allies, and enemies who summon him to adventure, lure him to the underworld, and eventually return him to the community as a hero.
This story is powerful because it resonates with our individual human struggles. When I was diagnosed with cancer in my early thirties, I embarked on a hero’s journey. But a hero’s journey isn’t always as serious as cancer. Sometimes your hero’s journey is debugging a particularly nasty and esoteric failure in your code, confronting your imposter syndrome, reaching out for help, persevering, and overcoming the challenge with a solution you can share with other developers on Stack Overflow.
So if the developer is the hero, developer relations is Yoda in their backpack.
The hero’s journey of the developer
Our hero, the developer, receives the call to adventure when hearing a talk at a conference. At this point in their journey, the developer is interacting with the developer advocate. In other words, the developer advocate is R2-D2, and the talk is Princess Leia’s plea for help. And like Luke Skywalker, the developer might initially refuse the call to adventure, citing the limitations of their current circumstances … until their circumstances change — a software incident, a new privacy regulation, or a customer feature request — and the developer is forced to heed the call. That’s when the developer advocate is Obi-Wan Kenobi accompanying the developer to the Mos Eisley spaceport, where together they purchase passage to Alderaan aboard the “ship that made the Kessel run in less than 12 parsecs.” They clone the repo, they create the trial account, they request the demo, they sell the landspeeder because they’re never coming back to the moisture farms of Tatooine
But even the most celebrated ship in the galaxy — the Millennium Falcon — is susceptible to failure to deliver and missing the jump to hyperspace at the most critical moments. So the developer is forced to confront the shadows of doubt, wondering, “Is the documentation too difficult to understand or am I too stupid to understand it?” This is where developer experience and developer education appear, and like the wizened Jedi master, Yoda, they lift the proverbial X-Wing out of the swamp, rescuing the developer from despair and preventing the sprint from careening off schedule.
With the support of developer education and developer community, the developer masters the product. In the best cases, they become a champion of the product, contributing to the community and offering feedback for the developer advocate to take back to product. The hero’s journey is complete: the apprentice is now a Jedi. They may go forth into the galaxy and help uphold the light side of the Force.
Measuring Developer Relations
We wouldn’t be talking about Star Wars today if it had failed to turn a profit at the box office. The franchise is not only an engaging story with relatable characters and cool special effects; it’s also a commercial success that spawned action figures, LEGO sets, TV shows, computer games, prequels, sequels, and even a parallel universe that we just sort of pretend doesn’t exist. (And I’ll always be somewhat disappointed that I will never get a film representation of Admiral Thrawn!)
As much as I wish I could work in developer relations solely for the pleasure of helping others and building genuine trust between developers and products, the recent tech layoffs have illustrated that if your role can’t demonstrate financial value, you better start drafting your LinkedIn layoff announcement. Since the definition of developer relations remains elusive, the function is even more vulnerable to cuts. So what are some metrics we can apply?
The 2022 State of Developer Relations report offers important insights into how developer relations programs are measuring success. (It’s worth noting that 14% of respondents reported implementing no metrics at all — guilty as charged!) Metrics for developer relations can be broken down into four categories: awareness, activation, engagement, and retention. These categories are further refined into distinct components. For example, engagement can be measured in terms of the number of active users, the number of API calls, and community participation.
I recommend checking out the report to learn more, but there is a particular metric that feels validating to see because I have been advocating for its use since I began my developer relations journey in 2020.
Cuteness aggression and Net Promoter Score
After film school and before transitioning to tech, I worked as a social media manager and content creator for online magazines Dogster and Catster. Prior to moving to San Francisco, I also ghostwrote for a celebrity gossip blog. I know a thing or two about viral content. If you consumed celebrity gossip in the early 2000s, you have definitely seen my work. At that time, the only goal was to increase page views and clicks on paid ads, just maybe leading to a sale.
It didn’t take long for me to discover that the readers of dog and cat magazines are not easily persuaded to click on ads. The readers of Dogster and Catster were quick to recognize insincerity or manipulation and would call out obvious promotional posts. In that way, they were a lot like developers — they didn’t take kindly to bullshit. I learned I had to be authentic if I wanted to appeal to them. I was naturally good at this because I am compulsively honest (not always my favorite trait) and shine brightest when I can be myself and speak from my heart.
I am an unabashed lover of all things cute and suffer from a documented condition known as “cuteness aggression” which causes an almost violent reaction to unbearable cuteness. If you’ve ever wanted to chomp a chubby baby leg, then you know what I mean. I also have a soft spot for the underdog, you know — the runt who turns out to be the diamond in the rough.
I noticed that amongst the Dogster and Catster communities were individuals who, despite all the ugliness in the world, could still find the love and compassion to care for animals who might otherwise be forgotten or, worse, euthanized. I was moved by their kindness and in a position to give them a platform, so I started a weekly column called “The Monday Miracle.”
It was an overly sentimental alliteration, but it was honest. I meant it. I would search Reddit and Facebook for people rescuing cats and dogs who had suffered disfiguring injuries or were born with disabilities, and I would feature their work in the magazines with appropriate permissions and credit. It was a mutually beneficial arrangement. They got exposure and shared the stories with their networks. So I got the page views, and when the strategy produced viral hits for the magazine, the boss was happy. Everyone got a feel-good story and cute photos.
“The Monday Miracle” taught me a lesson that guides me to this day: The best marketing is organic community evangelism.
When operating in a developer relations space, my goal is to create champions and evangelists. Developers are a sophisticated audience who don’t have time for products that don’t deliver value or have poor documentation or nonexistent support. Even if the solution I am advocating is not a fit for the developer, they might know someone who does need it. Therefore, my goal is to make such a positive impact that they think of me when passing on a recommendation.
Net Promoter Score (NPS) can be used throughout the hero’s journey of the developer to evaluate whether or not a developer relations strategy is working. The question at the heart of developer relations is always: Would you recommend this solution, product, blog post, webinar, demo, conference talk, or tutorial to a friend or colleague? If the NPS is positive, then something is going right. You are creating brand champions and product evangelists whose recommendations are the best marketing you could ask for.
And just like “The Monday Miracle”, strategies for developer relations need to be devised and executed with authenticity, integrity, and genuine care for the community. The best marketing comes from being honest and transparent. Deception and superficiality lead to the dark side.
This brings me back to the question that haunts DevRel: What even is it? Maybe we’re not looking at the question the right way. Maybe we’re overthinking it. Maybe it’s not such an ambiguous, abstract concept. Maybe developer relations is just about realizing the hero in all of us.
Top comments (2)
This is such an interesting take on developer relations! Do you think the Hero’s Journey framework applies equally well to all roles within tech, or is it particularly suited to DevRel?
This is an excellent question. Thank you for asking it.
An aspect of the hero's journey that makes it so enduring and so relatable is that it can be applied to almost anything. For example, you can apply it to the professional development of an engineer from new grad to seasoned tech lead (they are the hero on the journey). In that case, it might be useful for engineering managers to adopt a hero's journey framework to help them better coach their team (as the mentor to the hero).
I think the framework is particularly well suited for Developer Relations. This is because the application of the framework is a lot more explicit: The developer is the hero, DevRel is the mentor, and the ultimate goal is to help developers become Jedi Knights aka product champions/evangelists.