Identity Crisis - A Tale of DevRel

Do you identify yourself as a developer advocate?

Are you confident that your skills are being fully utilized in your current role?

OR,

Do you ever feel like your work requires more skills than what you currently possess?

Developer relations (DevRel, in short), both as a field and for those working within it, is currently facing a significant identity crisis. There is little to no standardization across various aspects of the role, from the type of work being done, to the required competencies, and even to the ideal career ladder. This blog presents a somber view of the identity crisis currently plaguing DevRel. I conclude the blog with one action item YOU can take before irreparable damage is done to the very essence of our field's identity.

Forming the identity

December 9, 1968.

Douglas Engelbart took to the stage to perform what would become known as the "Mother of All Demos". Little did the audience know that they were about to witness a demonstration that would forever change the course of computing history.

Engelbart's presentation was not just a showcase of his technological innovations, but it was also an invitation for developers to collaborate with him in advancing the field of human-computer interaction. Many credit Engelbart to first plant the seed of technology evangelist. However, Guy Kawasaki is more widely known to pioneer the role of technology evangelist as the first successful one, promoting the Apple Macintosh in the 1980s through his passionate speeches, demonstrations, and events.

Around 2012-13, companies like EngineYard, Twilio, SendGrid, and New Relic took DevRel to mainstream by investing heavily in their DevRel programs and reaching their developers from a community-first approach. Rather than traditional marketing materials, these companies had engineers presenting technical talks at meetups and conferences.

Battling for an identity

Long before I had the title of developer advocate, I was delivering talks, hosting meetups, and writing technical blogs on my own time. I was doing this out of joy and could never imagine that I could do this full-time (and get paid to do so).

As a full-time software engineer doing "DevRel thing" on the side, I didn't have an identity crisis. I was just another software engineer who was active in writing and public speaking. When I started to do DevRel full-time, I asked myself "how valuable and visible is my work?". Check out what Rachel has to say about the value of tech writing:

This can be very much relatable to the perceived value of DevRel.

It's a golden thread for anyone in DevRel. Please bookmark!

When I started my first official DevRel role at IBM, the answer to "what do you do at IBM?" never ended in one line as developer advocacy was new to most folks. I was tired to explain my role every time so I wrote a blog to explain. If you think that something clever like "I help developers to succeed" or "I educate developers on $someTechnology" would work, please try it out on someone who never heard of developer relations and then ask them back if they understood what you do from that clever one-liner.

How did we arrive at this point?

Surprisingly enough... it's because DevRel became highly successful!

Seeing the massive success of DevRel programs at companies like Twilio and HashiCorp, other companies wanted to replicate.

However, simply copying their models does not guarantee success. In fact, many tech companies that attempted to do so ended up failing in their DevRel programs. Without an insider knowledge, here's my calculated guess on the "why":

1. Lack of genuine commitment: DevRel programs require a genuine commitment to developers and their needs. This means investing in resources like documentation, support channels, and events, as well as taking the time to engage with the developer community. Many companies see DevRel as an afterthought or a checkbox item, rather than a core part of their business strategy.

2. Poor understanding of the developer mindset: Developers have a unique mindset and approach to problem-solving. They value tools that are easy to use, well-documented, and flexible. Companies that fail to understand this mindset may develop tools and resources that are too complex or too restrictive, which can turn developers off. Even the best DevRel team won't be able to shine a poor product.

3. Lack of trust: Developers are a discerning audience, and they can quickly sniff out inauthenticity. Companies that lack trust with the developer community, perhaps because of a history of closed-source practices or a lack of transparency, may struggle to build meaningful relationships with developers. Imagine that you (a developer advocate) went above and beyond on a developer event. You delivered a talk, spent hours on booth duties, and talked to a bunch of developers about the technology behind your product. You write a 9 page trip report with all the details and the CEO comes to you right after the event asking for an ROI. It's extremely easy to lose the trust of the community as well as the trust of your own DevRel team.

4. Insufficient resources: Building a strong DevRel program requires a significant investment of time, money, and people. Companies that try to cut corners or skimp on resources may find that their DevRel efforts fall short. Sure, you can hire 3 junior folks to form a DevRel team but without senior people in the team to groom them, they'll burn out fast with trying to do 10 things at a time and battling for an identity.

