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. 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:
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.
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.
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!
Top comments (4)
I had never heard about DevRel until now so I read a definition online. This job is interesting but it looks like a way to prevent any unionization (which I think is really important). Am I completely missing the job ? If not, what do you think / how do you feel about unions ?
That's very interesting... I've never considered unionization's relationship to DevRel before. Unionization/collective bargaining tends to be a reaction to a workforce that feels exploited and feels the need for safety in numbers, but I don't think we're postulating that software engineers are exploited.
Mostly I see DevRel as being the people who help Marketers reach developers. When I was in a dev team, sales & marketing people had a really negative connotation because every interaction felt like "they're just trying to make a sale" - DevRel is about changing that interaction to promote more sharing and teamwork. As a Developer Advocate, I'm interested in the technology as much as you are. I think I have a cool solution to share, but the tech comes first and I'm more interested in the relationship than the sale, if that makes any sense.
As for your other question, I'm on the fence about unions. I think they solve some problems, and I think they create other problems. Most complex systems exhibit that trait. I guess I'd sum it up as "they're not a cure-all". Anyone who says "everyone should be in a union" is just as mistaken as anyone who says "all unions are bad". Personally I think an honest open relationship between employer and employee, with significant psychological safety and inclusiveness from both sides, would be a better solution - once you have to get lawyers and contracts involved, the relationship is already strained and isn't healthy to start with. I take my inspiration there from the Agile Manifesto - "customer collaboration over contract negotiation".
💜💜💜
I really appreciate you, Matt! You and a couple others there at DevOpsDay Nashville really helped me understand the role that I wanted - I had tried to do things like it but didn't know it had a name until I met y'all. Since then I've realigned my career and it's been life-changing.