DevRel in the NEAR ecosystem
You’ve got a dev in me
As you may have heard, Developer Relations is splitting into two core departments, serving two related but distinct goals. There will be a follow up post describing the second department, which will be a spin-out from the parent organizations. Here is described the internal department of Developer Relations as it should be organized moving forward.
Intro
To start, I want to clarify that the DevRel team is a challenging one to categorize. It doesn’t really fall inside of Near Inc, which is essentially the engineering core of NEAR, nor does it really fall under Near Foundation, which represents BD, education and funding. It straddles both, making defining the roles and responsibilities of the team a little more confusing.
Historically, this has been made even more challenging by a set of goals that seemed to grow as the team grew to meet them. This makes sense on one level, because–by definition–DevRel serves both a technical (dev) and non-technical (rel) purpose. Generalists attracted to this role and team tend to have broader skillsets, and thus tend to take on a versatile array of tasks.
It’s become clear that in order to continue to scale, we really need to reduce the chaotic pursuit of all that is valuable, and prioritize only the things that are most valuable. In this post, I want to make clear the focused mandate of DevRel moving forward. I’ll cover the goals and metrics, as well as how this team is held accountable to the ecosystem to deliver on the mission.
The DevRel Mission: Delight developers, inspire builders, grow the network. Build cool shit.
The DevRel Priorities: a pyramid
From these priorities, all OKRs and metrics flow. These are pretty self explanatory and serve as the North Star for the DevRel team for the foreseeable future. Perhaps even after Polaris, the real North Star, burns into a supernova oblivion.
- Priority One: Increase the number of successful apps running on MainNet
- Priority Two: Increase the number of successful developers deploying and improving their apps on TestNet
- Priority Three: Support the continued maintenance of the material that will allow devs to self-serve and be successful
The DevRel Funnel: an inverted pyramid
When you flip this pyramid, you get the funnel that we can use to move devs from awareness to engagement, and then to activation. New friends traverse from the top of the funnel down to the full activation of becoming besties.
At each step of the funnel is a theoretical conversion rate from a core metric, then there are activities we can engage in to improve those core metrics. The idea is that these are very simple mental models for three steps in the process of converting from a curious hacker to a competent CTO or technical entrepreneur.
If we muddy the process with too many steps or get too granular at this point, we are taking away from the core purpose: to help more people build on NEAR successfully. The product we offer here is the feeling that anything is possible on this amazing platform. Getting caught in the weeds of a complex conversion funnel doesn’t serve that, nor does having insufficient categories to target.
DevRel Metrics
Below is the list of top metrics. It’s doesn’t include every single thing that we could be measuring. It’s a list of what we are currently looking at. I think these are a good start and the bucket that needs the most work is the P3 category. At this time, any activation we participate in causes a spike and any period of inactivity leads to a slow decline in these metrics. That’s good and bad news.
Bad news: it means that we don’t have real product-market-fit for our developers. If we did, our inactivity would not lead to a decline. We would just coast on previous activations. In other words: people don’t sufficiently feel that anything is possible on the platform with what we’re delivering currently. We’re not making them feel awesome when we’re not sitting next to them.
The good news: it’s a direct impact metric. The more effort we put in, the more value out, at least for now. This means that focusing on P3 and P2 in the next two quarters is both necessary AND sufficient to make a meaningful impact on the developer ecosystem. Knowing what to focus on is not always a given so we have that small luxury.
-
MainNet
- Unique contracts deployed on MainNet
- Number of builders on MainNet (this number is low enough now that it is manually measured)
- Number of active accounts (this is a downstream effect and only matters if we are doing MainNet support well!)
-
TestNet
- Unique contracts deployed on TestNet
- Monthly active developers on TestNet
- Weekly returning active developers on TestNet
-
MetaNet
- Views on documentation pages, example pages etc.
- Attendees of events we host or sponsor
- Hackers pursuing our sponsorships of external hackathons
- Hackers participating in our hackathons
- Activity in our supported developer chat channels
- Views on developer media channels
- Engagement on developer media channels
DevRel Departments and Roles
For all new hiring to the team, there are three categories of work we do and there are three core roles inside of the team. Roles other than these, such as design or product related work, should be embedded but ultimately managed by an external service team.
Categories of work
Engineering - for example, building an example application for a common developer use case.
Content/Awareness - for example, writing a blog about how to manage multiple contracts in one project.
Ecosystem/Engagement - for example, going to a in-person meetup (safety and sanitation permitting) in order to present a workshop
Roles
These roles have a gradient between them since almost everyone on DevRel is expected to be technical and comfortable communicating technical concepts. Having a definite title doesn’t mean someone is precluded to a certain subset of activity, it just means that it’s more likely they will spend the bulk of their time in activities closest to their role.
Developer Evangelist - 70% Rel and 30% Dev. These people spend most time in engaging with an audience, creating content, interacting with hackers and giving talks.
Developer Advocate - 70% Dev and 30% Rel. These people spend most time creating example apps, adding issues to libraries based on dev feedback, helping go through code samples, and writing docs
Software Engineer, DevRel - 90% Dev and 10% Rel. These people spend most time creating code templates, thinking up new ways to make the development process smoother, creating highly technical educational material, and coding solutions to devs architecture issues.
You can get a picture of the specifics of these roles from this calculator: DevRelOMeter: Are you practicing Developer Evangelism or Advocacy?
What DevRel DOES do
The focused DevRel team will engage in activities that drive the above metrics. A comprehensive list of activities here doesn’t make much sense and would take up a sizable amount of space, but here are some concrete examples:
Creating and maintaining a developer portal for all things near dev
Curating reference/API documentation
Supporting hackathons
Async dev support
Creating technical tutorials
Producing dev video content
Creating, delivering and maintaining interactive workshops
Writing technical blogs that explore cool features of NEAR
Engineering relevant examples
Producing copy and paste-able templates
Making light-weight and useful tools for devs
Pre-sales
And of course
Building relationships with developers!
The difference between DevRel of the past and the DevRel of the future, is actually more to do with what the team won’t do moving forward.
What DevRel DOES NOT do
Business Development
Sales from start to finish
Sourcing new projects
Business partnerships
Ecosystem integration partnerships
Full-time Integration Engineering (unless we decide with BD this is a necessary department that sits here)
One-off product development sprints
Finishing projects that are about to crash
Project management for dapps/startups
Embedding with dapps/startups
Go to market strategies
Doing random tasks requested by external teams
These activities have been really valuable, but the cost of having them centralized in the DevRel team is that developer support activities have fallen to the wayside. It’s not that we should not do the sort of thing listed above, but DevRel as a department should not do them. What this costs is the wide variety of potential things that anyone could work on in DevRel at any given time. What it gains is consistency, focus and faster forward progress.
Example scenarios:
Alice comes into the NEAR ecosystem and sees a video from an engineer on the DevRel team. She asks the Engineer if they can helper her with her “app architecture.” Since she is the CEO, the engineer passes her over a contributor in the BD department, and then finishes a video on “How to manage access keys.” No fuss, no muss. Way to go DevRel Engineer!
Bob, a developer that found out about NEAR from a hackathon, is almost done with his cool new application. He reaches out to a public channel on Discord for help! He’s almost there, but totally stuck. One of the Developer Advocates on the team sees his cry for help. She offers to jump in a call (since she is on-call for chat support anyway) and helps Bob through the problem. She writes down in a shared doc the nature of the problem for other Dev Advocates in case it comes up again He ships and ends up making 20 trillion dollars (almost as much as the US national debt!), all because of her 5 minutes of help[1]. Way to go Developer Advocate!
DevRel Team Process
Tools
We do all our work using the github project here: https://near.ai/board. This is also consumed into near7.monday.com for analytics on the capacity of the team. Coming soon is a public content calendar.
We work in two week sprints with one day for admin, meetings, or just general hacking. This ends up being 9 business day units of work:
Because events frequently fall on nights and weekends, you might find a surprise devrel holiday on a random weekday for the team to rest shortly after a big push. This is part of the team culture of hard work, trust and well-deserved rest.
Accountability
- The team is accountable through OKRs to the NEAR foundation board, the CEO of NF, and the CEO of Near Inc.
- This is facilitated through the Head of DevRel, who communicates directly with those stakeholders weekly on team progress
- The team is also accountable to the community of developers in the ecosystem. We don’t have a formal measure of this yet. This could be based on sentiment metrics in the future.
- OKRs are decided by the DevRel team leads, signed off by the head of the department, and reported on monthly and quarterly to leadership team
- Review meeting: Demo day
- The team presents biweekly on what they have worked on
- CEO Near Inc. shares context back
- Required/requested elements
- Intro at a high level
- Bi-weekly updated metrics dashboard
Refocused OKRs
MainNet
- OKR 1 - Create the “How to launch on MainNet” Guide
- Cover the checklist going from testnet to mainnet
- Cover cases going from Eth to NEAR
Testnet
- OKR 1 - Build Toy Apps (yarn deploy → testnet) based on requests heard in developer support sessions and channels
- OKR 2 - Organize and support Hackathons (internal and external)
Top Funnel of Developer Ecosystem
-
OKR 1 - Grow ecosystem by 1000 new devs
- 500 more active NEAR developers
- Expand Contributor Program to include content & communication (2500 devs)
- 5 case studies with mainnet/testnet partners re: the development/launch experience (user research & feedback)
-
OKR 2 - Enhance Documentation and Self-Serve Resource Expansion
- 5 new content series, i.e. How to Launch [X] on NEAR
- Close out 5 major and 50 minor issues across tools and documentation
- Add use case-specific quick-start toolkits and docs (i.e. DEX launcher, NFT launcher) based on the demand of developers in the ecosystem
-
OKR 3 - Create Social Proof for NEAR
- 3 external developer websites publish NEAR examples or how-tos
- 3 external education platforms publish content about NEAR
- 3 media placements/case studies about successful NEAR launches
Conclusion
This direction should give everyone in the team AND the stakeholders of the team more reasonable expectations for how we are going to grow into the future. We have been doing far too much for the last several months, and still I have been dissatisfied seeing crucial developer metrics flagging. This was done on purpose at first; a sacrifice for higher priority targets. Now that we have the opportunity to trim the sails on this ship and set a clear course, it should be smooth sailing for the DevRel team and our friends in the ecosystem!