Forem: Devocate

Your first 30 days in a new DevRel role

Tessa Kriesel — Sun, 06 Feb 2022 21:11:30 +0000

Your first 30 days in a new DevRel role will be vastly different company to company. For the sake of clarity, let’s specify that this is your first 30 days after you’ve successfully completed company onboarding. As a DevRel function, fulfilling your company onboarding is incredibly important. You need to fully understand the business & product offerings to drive the greatest impact.

DevRel Discovery

DevRel discovery, as I like to call it, is the process you go through after completing your onboarding to learn about the company, products, & stakeholders you will be working alongside.

After your DevRel discovery process you should be able to answer the following questions:

What products does your company offer to developers?
Is your company developer-first or developer-plus?
What is the monetization strategy for developer products?
What roles do developers play in the decision-making process currently?
Does your company have defined personas, specifically around developers?
What is the value proposition to developers?
What is the product-market fit?
Who are your competitors?
How are you different from your competitors?
Who within the company understands DevRel?
Who within the company doesn’t understand DevRel?
What are the goals & priorities of key stakeholders across the org?
What gaps or challenges do you foresee facing with internal stakeholder buy-in?
Which stakeholders will you work with on a regular basis?
What does the marketing funnel look like?
What does the sale process look like?
What tools do sales and marketing use to track conversions?
What other tools are procured and available for your use?

Week 1 — Developer Products

Week 1 you should focus on understanding the landscape around your company’s product offerings for developers. Teams that can be incredibly valuable for this research are sales & sales engineering, or anyone else in the go-to-market org. Customer support or success can also be a valuable resource here as they work with your audience on a routine basis. You may even be able to find a lot of these answers on the internet if your company is 3+ years old and has a funding stage of Series A or greater. The research you will do on the internet will be impactful for your go-to-market strategy, so take lots of notes and find a way to organize those notes for your future self.

By the end of week 1, you should have most of these questions answered. Be sure to iterate on these answers as you grow in your role.

What products does your company offer to developers?
Is your company developer-first or developer-plus?
What is the monetization strategy for developer products?
What roles do developers play in the decision-making process currently?
Does your company have defined personas, specifically around developers?
What is the value proposition to developers?
What is the product-market fit?
Who are your competitors?
How are you different from your competitors?

Week 2 — Preparation & Schedule Calls

Week 2 you should be heads-down, and ideally, your manager is okay with this. You spent your first week capturing insights to better understand the developer fit & landscape at your company. Now it’s time to prepare to speak to stakeholders. Acceptance and understanding with internal stakeholders can make or break the success of a Developer Relations program.

From what you know so far, pull together a “What is DevRel” slide deck that you can quickly present in 5 to 10 minutes with key stakeholders. It’s too early to bring too many company insights into the deck, but if there are places you think you can relate DevRel to your company objectives, by all means, go ahead and do so.

Schedule time with key stakeholders across your organization for next week. Who you meet with depends on your company size and stage. Compiling this list will be a lot easier at early-stage companies. Generally, you want to speak to people across the following functions:

Sales or Sales Engineering, specifically those selling to developers
Marketing or Product Marketing, specifically for developer products
Customer Success or Support, specifically those serving developers
Product, specifically those leading the developer products
Engineering, specifically those building the developer products
Other functions that are currently serving developer audiences in any capacity

Ideally, your manager should have insights into who you should speak with, but sometimes this isn’t always the case. Ask about a company org chart and leverage that to identify who you could speak to. You can also ask folks in your calls who else you should speak to.

Week 3 — Stakeholder Interviews

The intent of this week is to mostly listen. Who understands DevRel? Who has worked with this function before? Leverage your slide deck when someone doesn’t know or understand DevRel. You want to better understand who you have as an early ally and who you will need to explain things to more deeply as you progress in your role.

As you’re chatting with stakeholders, ask them what they think the company priorities are and how they align with their team's priorities. What are their own objectives and goals? What challenges do they face? As you’re collecting data, you want to better understand how you can drive impact for that team, as well as better understand where you may be able to work alongside that team.

You should be able to answer these questions after your stakeholder interviews are completed:

Who within the company understands DevRel?
Who within the company doesn’t understand DevRel?
What are the goals & priorities of key stakeholders across the org?
What gaps or challenges do you foresee facing with internal stakeholder buy-in?
Which stakeholders will you work with on a regular basis?
What does the marketing funnel look like?
What does the sale process look like?
What tools do sales and marketing use to track conversions?
What other tools are procured and available for your use?

Take detailed notes. Defining a stakeholders list for use later by both yourself and your team will be incredibly helpful. Stakeholder understanding and support of DevRel are incredibly important.

Week 4 — Developer Experience Audit

It’s time to put yourself in the shoes of the audience you will be serving. Dive into your company’s website and current offerings as if you were a developer looking to discover and evaluate your company’s products for your use. You can even ask a developer peer to do the same, what things caught their attention? What did they like? What seemed to turn them away?

You should be able to answer the following questions as you work through your audit:

