The Adventures of Blink #2: What is it you DO here?
Tags: devrel
Published: 2022-06-05 17:22:27

{% embed https://twitter.com/mbritton/status/1533158136034611200 %}

I saw this roll by on my Twitter feed.  It caused quite the kerfuffle!  I can't say I'm surprised by what I saw - _everything in the universe_ has haters; you can't have diversity of thought without disagreement.

## Where the Tweet Went Wrong

The tweet above has committed something akin to the [reduction fallacy](https://en.wikipedia.org/wiki/Fallacy_of_the_single_cause).  Any career path is complex and focusing on one facet (in this case, the DevRel-Marketing connection) is a mistake.  It's like when people say that Support Operations teams are just "digital janitors", or when Software Engineers are referred to as "code monkeys". 

## Let's Dig a Little Deeper

Despite the insensitivity of the delivery, there's a question that underlies the tweet that *does* deserve to be answered.  When I'm in social situations and my recent job change comes up, I often feel like I'm here:

![Office Space Meme - What would you say you do here?](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9nzb2bhqehjl77y8q9m5.jpeg)

What exactly is a developer advocate?  What are you advocating for, and about?  How does what you do affect products your company sells, the world around you, etc?  These are all very good questions, and interesting to family and friends who aren't part of our field but because they care about us, are trying very hard to understand what "all of that technical mumbo-jumbo" means. Interestingly enough, the owner of the tweet above identifies as a software engineer, which seems to show that we aren't always clearly defined even _within_ tech.  So let's take a stab at explaining some of the facets of DevRel!

## Yes, we're marketers.

DevRel exists as a response to the often-siloed nature of IT.  When you have a small IT shop, there are just a few people and everyone's kind of a generalist.  Then your business grows, and with it, your tech team enlarges and begins to fracture a bit; you might hire people who have specialties that your team needs extra focus on.

The problem is one of communication complexity - when the entire IT department is 4 people, It's easy for everyone to stay in sync.  They've each got 3 people to talk to, for a total of 6 communication paths.  But if you double to 8 people on the team, now they each have 7 others to interact with, for a total of 28 communications paths.  It's easy to see how this will get overwhelming as the size of your department increases.

![Communication paths between teams of 4 and 8 people](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/46jb6m8r80imq3di5qhn.png)

The natural course of this is that the organization develops a hierarchy - now Bob is in charge of Developer teams, and Susan leads infrastructure platforms, and Lupita is responsible for sales engineers.  It makes sense to minimize the interactions so that people can focus on getting things done.

### But Silos Don't Work.

The siloed structure creates a problem, however; while we've narrowed the communication flow to give people focus space, we're losing data.  Nuance, subtlety... these things go by the wayside because the information has to be transferred through people to get from source to destination.

### Marketing Without DevRel

Imagine being a marketing team for a product that needs to be sold to engineers.  Except you're in a silo, and all of the people you communicate with are other marketers.

You develop your own "marketing shorthand" communications.  You know how to interact with each other because of your common ground.  You have a product that you think will improve engineering organizations.  Everything's good, you start putting out top-notch marketing communication about your product and high-fiving each other.

#### But your engineering customers aren't buying it.

Why? Because your target audience doesn't speak marketing shorthand.  They live in an engineering silo where they interact very differently from you.  The things you think are slam-dunk ways to communicate your product's value?  They scoff at or completely miss.  The message can't land because the source and destination don't have a way to translate for each other.

#### And that's where DevRel helps.

DevRel, Developer Advocates, are communicators. They help marketers communicate _effectively_ with the engineering audience.  Believe it or not, marketing isn't just about selling more things.  Oh sure, it's important because it keeps us in business, but people are still human and they genuinely care about making life better for their customers.  Keeping customers happy and profitable is a great way to keep me profitable after all, so it's a mutually beneficial arrangement.

## But we are also Builders!

Without fail, everyone in DevRel that I've ever met came from a "more technical" background.  We're technologists.  That doesn't _always_ mean we're hardcore programmers, but it quite often does - and the role requires us to be conversant in what hardcore programmers do.  After all, we're supposed to provide a means of effective communication with them, and if these two gents taught us anything, it's that real communication requires a shared experience.

![Picard and Dathon, at El-Adrel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9e2267bx500lnsx5sjjv.jpeg)

Now, you can't expect DevRel to always be your elite Software Engineering super-genius... because that's not what makes us tick. To offer an analogy - why does Tom Brady need a quarterback coach? Obviously the coach can't do it better than he can, but an external observer provides support and perspective. In DevRel, what gets us excited is _enabling those Software Engineering super-geniuses to succeed_.  **We in DevRel _literally exist_ to support Developers**.  Makes the tweet at the top of the article hurt a little more, doesn't it?  

## We Also Bring Humanity to Technology

This is a facet of DevRel that often gets overlooked, but it's something that **many** of us are extremely passionate about.  @mattstratton (mentioned in the above tweet) was actually one of the first Developer Advocates that I ever encountered in my career.  It was at a DevOpsDays conference where he spoke about psychological trauma response and how it related to incident management.  

_That conference is what I attribute as the awakening of my desire to get involved in DevRel._

Not exactly a lot of code in that talk, is there? But that's the thing... engineers aren't just about technology, they're people too.  And in DevRel, we care about the people who do technology work.  Why?  Because they're often forgotten by corporations who are grinding away at their people, trying to be more profitable.  And _we see that_.  We want to help it.  And our skill as communicators can be employed to bring those kinds of issues to light, in a manner that leadership of corporations can see and understand.

## Summary: Don't fall in the trap

Silos make it easy to start thinking about "us" versus "them".   And thinking about "us" versus "them" makes it easy to start trying to establish a pecking order.  It's just what we humans do in groups.

I'd like to encourage you to take a different approach consciously and intentionally.  Instead of going for the social numbers by dunking on another group, try promoting them.  Build them up, celebrate their wins in front of leadership, encourage them and help pick them up and dust off if they take an L.  

In doing so, you'll become a bit of a DevRel yourself.  Be excellent to one another, my friends!