DevRel for Beginners: What to Know and How to Get Started
Like many DevRel professionals, Ravi Lachhman began his tech career as a software engineer. He embraced an iterative, trial-and-error approach to development. He also found that he learned best by teaching others.
“On projects, I would always elect to write documentation and convert to Agile, happy to give presentations and sprint demos,” Lachhman told The New Stack.
That led to solutions architect and sales engineer positions, which eventually opened the door to his first evangelist role three years ago, a common job title in the DevRel field. Today, Lachhman manages a team of DevRels at Harness, a software-delivery platform company. (He’s hiring, by the way.)
“I am sure like many others, my path to DevRel was a windy one,” said Lachhman.
There’s no straight-line, well-lit path to a developer relations career. DevRel, in industry shorthand, is a burgeoning role — but its current practitioners most often grew into their position rather than actively pursuing it from the outset of their tech career.
The developer relations role has grown in popularity in recent years. Glassdoor currently pegs the average DevRel base pay in the U.S. at $90,416 annually, ZipRecruiter reports an average annual salary for U.S.-based DevRels of $107,273, with top earners (those in the 90th percentile) making $162,000.
Jorn Knuttila, solution architect and DevRel advocate at NeuVector, a container security company, also worked in a variety of IT roles in his 30-year career and said they’ve all contributed in some way to his current work. But like Lachhman, he credited his successful shift into DevRel to an earlier pivot he made to solutions and sales engineer jobs.
“Those roles put me in customer-facing positions where I needed to understand the technology but also relate it back to the struggles that people are facing — including how those struggles vary from department to department,” said Knuttila, who started his career pivot in 2000. “You are the smiley face of technology representing your company.”
Knuttila just distilled the role down to its essence: You are ultimately the (ideally smiling) face of your organization’s technology, responsible for listening to feedback, solving developer problems, and evangelizing solutions and best practices. There’s no such thing as a DevRel job that does not closely interact with the devs who actually use your products and help them do their jobs.
“In [my career] the one constant has been the need to talk to customers — which means developers,” said Steve Poole, developer advocate at Sonatype, a software supply chain technology company. Poole’s resume includes a 28-year stint as a software engineer — and later as a developer advocate — at IBM: “I’ve been doing ‘DevRel’ before it even had that name! It’s always been an integral part of my life.”
So if there’s no precise path into a DevRel career, how do you actually get started? We asked Lachhman, Knutilla, Poole and other experienced DevRel practitioners to share some words of wisdom for developers and other IT pros who are considering a career shift into this growing field.
So You Want to Be a DevRel: 4 Tips to Get Going
1. Become an advocate for devs in your current role.
Experienced DevRel pros seem to universally agree: The best way to get started in the field is to start taking on DevRel-like responsibilities in your current role.
“Start by being an advocate for developers and builders in your current role,” advised Kale Bogdanovs, senior manager of product-led growth at Workato, an automation platform. “Get involved with the people in your organization who work at the coalface.”
If you’re not already a sales engineer or in a similar customer-facing role, find the folks in your org who do fill that function and connect with them.
“Sales engineers are a great resource,” Bogdanovs said. “They’re the ones who need to make your product work under pressure, and they’ll be able to tell you what is good and bad about your development experience.”
2. Ask lots of questions — and never act like the smartest person in the room.
One of the best ways to achieve No. 1 is to ask questions, both internally and externally. You don’t need a particular job title to start doing that,
“Curiosity is the most important trait you can have as a developer, and it is no different in developer relations,” said Sal Kimmich, developer advocate at Sonatype. “Find out where the sticking points are in every process you are curious about, whether they are technical, process or personal dynamics. When you hit a major roadblock that you know is a problem for developers everywhere, that’s when you’ve hit gold.”
Identifying and then clearing those kinds of roadblocks is essentially what DevRel is all about.
“Find out where the sticking points are in every process you are curious about … When you hit a major roadblock that you know is a problem for developers everywhere, that’s when you’ve hit gold.”
—Sal Kimmich, developer advocate, Sonatype
This is especially important for folks coming from more of a heads-down development role, or one that doesn’t require a ton of regular collaboration outside of your immediate team. DevRel is as much a people-oriented position as it is a tech job. You can start doing this now by talking to the people who actually use your product, Bogdanovs noted, even if your job description doesn’t require doing so.
“In DevRel, you need to be the kind of person who is outgoing and willing to interact with all sorts of different people in all kinds of different situations,” Knutilla said. “You will be learning new things every day, and you’re going to encounter developers who are at different points in their career path and will bring myriad opinions and perspectives.”
A dose of humility doesn’t hurt, either, he added: “If you approach DevRel with an attitude that you’re smarter than everybody else — well, this is not going to be the role for you.”
3. Hone your writing and speaking skills.
If writing and speaking don’t come naturally to you, it’s time to build up those skills — they’re fundamental to DevRel. And even if you think they come naturally, it’s still good to get feedback and support. If solving developer problems is the first pillar of DevRel, communicating those solutions is the second pillar.
“At a high level, our role is to learn about and understand the problems developers are facing, and to develop and evangelize best practices for attacking those problems,” Bogdanovs said. “The venue changes, whether it’s conferences, forums, blog posts, docs, webinars, social media — but the core job is always the same.”
There’s an internal component to this, too: Lachhman started out by speaking and writing more publicly, but also by creating and contributing to more and more internal documentation, including on channels such as Confluence or another wiki or collaboration site.
On that note, DevRel requires meeting people where they are. That means documentation and other content that you create often needs to be translated for different media or formats.
“Just as we all have different learning styles, meeting developers’ preferences for understanding new information is important to DevRel,” Knutilla said. Documentation and other reference material “can work great for one person, while a step-by-step guide via video works better for others. There is a lot of content creation and editing that comes with the DevRel gig!”
4. Share your experience — even if it’s beginner-level.
DevRel is fundamentally about authentic conversations and communities, according to Poole. You don’t need to wait until you’ve mastered some particular tool or stack to begin sharing and building relationships.
“Even if you’ve only just learned to take baby steps with some new tech — share it. Someone will benefit,” Poole said. “Everything you know, all your technical experiences, whether you’re five minutes in or a deep expert — it’s all unique and it all could help someone else.”
Kimmich, Poole’s colleague at Sonatype, pointed out that this kind of genuine sharing is in itself an act of continuous learning, and a foundation for occupying a leadership position, if that’s part of your future ambitions.
“No one becomes an expert in a bubble, and building a community of genuinely passionate people who value the content you provide is the first step to becoming a leader in DevRel,” Kimmich said.
What DevRel Veterans Wish They’d Known Sooner
If you’re transitioning into DevRel from a different role, it’s also helpful to know what to expect once you arrive. It’s an evolving discipline. We asked veteran DevRel pros to share some of the lessons they learned after they’d taken the job. Here’s what to anticipate as you consider a career move.
There’s fuzziness around the term ‘DevRel’ and its value.
“One of the most important things in pursuing a DevRel role or career is actually to be ready to accept the fact that the job has very soft definitions around it,” Knutilla said. “You are going to need to make sure that not only are your tasks clearly defined to the outside world, but that your value is still apparent to the organization for which you work. The job description here and the value can be very nebulous.”
It’s an opportunity to craft and implement your own vision for the role and its worth to external and internal stakeholders. Knutilla added that if you don’t know your own value, that means the rest of the company probably doesn’t, either.
“If you approach DevRel with an attitude that you’re smarter than everybody else — well, this is not going to be the role for you.”
—Jorn Knutilla, solution architect and DevRel advocate, NeuVector
“There is a lot of gray on what value DevRel produces,” Lachhman acknowledged. He went through a “gray period” when he first transitioned to DevRel; now he manages a DevRel group and said the people who join the team from engineering roles commonly go through similar experiences.
“As an engineer or sales engineer, you have concrete results. You build a product that folks use or you sell solutions and retire your quota,” Lachhman said. “With DevRel, the results are much more abstract.”
Lachhman said there’s an industry-wide problem with “attribution” — it’s not always easy to connect the dots between the work you do and your company’s bottom line.
“Linking that someone attended your talk and then eventually became a customer in the conversion funnel is difficult,” he said. “You don’t interrogate your buyers [about] why they bought.”
Your personal brand matters.
Like it or not, DevRel is a field where your personal brand — which, of course, includes your online personas — is important. It’s a lot harder to connect with external developer communities if no one knows who you are.
Authenticity and integrity matter. If you want to be a trusted ambassador and source of expertise, then you have to earn and preserve that trust.
“As an engineer or sales engineer, you have concrete results. You build a product that folks use or you sell solutions and retire your quota. With DevRel, the results are much more abstract.”
—Ravi Lachhman, evangelist, Harness
“Whatever you say or do is part of your brand — and your brand will go with you as you move forward in a DevRel career,” Poole said. Don’t be tempted by shortcuts or shaky claims.
“Do not accept or promote messages that are false — find the value and tell that story,” Poole says. “If you don’t, your reputation will be tarnished and you’ll lose the trust of the very people you want to influence.”
DevRel is not just a job description. It’s a mindset.
Just as many people describe DevOps as a culture (rather than any particular job titles, development methodologies, or toolchains), DevRel can be viewed as a philosophy or mindset rather than a specific technical function.
“I wish I’d really understood [earlier] that DevRel is just as much of a mindset as it is a job, and you can start doing developer relations inside of any technical role,” Kimmich said. “It’s the simple process of learning to have a systems view of the technical ecosystem that you work within and learning to metabolize new learnings in a way that can be broadly communicated.
In any role, learning to deliver not just excellent code, but the technical documentation to match is the first step to developing this unique expertise.”