5. Poor execution: Even with the best intentions and resources, DevRel programs can fail if they are poorly executed. This might include a lack of follow-through on promises, inconsistent messaging, or an inability to respond to developer feedback in a timely manner.

Engineering? Marketing? Product? Office of CTO?

Oh no! Not "where should DevRel sit" question again 🤬

An engineer typically works under the Engineering org, while an SDR works in Sales, and a marketing analyst works in Marketing.

But where does a developer advocate fit in? Many of them are engineers by trade, work closely with the product team, (oftentimes) report to the marketing department, and can be great allies for sales reps without directly selling the product.

Karin recently asked this same question which received 31 responses on Twitter. In these responses, people had eight different opinions on where DevRel should sit - from some flavors of "it depends" to "DevRel as a separate org" to "sales". Out of all 31 responses, I share the same view as Jim Bennett:

It’s such a cross functional org that there is no real right answer. Done well it’s such a strong collaboration across all the orgs that it should have access to marketing budget as well as product teams.

Just not sales - it should never be tied to revenue.

Had I responded to that thread, here would be my corollary to Jim's response: Developer relations (DevRel), when done right, acts as a metaphorical glue among cross-functional teams, similar to the Japanese art of Kintsugi. DevRel, like the gold in Kintsugi, repairs fractured relationships or creates non-existing relationships between an organization and its target developer audience. It creates an environment based on authenticity and trust, without a direct purpose of "sell no matter what".

But is DevRel really a golden solution for everyone?

Does every organization have the capacity to use the power of DevRel?

The real cost of identity crisis

Here's a CEO asking if developer advocacy is a good idea or not.

Here's a programmer with ~40K Twitter followers who does not trust developer advocates because this person feels that developer advocates are just pitch people for their employers instead of people really helping developers.

Here's a company pitting DevRel teams against each other without even taking their consent. They have since taken down the post due to backlash.

At the core of this confusion, there are two questions:

1. What is DevRel?
2. Why are we paying them?

If we (DevRel community) cannot have a unified answer to the first question, more and more people will question the effectiveness of DevRel. I don't know about you but I've seen more than enough "And the entire DevRel team was let go" posts in the last few months. In weak economy, you need a strong justification to the second question to save your job.

Have we forgotten how to be engineers?

I live in Canada so I'm aware that the term "engineer" has a special meaning at some places that is regulated by local engineering associations. However, my use of the term "engineer" refers to anyone who has professionaly built software and hence, (software) engineer. This includes a wide variety of roles such as developers, SysAdmins, DBAs, Solution Architects, etc. It has nothing to do with your path to becoming a software engineer. Whether you're a ComSci PhD or a bootcamp grad, you possess certain skillset that is common to expect from a majority of other software engineers. You know how to use version control, read a piece of code, write and debug code, and so on.

In the last 10 years, the identity of DevRel has become more convoluted. When I started at IBM in 2014, there were very few developer advocates in the industry (compared to now). A developer advocate would be someone with decades (not years) of engineering experience who chose not to go the management or principal engineer route. They wanted to teach and share their experience.

One of the common complaints DevRel folks have is that we don't get a seat at the table in terms of product development and roadmap. Your peers at product or engineering will likely respect product feedback coming from an engineer than from someone who has very little to do with coding in their day to day job.

Does it mean a developer advocate need to regularly write code that runs in production? No! Zero coding and writing production code daily are two extremes. At bare minimum, you should be comfortable writing code samples and you should do that regularly as part of your job. "I know how to code and I'll do it when needed (interpreted as never)" is a dangerous mindset for a developer advocate.

You aren't gatekeeping... are you?

When I express my view on developer advocates needing to be highly technical, I usually get three types of questions/comments:

• What about developer advocates who are more community focused?

My response: A developer advocate is the default role that comes to mind when people think about DevRel. If you're a series-A startup and can only afford to have one person on your DevRel team, it's likely that you'll hire a developer advocate. This is why DevRel and developer advocate are often used interchangeably, even though one is a subset of the other.