What products are available to you?
What features do those products serve?
How much do the products cost?
How long will it take you to implement those products?
Is there proper documentation to implement these products?
How long will it take you to reach “Hello World?”
What do the communications look like?
Do they have a published changelog?
How does your company currently appear to developers?
Are the communications and platforms promotional?

With the research you capture, pull together a Developer Experience Assessment. You will be serving this audience and may need to instill your knowledge and expertise to make improvements to this experience. This assessment will give you insights into the work you have ahead of you.

Resources

How DevRel Programs Drive Business Impact

Tessa Kriesel — Thu, 03 Feb 2022 21:54:22 +0000

Developer roles within organizations

Developers can play many key roles in an organization's success. I’m sure many can argue there are more, but let’s focus on these four key roles:

Users
Innovators
Employees
Advocates

DevRel can drive awareness

Most developer relations programs focus on developers as users. They drive awareness and adoption of developer users through education and community efforts. Great developer relations programs create advocates too. And not the kind of developer advocates we bring onto our DevRel teams, but the kind I call superfans. Superfans are the kind of developers that are going to scale your business because they’re singing your praises to their peers.

Innovators & employees—are missing from 90% of developer relations programs.

DevRel can create a recruiting pipeline

DevRel programs can drive greater impact internally by partnering with technical recruiting teams to leverage the same tactics they use to drive developer user adoption to increase the recruiting pipeline. It’s a missed opportunity on both sides because there are often recruiting budgets that DevRel teams can “borrow” from to validate an event or activity that is out-of-budget or scope but valuable for trust-building and recruiting.

DevRel can scale non-developer products

Innovators are where developer-plus companies can truly benefit from a Developer Relations program. Many products that don’t serve developers can find success by building a program to create innovators. What I mean by innovators is when you create a space for developers to improve or build upon your product. Let’s take Notion for example. It’s a great product but it wasn’t built for developers. Do developers use it, they sure do. Where Notion can win with a DevRel program is by enabling developers to find success in building on top or alongside Notion. They’ve already figured this out though and launched a developer offering in May of 2021. It’s still in beta, but they’ve seen the value in empowering developers to build with Notion in mind.

How DevRel Programs Win

They deeply understand the DevRel framework
They leverage education over promotion
They understand that building trust is their top priority
They capture feedback and insights to better understand their audience and drive innovation
They define a developer journey and reference back to it frequently
They drive impact to the company goals & their program goals
They’re able to define what success looks like & report on it regularly
They advocate internally for their users, and authentically communicate company updates externally
They build a sense of community around their peers and leverage that community to build trust and accomplish their goals
They care deeply about the developer experience and continually improve upon it

Developer Relations programs leverage community-driven methodologies that build trust among developers. Instead of spending money on paid ads, they write blogs posts and conference presentations to educate their peers on the value of a solution or product, authentically. They show up, authentically, in the spaces where their peers spend time, providing support & education. They may even join their peers in helping them build something or dive into an open-source project they’re working on. They listen to what developers need and do everything they can to deliver it to them. Developer marketing does not exist, because developers don’t want to be marketed to, they want to feel supported by familiar faces and folks they trust.

Business Impact of DevRel Programs

When an organization can provide stakeholder buy-in, budget, resources, & team support of the program, they can find impact in the areas that matter most.

Increased revenue & funding
User growth & retention
Product innovation & improvements
Customer satisfaction & support deflection
Strong technical recruiting pipeline
Brand recognition & awareness

Developers are incredibly impactful in any organization and when you’re able to build programs that align with their needs & solve their problems, business impact follows.

DevRel Teams: Solitary to Collaborative

Tessa Kriesel — Tue, 01 Feb 2022 12:06:00 +0000

Developer Relations is a relatively new industry, at least the term anyways. For me, the most frustrating part of our “youth” is speaking to contributors who are new to DevRel themselves and are thrown into a role where they’re a team of one, not fully understanding what they got themselves into. Being a DevRel team of one can be an incredibly stressful role and many areas can play into this. At any given time a DevRel team can be working to accomplish the following list of tasks.

DevRel Contributions*

Content creation
Advocacy
Strategy & planning
Team management
Events
Internal company relations
Research & technical expertise
Support
Outreach
Product development
Marketing
Website updates
Social media
Stakeholder buy-in

If we look through this list, we can see numerous roles across an organization, and DevRel is often expected to do them all with their developer audience. Depending on company structure, you may be able to find allies across the org to help support these areas, however, these allies may not know your audience as you do. In my career, I’ve found allies across all of these contribution areas, but I’ve had to work hard to instill what developers need versus other audiences.

Solitary to Collaborative

Whether you’re a team of one or a team of many, you’re still tasked with the same objectives. A team of one requires more of a generalist to find success, whereas a collaborative team means you can hire people more specialized in their experience—likely driving a greater impact in that niche. It’s how you scale your developer program efforts.

DevRel Objectives*

Educate & support developers
Drive awareness
Drive engagement
Feedback on products
Build brand
Drive innovation
Drive sales (through education)
Support deflection
Enhance other products
Obtain code contributions

