I don’t have a technical background, so I’m looking to apply for a project manager, product owner, or developer advocate type of role.
I offer pro bono career coaching outside of work hours, so I interact with a lot of jobseekers on a regular basis. Over the last few months, I’ve been observing a troubling trend. Folks who are trying to transition into tech from a non-technical background have mentioned something like the above. I had a mixed reaction to hearing this. On one end, I was super happy that more people know about developer advocacy and are interested in a career in it. However, on a more troubling end, I thought to myself, "Are these folks seriously thinking of developer advocacy as an easy way in?" Folks who are new to this industry might not know much about developer advocacy. It’ll be scary, however, if the tech leadership also sees developer advocates as fluff.
In this blog, I will share my thoughts and provide reasoning to make three claims:
- Developer advocacy is a technical role.
- Developer advocacy is NOT an entry-level role.
- Your developer advocates are worth every penny you invest in them.
In the foreword of Mary's book, Jono Bacon wrote:
Developer Relations ... is a remarkably nuanced, complex, and context-specific discipline.
I know I'm making three absolute claims without the comfort of an "it depends" answer. That is because I'll set the context and boundary for each of my claims. Grab your favorite beverage, relax, and read on. This one doesn't come with a TL;DR.
Who is a developer advocate?
Since some of my readers might not know about developer advocacy, this section introduces the terminology. Feel free to skip this section if you're familiar with the role.
There are many right ways and only one wrong way to understand the different components of Developer Relations (DevRel). The only way to go wrong is to become obsessed with how different companies structure and view their DevRel teams. For example, Developer Relations - The Book breaks down DevRel into four functional areas: developer marketing, developer experience, developer education, and developer success. On the other hand, developer experience is a superset of developer relations, according to Lee Robinson at Vercel or Milen Dyankov at AxonIQ. Developer relations can report to the engineering organization, such as Google, the product or marketing organization, such as AWS, or remain separate, such as Microsoft. All this to say that the definition and structure of developer relations can vary a lot.
However, in my opinion, the role and work of a developer advocate can be universally defined regardless of the company or the position in an org chart. A developer advocate is an experienced engineer who acts as a trusted voice between the company and the community/customer. They write clean code, produce reusable and developer-friendly content, and possess a tremendous level of empathy for the community. They can work as part of a developer relations team or as the solo developer advocate for their company. There are three important pieces in my definition of a developer advocate:
- Engineer (builder)
- Trusted voice and experience
- (Interface) between the company and the community/customer
In the following three sections, I will discuss the reasoning behind my definition.
Developer advocates MUST be technical
In Canada, the term "engineer" is protected and reserved only for those licensed by a provincial or territorial engineering regulator. Let's use the term "builder" instead. A builder is someone who has experience building software systems.
Developer advocates are storytellers. Oftentimes, these stories are about their own experiences solving critical technical challenges. Even when they're building a demo application, their previous experience as builders helps them architect the application to follow the best practices. Most talks follow a question/answer period where the audience asks the developer advocate questions about the technology they talked about. Even if someone (without the technical foundation) manages to rehearse and deliver a technical talk, answering the audience's deep technical questions will be extremely difficult.
If you think that not all developer advocates need to be technical and that some folks might be more on the community side, you might be mixing community managers with developer advocates. Community managers are also part of a developer relations team, and their work overlaps some of the work of developer advocates in the community. If you see a developer advocate doing only community work and no code or technical content, they may be using the incorrect title for whatever reason. On LinkedIn, I saw a sales representative with the title "Sales Rep / Developer Advocate."
What do I mean by "code or technical contents"? In the current time and market, almost everyone at a tech company can talk technical. Even basic knowledge of git and GitHub are considered general skills. You must return to your audience—the developers—to find the bar of code and technical content. Developers have an uncanny ability to smell sales and marketing tactics. However, they constantly seek technical knowledge from blogs and (reluctantly) skim through developer documentation. Your developer audience is the litmus test for the code and contents your developer advocate creates. Your developer advocate should somehow make developers' lives easier through advocacy and content creation.
Why am I trying to be a gatekeeper, though? I don't think anyone can/should be a gatekeeper in tech, but my opinions in this blog are coming from a genuine concern that some folks might be devaluing the developer advocacy role. When I was interviewing for my first job change after 8 years in 2020, I was fortunate to receive a flood of emails for DevRel roles. Unfortunately, a good percentage of these roles were for blockchain/crypto/NFT companies. What's unfortunate about it?
I respect all technologies and legal companies. Here is the unfortunate bit ➡️ Almost every single recruiter from these companies assured me that I didn't need to know ANYTHING about blockchain or the underlying technology to join their companies. This is after I mentioned that I don't have a clue about blockchain. What was important for these companies then? A large social media following and the ability to create endless marketing contents. I don't follow that industry, but I can make a guess that without the technical foundation, most of the blockchain/crypto/NFT DevRel hires were unsuccessful at building the trust of their communities.
Do you have a favorite developer advocate? I follow and respect a number of developer advocates in the industry. Let's take a look at their background and try to deduce if a technical background is needed or not to become a successful developer advocate.
| Name | Roles before DevRel |
|---|---|
| Kelsey Hightower | Software Engineer, IT Consultant, SysAdmin |
| Angie Jones | Java Champion, Software Engineer, Inventor {26 patents} |
| Matty Stratton | Lead Engineer, Infrastructure Architect, Technical Consultant |
| Lorna Jane | PHP Consultant, Principal Developer, Senior Web Developer |
| Sai Vennam | Software Engineer, Web Developer |
I hope I was able to explain why developer advocacy is and will remain a highly technical role.
Developer advocacy - NOT an entry-level role
Before I transitioned into tech, I worked as an electrical engineer building renewable energy systems. I also spent 10 years at engineering schools in two countries, where my brain was hammered to learn new things by reading documentation (a.k.a. books), and then I built systems (a.k.a. lighting up an LED) using that knowledge. Even with all that technical experience, it would be impossible for me to start my tech career as a developer advocate. I knew a lot about circuits, diodes, and huge transformers but nothing about SQL or git, let alone cloud and Kubernetes. I started as an intern at IBM, worked my way up as a Java developer, and then transitioned to technical consulting. After 4 years of experience as a developer and consultant, I was able to start my developer advocacy career.
Your path can be very different. You can be a CS grad or a college dropout, a physics PhD or a musician - but you need the experience of building software systems before trying to teach others how to do so. Whether it's for two years or twenty, legacy enterprise development or freelance open-source contributions, a developer advocate must have done the thing that they are hoping to teach others. Without the technical experience, how can you teach a bunch of techies? Angie Jones writes:
Developer advocates have to build and maintain credibility with their engineering peers, understand their pain points, and foresee how given solutions would address their needs. Without engineering experience, this is hard to do. Not impossible, but definitely hard.
Does DevRel look glamorous from the outside? The travel, staying at nice hotels, and "influence" on social media might send all the wrong signals to someone looking to break into tech. Maybe we should talk more about the invisible hard stuff on the job. When I'm in my hotel room, I'm practicing in front of a mirror for my talk the next morning and not sipping on a pina colada by the pool. I've spent countless nights at airports and on economy flights without much sleep. I've had layovers at airports without a proper restaurant and survived on granola bars and Coke Zero. On economy flights, wearing N95 masks can be anything but glamorous.
Based on the 2022 State of Developer Relations report, Taylor wrote on Twitter about her hypothesis on why companies with new DevRel programs are hiring inexperienced folks. She mentioned that this is dangerous to the person they are hiring (more likely to leave the field), dangerous to the industry, and just dangerous to the company's success. On her blog, Taylor wrote about the challenges of DevRel. Although aimed at solo DevRels, developer advocates in general, are likely to burn out due to unclear prioritization and a lack of support/understanding from the larger teams (marketing, engineering, product, etc.). This likelihood of burnout increases by a few magnitudes if this DevRel person is an intern or have very little experience.
There can be a handful of exceptions, like Twilio back in the day or GitHub in the present, where they had/have programs to hire, support, and grow junior DevRel talents. But this is an exception, not an excuse, for companies to hire cheap DevRel talent and then set them up for failure. How is this dangerous for the company and the industry? This question creates a nice segue to my final claim. More on that in the next section.
Cost of DevRel depends on how you value them
2022 was a troubling year for tech. However, with all the mass layoffs, don't associate the troubling trend of DevRel layoffs only with mass layoffs. DevRel layoffs happened this year, the year before, and the year before. In my observations, there are three main reasons behind DevRel layoffs:
- Company-wide mass layoffs
- The company never needed DevRel
- The leadership didn't understand DevRel
When the company needs to tighten the belt, only the folks directly contributing to the revenue make the cut, and their colleagues find a place on the chopping board. I will be out of my mind to say that a company should let go of a developer or a sales rep over a developer advocate. Mass layoffs are unsightly and brutal, and they frequently result from Silicon Valley's rush to become the next unicorn. But that is sometimes the unfortunate reality and cannot be avoided.
DevRel - for every developer, not for every company
Why do you think you need a developer relations team? Did you get Series A funding, and one of the investors suggested you get one of those developer advocate things? The question to ask is pretty simple. Does your company have a product or (open-source) project whose users are developers? For example, Gmail is used by the general population, but Google Cloud is used by developers.
Once you're convinced that you need a developer advocate, or a DevRel team, it's paramount to hire the first DevRel at the right time. Adam FitzGerald, Vice President of Developer Relations at HashiCorp, mentioned to GGV that the right time to formally create a developer relations program is when your company has about 25-50 people. Adam added that by the time your company has 100 employees, you almost certainly should have a head of developer relations, if you don’t already. While this is not exact science, this formula has worked well for many companies, including HashiCorp, which is considered the poster child for building successful open-source and developer relations programs.
In the majority of failed DevRel cases, the company leadership failed to understand the value of DevRel. When the pandemic hit in early 2020, I was working as a developer advocate at IBM. With all of the in-person conferences and meetups being cancelled, IBM leadership might have thought, "No events == No need for DevRel". Many of our DevRel peers were let go, and the remaining were forced to move into some sort of client engineering roles. At the time of writing this blog, Grace Jansen and JJ Asghar might be the last two DevRel standing at IBM. That, too, is probably because of how insanely awesome they are at their advocacy work. I can write a book on my lessons from the IBM DevRel days, but let's set that aside for now.
Majority of companies layer DevRel on top of marketing as a sort of afterthought, and that’s usually a recipe for failure. All four co-founders at Aiven (the company where I work at) have been long-time open-source maintainers/contributors and highly value the work of DevRel. Similar examples can be seen at HashiCorp, where co-founder Armon Dadgar has been doing DevRel on the whiteboard since the early days of the company. Technical founders know the value of DevRel and know when to form a DevRel team. This is very different from bringing your first DevRel hire onboard and making them convince the leadership why the company needs DevRel in the first place. If your developer advocate needs to explain to the technical leadership the need for DevRel, that's a red flag for that individual and the company.
If you're trying to transition into DevRel without technical experience, kudos to you for making this decision. But please don't think of DevRel as a shortcut into a career in tech. Gain some experience building software systems, try to walk in the shoes of developers, and understand the pain points. There will be a time when you feel confident enough to make the move. Till then, work on your public speaking and writing skills.
If you're hiring for DevRel talent, you're paying a premium salary equivalent to the same level on the engineering ladder. You are completely justified in questioning this cost. What value is DevRel bringing? 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. Read the last line again and again until you realize why DevRel and developer advocates are worth every penny you invest in them.
Top comments (0)