Out of the 3Cs (code, content, community), what % of code and technical content are you producing as a developer advocate? If the answer is "zero" or "very little", you're confusing developer advocates with community managers. A community manager is a super important role. At smaller companies, a developer advocate might be doing community management on top of their advocacy work. But code and technical content come first for a developer advocate, with community work as a nice-to-have.

• Are you trying to gatekeep?

My response: Not really; I'm simply sharing my opinions on DevRel (on my personal blog). A question back at you: can you maintain quality of anything without setting some level of standards? From a software engineer to a sales rep, there is clear and unified job description and expectations for every single role in tech industry; except DevRel! Most of what I'm saying have been said many times in the past by well-respected DevRel leaders.

• But... I have empathy for developers. Isn't that enough?

My response: Having empathy is important but empathy alone will not help you become a strong develper advocate. How does one cultivate empathy in the first place? Tim Berglund, a respected figure in DevRel and one of the best developer advocates out there, points out that genuine empathy for developers is challenging to achieve if you have never been a developer yourself. It's almost impossible to truly understand their experiences and struggles without a background in engineering or coding.

Tim goes on to explain that developers worldwide, regardless of spoken language, share a common dialect and inside jokes that only fellow developers can comprehend. This shared language and understanding of the developer's world can only be acquired through years spent behind a keyboard, earning a livelihood by writing code. It is by going through similar challenges and experiences that one can truly develop the empathy necessary to connect with other developers.

DevRel is NOT influencer marketing

Once I had a recruiter reach out who was looking for a DevRel superstar with a certain Twitter follower count as part of the required skills on the job description. I was about to write this section and then heard Tim Berglund craft the same message perfectly. Listen to what Tim has to say about the influencer path vs. the traditional DevRel path (32:32min mark) ⤵️

You're a developer advocate... what's next?

Around 2013-14, some of my IBM colleagues retired as a developer advocate. This is after they became a developer advocate after working as a senior engineer for 20+ years. I wrote before that developer advocay is not an entry-level role. In present days, some companies are hiring junior folks as a developer advocate (totally not to save on 💰) and then they are not providing them a DevRel career path to grow.

If you're a solo developer advocate, what does a promotion look like for you? If you're manager of a DevRel team, do you have a defined career ladder at your company? At what point in your DevRel career do you reach a plateau, where staying in a DevRel role no longer offers further growth opportunities?

Scanning the internet, I found four companies with publicly posted DevRel career path. Besides these four companies, I know a few more with defined career ladders for DevRel individual contributor (IC) but none for DevRel managers. From DevRel-ladders site:

Often one of the hardest challenges in Developer Relations is clarity. Clarity around goals, metrics, place within the organization, but most importantly clarity about your career path.

When your DevRel team doesn't have clarity, they'll face an identity crisis and that's the shortest path to burnout.

But... there is hope

If you've managed to read this far, thank you for your patience! There are three key things YOU can focus on in order to revive the lost identity of developer relations.

If you're a DevRel IC, focus on:

• Technical expertise
• Authenticity
• Optics

You, as a developer advocate, need to showcase the technical expertise which is the foundation of helping your developers succeed. You have to do that in an authentic way and not treat every community member as a new lead in the marketing funnel. Besides doing the work, you have to be intentional in conveying the value of your work within your company. This is where the optics comes in.

If you manage a DevRel team, focus on:

• Exec buy-in
• DevRel metrics
• Avoiding burn-outs

Your exec team must understand the value of developer relations before they hire the first developer advocate and they should be transparent in their support for DevRel. If you are in a difficult spot where you have to convince the leadership on DevRel ROI, understand what metrics are important for the exec team and find a direct/semi-direct relation with DevRel metrics. Most people working in DevRel are eager to help and often find it challenging to say "no". When this eagerness is coupled with a lack of clarity and clear expectations, it becomes the primary cause of DevRel burnout. It is crucial to prioritize the well-being of your team and foster a sense of psychological safety within the organization.

My hope from this blog is to inspire you, the reader, to revive the lost identity of developer relations and help developers succeed. Remember, DevRel is the only team at your company that can speak the engineer’s language, provide regular feedback to the product team, function as a marketing team, and grow the community as the face of your company.