# DevRel in the NEAR ecosystem **URL:** \ **Category:** Developer Relations\ **Created:** [May 31, 2021, 5:07am UTC](https://gov.near.org/t/devrel-in-the-near-ecosystem/2487 "2021-05-31T05:07:54Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![potatodepaulo](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/potatodepaulo/32/97_2.png) [@potatodepaulo](https://gov.near.org/u/potatodepaulo)\ **Post date:** [May 31, 2021, 5:07am UTC](https://gov.near.org/t/devrel-in-the-near-ecosystem/2487/1 "2021-05-31T05:07:54Z")
# 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. 1. Priority One: Increase the number of **successful** apps running on MainNet 2. Priority Two: Increase the number of **successful** developers deploying and improving their apps on TestNet 3. Priority Three: Support the continued maintenance of the material that will allow devs to self-serve and be **successful** ![Pyramid](https://europe1.discourse-cdn.com/flex005/uploads/gov_near/original/2X/0/0abce7c72edbce5507365bbde8ff59bc2b352c6d.png) ## 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. ![Funnel@3x](https://europe1.discourse-cdn.com/flex005/uploads/gov_near/original/2X/f/faab644bb3ace9acd0d3108d779e74fcb2f787b9.png) 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 - TestNet - MetaNet ## 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?](https://leggetter.github.io/devrelometer/) ### 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](https://near.ai/board). This is also consumed into [near7.monday.com](http://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: ![image](https://europe1.discourse-cdn.com/flex005/uploads/gov_near/original/2X/2/2d171f1bbb0b48309455fc01178c804e32316bc1.png) 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 1. OKR 1 - Create the “How to launch on MainNet” Guide 1. Cover the checklist going from testnet to mainnet 2. Cover cases going from Eth to NEAR Testnet 1. OKR 1 - Build Toy Apps (yarn deploy → testnet) based on requests heard in developer support sessions and channels 2. OKR 2 - Organize and support Hackathons (internal and external) Top Funnel of Developer Ecosystem 1. OKR 1 - Grow ecosystem by 1000 new devs 2. OKR 2 - Enhance Documentation and Self-Serve Resource Expansion 3. OKR 3 - Create Social Proof for NEAR ## 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!