Let’s take this list of objectives and sort them into the four functional areas of developer relations.

Marketing

Drive awareness
Drive sales
Build brand

Community

Educate & support developers
Drive engagement
Feedback on products
Obtain code contributions
Drive innovation
Support deflection

Education

Educate & support developers
Support deflection

Experience

Educate & support developers
Drive innovation
Enhance other products

These lists can easily be interchanged, there are no two DevRel teams that are exactly the same, but these separations resonate with my experience and what I’ve learned. Developer Advocates play a role in all four of these functional areas, while a community manager usually focuses on the community function and passively supports the others as needs arise.

If you’ve read the book “Developer Marketing Does Not Exist” you’ve learned that developer marketing, well, doesn't exist, but it doesn’t exist because it’s in the form of education over promotion. Therefore, it’s not really marketing. That doesn’t stop your stakeholders from assigning marketing-like goals to your programs and team. Therefore, you need to do this through educational driven contributions and focus on what your audience needs to find you trustworthy.

Your DevRel program can be one-person or a fully-staffed team with leaders across various functions. If you’re a lean program and only have a developer advocate on staff, it’s likely those folks are burning out, quickly. Consider finding allies across the org to supplement their contributions as well as bringing in someone to specifically lead the community and maybe even experience. As you scale you should consider bringing in additional developer advocates, DX engineers, technical writers, multimedia producers, and more. I’ve shared some job titles below that I’ve seen across various Developer Relations teams.

DevRel Job Titles

Developer Advocate
Technical Community Manager
DX (developer experience) Engineer
Technical Writer
Developer Marketing Manager
Events Coordinator
Program Manager
Campaign Manager
Community Engineer
Community Coordinator
Outreach Manager
Community Programs Manager
Curriculum Engineer
Training Manager
Product Manager
Technical Support Engineer
Technical Editor
Programs Engineer
Multimedia Producer

Every organization has different needs and different goals and DevRel teams need to adapt and understand how to best serve their developer audience across many different specialties and skillsets.

* Data captured from the State of Developer Relations report

Upcoming Webinar

Building a DevRel Team Webinar

We'll cover functional areas of DevRel, how to build a team upon your needs, and reporting structures for success.

Wednesday, Feb 16, 2022 11:00AM - 11:30AM CST

Upcoming Twitter Space

Friday, February 4th at 9am PT / 11am CT / 5pm UTC

// Detect dark theme var iframe = document.getElementById('tweet-1488253517013807104-337'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1488253517013807104&theme=dark" }

Why Your New Software Needs a Developer Community Before Marketing

Tessa Kriesel — Mon, 18 Jan 2021 19:50:35 +0000

So, you’re launching a new software product. Where do you start onboarding new users? Who do you target?

My suggestion is to build your developer community first, then market to the masses… no matter your ideal end-user.

Here’s why and how to get your own developer community started.

Why Your Software Needs a Developer Community

Putting ego aside, developers are often the best people to catch mistakes other developers make. They’re also ideal to help onboard less tech-savvy users down the road.

The first reason to gain the support of developers first, is to improve your product before regular users get the opportunity to break it. We all want to hope our MVP (minimum viable product) will come out flaw-free, but the truth is that it usually doesn’t. Offering a beta testing program is a wonderful way to create a developer community surrounding your product that could produce long-term brand ambassadors.

Second, having a developer community can deflect a chunk of work from support later on. Usually having a large amount of everyday users results in a lot of questions. Your developer community can alleviate this work through:

Documentation Writing Programs: Offer incentives or monetary pay to write documentation for your users. Include everything down to the simplest questions.
Open Community Forums: Invite your developers to become moderators or designated experts on your products in open community support forums.

Find Your Developer Community

Targeting developers isn’t quite as simple as most marketing techniques. Developers are picky and each is motivated by varying factors. The key is to make sure you know which kind of developer you want in your community. Then, create a developer program with the right pillars to meet your goals and theirs.

Once you have those two things in place, “hang out” where your ideal developers are. Sponsor their favorite conferences, podcasts, and blogs. You can also run ads to targeted channels and through social media platforms, but I would recommend more community-oriented advertising.

Developers are a very marketing-wary community. Gaining their trust requires a specific three-step model:

Build Trust: You can’t simply “capture the attention” of a developer with something as basic as an ad (well you can, but it’s hard). You have to give them a reason to trust you first. Sponsorships and community-supporting efforts help build this trust while boosting brand recognition.
Provide a Value: What can you offer that your target audience might find value in? Go back to the developer personas and use their motivations to think of incentives for joining your developer community.
Make the Ask: This is where you meet your own goals. What do you need back from your developers? Documentation? Product feedback? Community support forum responses?

Your developer community is worth the investment. They’ll be the ones there to help you improve your product and support your users when you need it most. You can always hire more help, but a developer community is irreplaceable for product feedback, brand-building, and community support.

Let’s Launch Your Developer Community Together

Devocate is here to help if you want to launch a strong developer community around your product. Let’s work together to build and leverage a strong developer audience to grow and improve your product.