Developer Relations exists and is executed in different ways at almost every company. Our Developer Relations journey at PostHog has just begun, and we still don't know exactly what it will look like in the medium term. But we can still assess what our needs are going to look like and formulate a plan to seed, grow, and scale Developer Relations. This plan, at the very least, provides a level of clarity that enables us to move forward as we iterate, learn, and continuously improve.
In this post, I'll share the questions I've posed myself about seeding, growing, and scaling Developer Relations. I'll include my general answers and the specifics about how we're approaching DevRel at PostHog. In doing so, I hope you will find the sharing of these questions, how we intend to answer them, and the process we've gone through valuable when planning the growth of your DevRel team.
This one is simple. If a company has one or more products that developers use, then the answer is "yes" because Developer Relations exists to serve customers who are developers.
Needing DevRel doesn't instantly mean you need to hire a team or even have a person in a full-time DevRel role. But it does indicate that you need somebody to wear a DevRel hat from time to time.
PostHog is an open-source developer platform. We do have end-users of PostHog that aren't developers. But there are plenty of interactions with PostHog from developers. It is installed, maintained, integrated, and also used by software developers with a product mindset. My current thinking is that a key persona for DevRel at PostHog is someone who would identify themselves as a "Product Engineer" or a product-minded software developer.
Responsibilities that could fall to dedicated Developer Relations roles will likely fall to other team members at early stage developer-focused startups. But, as a company grows, there will be a need to have people taking on DevRel in a full-time capacity.
DevRel is a multi-functional profession:
What activities you'll need your DevRel roles to undertake from the above will depend on the company goals and on:
Anyone who knows me and is reading this may be surprised I've not mentioned AAARRRP, the DevRel strategy framework yet. Well, there you go. The point of AAARRRP is to help you map your company's goals to DevRel activities that can help you achieve those goals.
Further reading: If you find this guide useful, you might also enjoy what we've learned about dev tool marketing so far.
PostHog has seen significant growth over the past year resulting in a Series B raise. Following this, James and Tim, our co-founders, decided it was the right time to introduce dedicated DevRel roles (I'm particularly pleased about this because it means I now get to work here!). Before this, all potential DevRel activities were spread across other team members. But, because PostHog is a developer-centric company, operates with small teams, and embraces stepping on toes, people need to continue to do what's required to ship. There are, however, some gaps and opportunities where DevRel can make improvements or begin new activities.
In the near term, our AAARRRP goals are Activation, Retention, Referral, and Product. Instead of narrowing in on specific activities, we've broadly mapped the priorities as:
The roles your company needs depend on the focus and activities undertaken by people within DevRel roles.
The most frequently found roles within Developer Relations and the activities they undertake are†:
† [Source: Most popular roles within Developer Relations](https://noti.st/leggetter/9B23EW/defining-the-roles-within-developer-relations-v0-1-0 #s6yhNbi)
We'll hire based on our activities priority list:
In early-stage startups that need Developer Relations, the go-to hire is frequently a Developer Advocate because this person will have to do a bit of everything. The company is probably still trying to work out what DevRel will do.
The other roles that are often the first DevRel hires are Technical Writers and Developer Educators because documentation, sample code, and exceptional developer content is fundamental to developer-focused products. A Developer Educator role has more of a focus on community engagement activities such as blog posts and video creation.
As a company grows, there will be more specialization. This isn't specific to DevRel and is common across many functions.
You may begin by hiring one or more generalist Developer Advocates who will contribute to docs, update and maintain SDKs, create sample code, and engage with external communities. It's also likely that you'll need to bring a Community Manager on board to engage with directly and facilitate broader engagement with communities.
As the company and thus DevRel team grows, you're going to need specialist roles.
For example, you can create a Developer Experience team of Technical Writers/Developer Educators and Developer Experience Engineers that focus on documentation, SDKs, and sample code. Developer Advocates will then shift focus to more community engagement activities such as workshops, meetups, speaking, and continuously gathering feedback directly from developers or identifying technology trends within communities. In addition, you may create a Developer Education team focused on blog and video content because 2020 has demonstrated the value of companies having such dedicated developer content teams.
As this growth-fueled shift occurs, it's essential to understand that you're changing the roles' definition - or at least the potential breadth. You may lose people who like being a generalist unless you can continue to allow them to contribute outside of their specialization. For example, Developer Advocates are likely hands-on coders, so when shifting, ensure they still have opportunities to contribute to docs, SDKs, and sample code.
I've been hired as the first person in Developer Relations, and I've spent some time working on docs, engaging with our community on GitHub and Slack, have organized some newsletter sponsorship, and am taking a look and upgrading our swag/merch. I'm the generalist first hire.
The "What DevRel roles do you need?" section outlines our likely short-term hiring plan of Developer Educator, Community Programmes Manager, a Developer Advocate, and ideally a Technical Writer. Beyond that, I can see a few growth opportunities:
†† I can see value in a rotation schedule being across multiple DevRel roles and also into non-DevRel roles.
As things stand, I don't believe we're going to form a "DevRel team". Instead, I believe we'll have a DevRel Guild where DevRel roles will reside within small teams, providing DevRel skills to those teams as they need them. If we grow as outlined above, I can see teams formed that consist mainly of DevRel roles with a focus on experience, education, and marketing.
How we grow will change with the company needs, but this gives us a few directions we could potentially go in.
I believe there are three key factors:
I've already covered that with growth comes specialization. Specialization results in focus, and a team will ultimately be able to deliver more that way ; a team asked to focus purely on developer content creation will deliver more than a team asked to write docs, update SDKs, write sample code, write blog posts, manage and present on Twitch streams, and speak at events.
Team structure can be Functional, Multi-Functional, or Regional, but the DevRel roles should be focused.
Examples of Functional and focused DevRel teams are:
In a Multi-Functional team set up where a team consists of Product Managers, Engineers, DevRel roles, and Marketing roles, the specialization may change from sprint to sprint as a product moves through the product life-cycle ; from inception/proof of concept through to a go-to-market phase. Occasionally changing specialization can be a good setup for a generalist developer advocate, allowing them to apply their broad range of skills but still have time to focus in stages as product development progresses.
For example, the DevRel role's focus may shift:
Regional teams are often multi-functional but, as you'd expect, focus on a specific geographic location. You'll most likely see this as the number of DevRel roles at a company gets to a point where it's possible to justify having North American, EMEA, and APAC regional teams.
It's always important to be collaborative. But there's also a lot of value in not having to collaborate on absolutely everything to get something done. Therefore, a team should be empowered as much as possible to do everything they need to get stuff done ; equipment, software, skills, authority, budget, and more. If you're leading a DevRel team, this most definitely means support. Your role as a leader of a DevRel team - and any empowered team - is to support and enable them, not tell them what to do.
When scaling, it's essential to think beyond simply adding headcount. That, in itself, isn't scaling. You're only really scaling a team if further investment increases output more than the increase in input. For example, if a Developer Education team of five people produces five pieces of content a week (one piece per person), adding another person should result in the team producing more than one additional piece of content a week. The additional headcount should help the team be more efficient or create new programs that result in exponentially more content (at least more than one piece per week from the previous example).
So, how do you scale DevRel? As discussed, a specialized, focused, and efficient team is a step in the right direction. But, the real opportunity to scale is through collaboration with customers, partners, and your broader community. Let's use the word "community" to encapsulate customers, partners, and the wider community to simplify things.
Firstly, you should work for and with your community to create a flywheel effect. You should do this in combination with programs that support and enable collaboration. Here are some examples:
As with many things in DevRel, these are unlikely to be quick wins. But, as the community grows, engages, and contributes, the velocity of the flywheel increases. As this happens, the community is increasingly responsible for the input and output as you work to scale your DevRel program. A word of caution: do not start too many programs in parallel. Instead, identify the one with the highest value and get that right first. Then, move on to the program with the next highest value.
I'll admit this sounds very enterprisey, but change management isn't something that should only happen in enterprise organizations. I've seen change mismanaged at both startups and enterprises, and because I've felt this pain and managed the fallout, I know it's so important.
The approach not to take is:
A simple yet much better approach is:
This process will take a bit more time. But, because everyone has had an opportunity to contribute, they're more likely to be bought into the decision. At the very least, they'll understand why the decision was made. If you don't involve people impacted by the change, you may have made the decision faster, but you'll fight inertia and get to the desired destination slower.
It's just too early to know if DevRel will need to scale significantly. But I'll ensure we approach it as outlined in this section.
Developer Relations typically reports into Marketing, Product, or Engineering. However, in smaller companies, DevRel may directly report to a founder.
Two things should determine what function or who DevRel reports to:
At the time of writing this (September 2021), PostHog is around thirty people, so I report to James, our CEO. Has James worked in DevRel before? No. But he can code, is the co-founder of an engineering-lead company, and believes in the power of the developer.
Will DevRel always report into the CEO? It's too early to say. As you'll see above, we're still iterating, and things will change.
DevRel at your company will change, and DevRel at PostHog will change (see DevRel: from startup to enterprise). DevRel isn't any different to any other role or function in this respect. However, it does feel like there is often some uncertainty about DevRel and that Developer Relations teams have endured more change than traditional functions. I believe this is because "modern Developer Relations" (see History of Modern Developer Relations by Brandon West) is still a relatively new profession in comparison to the likes of Engineering or Product.
Developer Relations at some companies, such as Twilio, is seen as a constant. Those who have worked in the industry for a while have seen DevRel teams come and go, which can be unnerving. However, there is no doubt that, when understood, supported, well-executed, and measured correctly, a DevRel team can significantly influence the success of a company and, in some cases, be transformative.
A big thanks to Martyn Davies for providing feedback on this post. _Enjoyed this? Subscribe to our newsletter to hear more from us twice a month!
Subscribe to our newsletter
Read by 100,000+ founders and builders
We'll share your email with Substack
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
