DEV Community: DevRel.Page

What is B2D Sector?

Zeus — Mon, 18 Oct 2021 04:26:14 +0000

In the previous carousel, we completed a whole series called "Developer Relations --- Digging Deeper" with its last edition "Developer Experience Specialists", where we decoded the various roles in developer relations and what exactly they do? Make sure you check them out here.

Coming to this carousel, we're talking about something different. Although we'll still be talking about DevRel, this time we wanted to explore the target market that DevRel hits. Today, we'll take a look at the Business to Developer, ie. the B2D Sector. It's also worth mentioning that previously we decoded Developer Marketers, who play a key role in the marketing aspect here, an essential part of the B2D sector.

What is the B2D Sector?

B2D or business to the developer is a sector that focuses on the developer-focused market. Software/ Hardware Developers, basically people who tend to spend their time working with "code" are the main target audiences. Most commonly, here the main focus of the business is towards creating tools and systems which make these Developers more productive and focused on the product they're looking to develop, rather than dealing with additional things that come up with building scalable software. Most of the successful B2D companies combine a mix of developer marketing along with developer relations techniques to drive the ongoing engagement throughout the developer journey.

Who are the audiences?

The need for the B2D sector arose when the standard business practices started to fail for major companies for this new audience that was being developed. The developer audience was difficult to characterise within the standard B2B and B2C categories. Here, one cannot focus on sales, nor mass marketing. Both traditional practices fail when this audience becomes in charge of purchasing the product. Here, the product became the king. Showing the product's real use case, regular improvement in functionality, and building a trustworthy community around it became the major way of driving the adoption.\
What makes this market more interesting is knowing that every developer is different in terms of their skills and interest. Hence, the types of tools, hardware and software that they can work with, translates to again their knowledge and interest around a niche category. This is a major reason why you might see a lot of hobby projects becoming full-scale businesses in the very short term and even major businesses becoming obsolete in a matter of days in this sector. The community people build around their product fuels their business growth and product development.

The modern-day, Developer market, according to us can be broadly classified into the following 4 categories -

Engineers
Data Scientists
Architects
DevOps Specialists

It is important to note that this segregation is not absolute. As we have mentioned before, the skills and interests of developers may vary heavily. This will definitely cause interdisciplinary fields to occur. The broad classification here helps us understand the product and tools that are developed in this sector more clearly.

Engineers

Engineers, to be honest, is a very broad term and can be used as a synonym for Developers almost always, but here we are talking about folks who build and ship products, web/ mobile apps, computer games, and more. Their characteristic is building actual products, usable by the masses.

They are builders at heart and need tools that can help them create and optimize solutions to existing problems. Talking about the roles, we can consider the following as a categorical example of the folks who are dedicated to actually building things:

Web/ Mobile Developers
Backend Developers
Software Development Engineers
Hardware Engineers

For creation and development, it's important to find tools that make their work productive. This might be achieved by

Making development environments (VSCode, JetBrains, Android Studio), or additive tools (Postman, GitHub) that make writing, testing and sharing the code easy
Providing libraries (React, React Native) or frameworks (Angular, Flask) that handle the heavy lifting and uncertainty of the actual programming language
Even developing an all-new language (Kotlin, Swift) for a specific use case
Giving pre-made solutions and infrastructure to existing problems (Twilio) that have been solved which all together,
Basically, anything that helps them build and ship high-quality products faster.

Data Scientists

Data scientists are responsible for making sense of raw data sets. They are basically engineers of information. They are responsible for finding trends in data and creating algorithms to decipher the raw data, making it more useful to solve a particular business problem. This role has a lot of alignment with technical roles, including mathematician, scientist, statistician and computer professional.

The demand for data science skills has grown significantly over the years, as companies look to glean useful information from big data, the voluminous amounts of structured, unstructured and semi-structured data that a large enterprise or internet of things produces and collects.

Data Engineers
Data Analysts
Data Architects
Machine Learning Engineers

Given that data Scientists are responsible for collecting, analyzing and interpreting large amounts of data, they need tools that make dealing with data faster and easier. On the Analytics side --- tools that make visualisations that give sense to 0 and 1.

Example tools:\
Tensorflow, Tableau, Apache Spark, Matlab, Jupyter

Architects

Architects, as the name sounds, are people who focus on planning the infrastructure of the projects that will later be built by the engineers. They analyse and recommend the right combination of IT components to achieve a specific business goal. Not just that, they optimise the infrastructure to give maximum output at the minimum cost, counting for horizontal scalability in the future to accommodate the business growth. They are the main folks who determine how the different components of a network will be linked together to produce a secure and effective way of running the system.

Architects can be broadly classified into -

Cloud Architects
Software/ Web Architects
System/ Network Architects
Database Engineers
Security Architects

Tools that they use need to be specifically built to help them in planning (Lucidchart), building and testing their infrastructure (Amazon Web Services, Google Cloud, Microsoft Azure), before implementing it for the use of engineers. The tools they use need to have the ability to let engineers build, simulate working models and test the development environment.

DevOps Specialists

Developer Operations or DevOps is the field responsible for introducing processes, tools, and methods to balance the various needs throughout the software development life cycle, from coding and deployment to maintenance and updates. They are folks behind the curtains who keep things running. They can be classified based on the type of process they work in, under DevOps.

Systems Reliability Engineers
Network Engineer
SysOps Administrator
Build Engineer
Automation Architect

The majority of the work they do revolves around working around reducing the complexity, closing the gap between actions needed to quickly change an application and tasks to maintain the complete system's reliability. It's also important to understand that DevOps more than the engineers also falls down to the adoption. It depends on the changes and the process, this takes a lot of effort from an organisational perspective to strengthen and integrate the connection between developers and operational teams.

For the majority of their work, they need tools for Version Control (GitHub, GitLab), Container Management(Kubernetes, Docker), APM (Elastic, AppDynamics), Deployments and Server Monitoring(Datadog), CI/CD & Test Automation (Jenkins, TravisCI, CircleCI, GitHub Actions), etc..

How is B2D different?

B2D is mainly different because of the type of audience it targets/ wants to target --- developers.\
Developers come from a very non-traditional, result-focused mass community. They expect and want the problems to be solved while completing the whole process with minimal effort and the lowest consumption of time and resources. Developers will always be a different kind of audience --- this also includes their employers and clients. They focus on the problems that are ever-growing and need a solution with an extremely low turnaround time. Most of the time, developers themselves tend to be the users of the product while sitting among folks who make business decisions about the very same product.

The effectiveness of the tools used by developers can be proved in a relatively short period of time. This leads those products/tools to be extremely process-oriented which definitely has to involve a continuous improvement cycle. Most of the time, developers make products for solving problems faced by millions, thus, impacting millions of lives directly. So, the product needs to be extremely reliable with minimal downtime. All of the above reasons make developer-targeted tools and products very different from other traditional products.

When we look into the B2D sector, the companies will be product-focused --- which is a no brainer. Whereas, B2C is marketing focused and B2B is heavily focused on sales. So, the business focus in B2D becomes different from B2C and B2B.

Summary

Compared to other forms of sectors out there, B2D is still relatively new. But at the same time, it's proven to be one of the fastest-growing sectors currently. The B2D sector, given its focus on such a unique targeted audience --- developers, has given rise to process and business practices that never existed before. Looking at the magnitude of change it brought to the business world, many have kept those an idol to implement similar changes in the traditional industries as well.

Given the age of digital literacy, almost everyone is a developer of some kind. This has given rise to freelancers and independent developers, who with the help of these developer tools are able to build and ship complete products from scratch --- all by themselves --- something which took a whole corporate organisation to come up with, just a few years ago. All of this has provided an ever-growing market opportunity to companies who want to focus on developers. The B2D sector, along with the awesome DevRel folks working to make it successful, is going to stay here for a while, disrupting the industry like never before.

The Campus DevRel Show 🔥 - Episode 2

Zeus — Wed, 22 Sep 2021 14:57:53 +0000

This blog will be a little special and a little different. This is because of the relationship Yash (the host of the show) and the guest speaker shared within the GitHub Community. The speaker's pathway to open source and developer relations is truly inspiring. The way he formulated an open-source culture in an environment where the community aspect was missing initially makes you understand the value DevRel folks are actually bringing to the tech industry.

Before we dive more into his journey, I am sure by now you have at least some knowledge about developer relations. If you are new here make sure you check out DevRel.Page and also do check out the blog on the first episode to understand the basics of #DevRel and how "The Campus DevRel Show" started.

This episode's guest speaker is Juan Pablo Flores, the program manager for GitHub Education, leading the GitHub Campus Experts program. I am sure most of the folks who are part of GitHub's student community already know him. He is a celebrity in the Mexican student communities for the amazing work he has done and still does for uplifting the community culture in LATAM.

Juan's journey into the tech sector started in 2014 when he organized a hackathon called "MX Hacks". One of the biggest challenges he wanted to tackle was the interaction between the students. He mentioned that due to colleges being apart from each other --- private or public, there was hardly any inter-university interaction between the students. He focused on building a space where students could build whatever they had in their minds, work with folks they have never met before and of course FREE FOOD!

Did Juan start building a community before the hackathon or did he start building it along with the hackathon?

At the time when Juan started getting involved with tech communities, the ecosystem was very small. There were only a handful of people in the ecosystem who were "that influential". Even a hackathon with 15--20 people was considered big, where everything was organized on a contribution basis. SuperHappyDevHouse --- someone would allow the hackathon to happen at their houses, some other person pays for the pizzas and another brings the beer, the rest was all coding throughout the weekend.

Juan mentions that it was Google that started having strong community events in the country. That's when Juan started attending community events and eventually attended a meetup for Google Developer Group for Dart, where he met a few folks and got the idea for organising hackathons for student communities in Mexico. Juan met Jon, co-founder of Major League Hacking through a meetup. He mentions that the networks and connections he has made over the last 7 years have been the key to his and his community's development.

Random people that you meet at random places at the right time lead to better opportunities.

How did Juan learn about MLH and build LMH ( Liga Mexicana de Hackathons )?

When Juan started building MX hacks, he was also having conversations with Jon and Swift, the founders of Major League Hacking, about building the league that they had in the US, in Mexico. He also wanted to see if the developer audience would like the idea of the hackathon in Mexico --- experimenting with MX Hacks which turned out to be a success. At this point, they started organising hackathons for governments, corporates, having built a decent community built around it.. After the first MX Hacks, they started getting a lot of emails and requests from people to organise the same event for colleges across the country. That's when Juan and other organisers felt they needed a bigger league for this and started the "La Liga Mexicana de Hackatones" (LMH).

The team that organised the Mexican league were the one that organised everything. But after a while, they merged with MLH which got them more global exposure and access to resources they didn't possess before. He also mentions that not only helped him make connections with the MLH team in the US but also with the DevRel folks in the UK.

What was Juan's learning throughout his journey?

The very first thing Juan mentioned was about finding the right people to partner with while you start an organisation and then sharing the same vision with them. He also talks about the process of separation, where the team that he was part of separated to focus on very different aspects of the same idea. This involved a lot of friction, the experience of which helped him develop a different perception and approach at a very young age.. Juan also derives the importance of opportunities that are presented to the student communities for their success and growth.

Juan's journey as a developer, working at a startup and his research work.

After working with MLH for almost 18 months, Juan had a lot of offers that he wanted to take but he couldn't due to his delayed degree. Juan decided to go back to university to finish his degree at the same time when he was approached by his friend, who was working at an IT consultancy company, to start Inventive Hack. He went on working and managing his school at the same time, but after 2 years it was getting harder and harder for him to manage time. At that time, they were building apps for various companies and also made an app for Mexico city to solve their traffic problems. Juan recalls that within a week they were having conversations with the CEO of Uber Mexico and similar big startups..He and his team were just paving their way through this new journey being total beginners in their early '20s. They ended up getting a lot of media coverage that made their firm explode leading to big partnerships.

Juan had helped the owner of the lab where he would later join as a researcher, to organise a hackathon and that's how he got acquainted and landed the position as a researcher. He mentioned that writing research papers was one of the most difficult parts of that job. Talking to other researchers and getting involved with their work was a great learning experience for him.

Juan also secured a summer internship at CMU, US to work with "top-top-top" researchers in the field of human-computer interaction.

Juan journey into communities and his learnings

When GitHub was launching its first-ever batch of campus experts, Joe from GitHub, approached Juan to talk about the program wanting to know if he was interested in joining in. Juan continued his community work alongside his other ventures all along. Juan joined the program and he never felt the need to sell GitHub or force himself to do so. He had already been talking about GitHub right from his college days and he was always fascinated to see students transition from learning about GitHub to their first PR merge. He also had a deeper involvement with GitHub as he became a campus expert and then a field expert. The training into the program was definitely very hard but at the same time, he could also pinpoint the places where the program was struggling. He later also became responsible for reviewing the training of other campus experts. He wanted to be influential in this space to make more students from Latin America and the European region to be involved in the tech space.

Juan recalls that learning how to react to incidents had been great learning, during his MLH days. He also recalls his biggest learning through his journey --- "Importance of access to opportunities". He felt the need to bring the change in the community around him and then branch out to provide the same opportunities wherever possible, which lead him to join GitHub as a community manager. He also knew that he wanted it, but at the same time, he could contribute to the role and make the existing program even better.

What advice would you give looking back at your journey, would you give to students exploring the DevRel field as a career option.

Work on your communications skills.

Communicating effectively, correctly and making sure that you are able to express yourself will always pay off in some way or another in future. DevRels, CMGRs, PMs --- are all expected to write & communicate a lot. If you aren't the best at it, start early! Start writing blogs, there are lots of platforms out there.

Yes! What an amazing insight into Juan's journey into the tech space and communities! Before the blog becomes too long to read, let's wrap this up.

Make sure you check out the first episode in the CDRS series, if you haven't already and also don't forget to check out DevRel.page, we have lots of content to get you started with your journey in exploring everything in and around Developer Relations.

Like always, Keep grinding! Keep working! And.... I'll catch you in the next one.

Adiós 👋🏻 😊

Developer Community Managers - DevRel Carousels #7

Zeus — Thu, 16 Sep 2021 13:03:12 +0000

I hope you've brought your shovels ⛏ because in today's blog we are really Digging Deeper! I have a feeling, this particular blog will get a few more eyes than the other ones out there --- why? Because of the recent increase in the need for community managers everywhere! Community managers have existed for a long long time. We humans have always lived in smaller communities or tribes if you consider the millennial era or factions. From politics to religion, sports to technology, the community is what binds people together and helps them grow as individuals supporting a larger cause.

But I am more sure you all already know all this. Let's pick up the shovel and understand one of the foundational roles in DevRel --- Developer Community Managers.

Who are developer community managers?

Developer community managers are folks who lead the growth and nurturing of their target developer community through various initiatives. They are usually experienced as developers in their field, although not necessarily, and act as a liaison between developers and the organisation. Generally, these roles are generally taken upon by community advocates who are extremely passionate about the product and the community built around it. Hence these folks often interface with the developer relations, marketing and product teams, with a multitude of responsibilities.

What is the need for a developer community manager?

For any community, there's always an initial communication gap between the experienced and the new individuals. Without a certain level of moderation and motivation, it becomes difficult for people to get accustomed to and contribute to the community. Even for experienced folks, it is necessary that someone listens to them and understands their needs and accordingly works towards facilitating that --- very similar to a job of a manager.

Ever since the COVID-19 pandemic, there has been an accelerated adoption of remote working and now the need for digital innovation has been more than ever. Every community tends to look for new ways to boost their collective spirit, now more than ever. These groups or communities of developers need guidance and more creative people to lead and understand their needs.

Especially while working remotely, developers often lose touch with other developers outside of an organisation and miss out on the work that might excite them too. Community managers make sure this doesn't happen. They are skilled individuals which often share the same skills as developers and are strikingly motivating 🔥.

Which skills are needed to make a great CM?

Being a developer community manager, one is expected to have both hard and soft skills.

Hard skills might include the focus and understanding of the goal of the community. Whether it is a tool, product or a new age technology, understanding the gist of it is generally needed. Alongside that, the ability to structure programs around community engagement are also desirable depending on the needs of the community.
Soft skills for community managers are mainly focused on the inherent ability to sense the feeling of the community alongside organisational abilities and competency in the management of time and resources.

Some of the other skills that most community managers generally have possessed include being a great mediator and having amazing great team-building skills. CMGR's are expected to assess a multitude of situations and apply feedback to any given process. It's a no-brainer that community managers are communication experts and people who possess great emotional and social intelligence. A huge part of community management is communicating effectively. Community managers are expected to be versatile, flexible and adaptable.

How CMGRs track community growth?

Metrics are one of the most debatable topics in the world of DevRel. As we move more and more into the digital world of community management, it is getting harder to track the actual growth of the community. This is because as compared to the physical interactions, the digital interaction of the community can be diversified so heavily that tracking it becomes really difficult. When it comes to metrics it's very important to understand that one can measure only the things that they manage.

Understanding the success of your community and pinpointing where that success lies can be difficult but then one of the most basic ways to measure success is by engagement and response. Having said that, there are a few metrics that generally help a CMGR get a better picture of how the community is responding to the current strategies.

Addition of new members: A direct indicator of growth and increased interest in the community/ product
Retention of existing community members: Indicator of engagement and the value community members are finding being a part of it
Daily/weekly/monthly active users (DAUs, WAUs & MAUs): A decent indicator of engagement, but generally should be considered alongside other parameters affecting the behaviour of the community
Average session length: This generally shows the interest people are taking in understanding the happenings of the community.
Net promoter score (NPS): It is a metric used in community experience programs. NPS measures the perception or loyalty people have towards the company/ product. NPS scores are measured with a single question survey and reported with a number from -100 to +100, a higher score is desirable.,
Customer effort score (CES): Customer Effort Score is a type of satisfaction survey used to measure the ease of service experience with an organization. It asks people to rate the ease of using products or services on a scale of "very difficult" or "very easy."
Percentage of user-generated content(UGC): Arguably one of the best indicators of a community's success. The more UGC, the more it shows that people are genuinely interested in contributing and are taking interest in the community.

Another point one would like to consider is understanding the "degradation point" --- a point at which in the coming years, your strategy might become irrelevant towards maintaining the relationships it currently does. This directly ties into building scalable programs or refactoring existing ones to accommodate a newer section of the community. As a community manager, one should always work on building long-lasting relationships and communities.

The 90:9:1 Rule

While structuring community programs, there's one rule that always grabs my attention. The 90:9:1 rule. This rule essentially means that

90% of the community members will never be interacting (lurkers), they're just consumers of information and make a perception about the product around the conversations that are happening around. Assume this similar to how we see reviews on online products before we buy
9% of the community members actually interact (promoters), ie. asks questions and raise issues
1% of the audience members are advocates. They answer questions, interact with people and help them explore your product.

Targeting these members is very different in general. We need to have specific strategies for everyone here. Each section of the community has different requirements and it is necessary to understand their needs before making any decision that affects them.

Various Faces of the Community Managers

Marketing & Support

This is the most important part of community management. The marketing and support aspect of community management does not consist of forming those catchy tags in social media, but rather communicating new developments with the community effectively. Making sure they are aware of the new happenings alongside resolving their questions, forming discussions and making sure everyone is heard.

Partner and Ecosystem Development

Apart from growing the user community, community managers also care about growing the developer and contributor community for their projects. Contributor programs, especially, involving open-source projects for an enterprise, are either employed by large users of the software, or they are engineers working for companies selling the product. Maintaining advisory board memberships, user group meetings, and generally ensuring that your project remains a strategic priority for the companies investing in it is an important part of the job.

Developer Enablement

While growing a developer community, community managers are responsible for ensuring that the developers who are actually contributing to the project, can get their job done effectively, and with ease. This can be made sure by creating proper contribution guidelines and making sure it is understood by everyone involved in the community to have a flawless workflow with fewer barriers. Creating workflows around how PRs are reviewed is also a great way to ensure the contributions are taken seriously, encouraging the community members in their efforts.

Product and Release Management

There are a lot of variables and teams involved in releasing a complete product, especially in the open-source world. A community manager is ideally positioned to mediate the internal conflicts that can cause hindrance in delay or disruption of an efficient workflow. Community managers usually tackle this by presenting a roadmap that includes all types of teams involved with the project. Communication is key. 🔑

Product Strategy

Strategy is everything when it comes to determining the success of the community or product in general. Understanding the community needs and communicating them effectively with the concerned teams to make a clear pathway to achieve those are some of the many responsibilities of developer community managers. This becomes especially important in companies that have an intersection of community and enterprise products. Making the case of prioritising the community while ensuring the customers are happy is one of the trickiest situations faced by community managers.

To sum it all up, developer community managers can't be easily defined based on their needs --- hard or soft skills. It's so much more than that. At the core, it's all about effective communication and having a clear thought process to understand the priorities, rather than the specificities. Developer community managers usually are developers at some point too, although not necessarily, they definitely share the same passion and motivation --- to make the product better, to make the community thrive, to help everyone involved.

Like always, don't forget to get your shovels ⛏ for the next and final blog in our Digging Deeper series.

Tschüss 👋🏼😊

Originally published at https://www.linkedin.com.

The Campus DevRel Show 🔥 - Episode 1

Zeus — Wed, 01 Sep 2021 15:45:50 +0000

Okay, first things first! Before we dive into the first episode let's first try to understand what the term "DevRel" stands for, along with understanding what this show is all about!

Now, #DevRel stands for Developer Relations, this field has a massive spectrum per-say, for the roles involved, for the tasks to be carried out, it is something that can take various forms depending on the company and their goals. But, the one thing that you blindly trust on --- developer relations is a job for folks who understand developers, who are inherently developers and can easily interact with the developer audience with the aim of catering to their needs and empowering them. That sum-up is a very small portion of it. If you want to take a deep dive into this field, understand what it is all about, make sure you check out DevRel.Page, a resource for Developer Relations beginners, managed by Zeus (me!) and Yash (who is also the host of the show 😄)!

Coming back to our show, let's understand why the show was started in the first place or even better, what made us, at DevRel.Page, come up with the idea.

For our host, it was interactions with #DevRel folks is what helped him to get a better understanding of the field. Once he got into the field, he saw the students having the same confusion about this field --- "What is this field all about?", "Should I get into this field?", "Will this be a perfect career choice?". So, his goal was to redefine that journey, that interaction, that pathway of approaching DevRel for student community leaders, demystifying the myths and vagueness around it. He wanted to help student community leaders find a space within the world of software development.The aim was to not just cover the questions or a topic of DevRel, it was to share the journey of the speaker which in many cases is the main motivating factor for anyone looking to be involved. Hence, with the help of amazing folks at GitHub Education, "The Campus DevRel Show 🔥" was born!

Without wasting any more time! Let's dive right into the first episode of The Campus DevRel Show hosted by Yash, with guest speaker Jonathan Gottfried(Jon)!

Jon's Story

Jon is the co-founder of Major League Hacking, who has a very unique journey, where he transitioned from being a history graduate to finding his own place in the software development field. He was always fascinated with computers right from a young age. Interestingly, while he did get into college as a part of the computer science program,he soon realized that his interest lied in building things, writing code and not particularly in research and academic side of computer science.Hence, he switched to history to make his academic life more fun, to get involved with teaching kids. But, he never left the tech side of things either, he was always able to find that balance.

How did Jon go from aiming to be a history high school teacher to becoming a developer and eventually getting into developer relations??

During a semester break, Jon was back at his home in suburban New York, when he decided to look for jobs on craigslist (not the usual goto!). He found a tech startup hiring for PHP developers, just a few blocks away from his home. It was the first startup he interacted with and played a huge part for him to get a huge chunk of knowledge. He liked that the environment was really interactive and noticing that there are folks out there passionate about building practical things with the help of technology was an eye-opener for him. According to him, his first ever hackathon was "Music Hack Day '', organized by his co-worker which was a life changing experience for him.

Community building and evangelism was something that Jon was always interested in. He grew up going to summer camp and being super involved in it. He liked being involved in building communities and experiences for people. This is one of the reasons he says he wanted to be a teacher in the first place! At the Music Hack Day he met folks from a company whom he later pitched for being a part-time developer evangelist, inspired by folks themselves and how they helped organize hackathons and would live code --- building apps and projects. Here comes the fun part, the very first event he went as an developer evangelist was also where he found his co-founder Swift of MLH! He then later joined Twilio as a developer evangelist after graduating, which shaped his further understanding of the field..

Jon believes it was a lot of luck along with hard-work that played out for him. He doesn't associate himself being an innovator in developer evangelism, but rather someone who got into it by observing the people around him.

I just happened to be at the right place at the right time and meet amazing people.

Working for two years at Twilio, what did Jon learn about developer relations and what made him take a deep dive into this field?

One of the first things that Jon said was "Well.. It was my job right" 😂.

For the record, Jon joined Twilio while in college. He worked with them for six to nine months while graduating and then two years after that. His understanding of DevRel when he just started working for Twilio was to show up at hackathons, do a really cool demo and support developers throughout the weekend. While working there, he realised there was much more than that going in that background, and a lot of it was about figuring it out as he moved forward. He worked with a fantastic manager, amazing co-workers and everyone around him were creatives from non traditional computer science backgrounds. Jon mentioned they would come up with these wild ideas which his team thought would be really cool and that was the real magic of it. As a company their strategy was to build something that developers love, which also inspires them to use it! He did mention numbers, and that someone had to keep in mind on getting "X number of users", but Jon was focused on making something that would make developers super excited. A lot of things their team did involved trial and error.

Jon made one of the first screencasts that Twilio had on their YouTube. At that time it was cool, they didn't invent the screencast, but they were on the path to understand what the developers would like. Jon reflected back to his time at Twilio and mentioned that a huge part of discovery of what developers would like included reflecting on what he would like as a developer and building up his trust for the organization.

The story of founding MLH

Jon and Swift, both developer evangelists, became close friends, going to multiple events together, speaking at and building community meet-ups in New York. They did multiple collaborations together and ended up spending a lot of time together. The interesting part is that, one of the most frequent places they met was at student hackathons, which was still a growing thing at that time. There were a few other organizations which had just started, and they as developer evangelists were early sponsors for most of the events. Both had been working on various things together, a couple of small ideas here and there, which made them agree that they want to work together eventually. So, basically they found co-founders before they came up with an idea for a startup.

Swift then left his job and Jon still continued with his, but it was during this six months of time, when a mutual friend of theirs gave them an idea to unite all of these student hackathons together.

Fun Fact: Jon had register the domain for MLH years before they for a completely different idea 🤯

Swift then spent the next six months building a community around student hackathons which laid the foundation of MLH.

What exactly do companies look for in student communities?

Jon mentioned that the companies' goals have changed from the time they had started. At first when MLH was just getting started, most of their sponsors were personal friends of theirs. As MLH grew it changed a lot as now they had to focus on making sure it was mutually beneficial for companies along with student communities. They figured out most of the things as they went along. For Jon, he was experienced in selling sponsorships so he managed that part of MLH, and Swift became the CEO, being an incredible leader that he is and also a huge part of MLH started by Swift by himself during the first couple months. Connections and relationships play a huge part in developer relations as a huge chunk of it is about creating meaningful relations.

What does John think is the best part about working in Developer Relations?

When you do something to help someone, just as a nice thing to do, and years later they come back and you realize how impactful it has been.

When you are into developer relations there are hundreds of interactions that you carry out as your day-to-day job. The interaction might just be a casual one for a DevRel, but that for the other person can be really impactful. That's one of the best parts about this job --- impacting people in a positive way and being able to scale that impact.

What is Jon's advice for undergrads getting into DevRel space?

"Start with becoming a community organizer" --- Jon

Attend conferences, organise hackathons, or volunteer under organisations who do the same, basically to gain the initial experience that you can showcase both, the community and the engineering side of things when you apply for a job. A little bit of experience on the marketing --- blogs, videos, speaking helps too. When Jon worked at Twilio and his team would look for developer relations roles, they would often look for full-time engineers who did part-time community work because they enjoyed it. So they would approach them and basically ask them to do what they enjoyed doing, but full time!

What exciting things companies are doing for student communities right now?

"Dev.to does really cool stuff" --- when it comes to folks getting started with writing about tech, Dev provides an accessible platform for doing so. Jon was personally excited about Battlesnake and their unique way of exercising creativity.

Jon's takeaway for DevRel metrics

It is an interesting question because I'm not sure that DevRel struggles to measure success or struggles to determine what their success metrics are.

That ^ is so true, and what Jon means is that DevRel teams have so many metrics, but fail to agree on which metric is more important for measuring their success. Which category DevRel fits into is still a very debate-able question. Most would say that it depends on the company and their goals, and which team you fit in, helps in determining what your success metric will be.

The companies that have been most successful have had a mix of belief in the strategy and metrics. One has to be willing to take creative risks while proving that they're doing something valuable, because otherwise it's hard to justify spending money on the team.

That was literally a lot of info to get started. Make sure you take your own time to understand every piece of information to pave your path towards becoming a DevRel🤞🏻. Always remember, "It's not a race, It's a process."\
This wraps the first ever blog for The Campus DevRel Show 🔥.

Do you think reading this made your pathway to #DevRel a little clear? Or Is it still a little blurry?

You can always check out devrel.page to get started with understanding #DevRel.

Blurry or crystal clear, we have 11 more blogs from 11 more episodes lined up to make your journey, your pathway, smoother.

Catch you in the next one! 😊👋🏼

Developer Marketers - DevRel Carousels #6

Zeus — Sat, 28 Aug 2021 15:16:01 +0000

It's been almost a year since the last blog on DevRel.Page's Digging Deeper series. Before I even start you might notice a new face below the blog!

So, hey! 😄👋🏼, this is Zeus (not the original one --- I wish tho⚡️), current Community Education Coordinator for DevRel.Page, you definitely are going to see my face pop up on our Twitter, Medium and especially on Scribbles! Now that my introduction is sorted, let's actually get back to the blog and start "digging deeper" into the DevRel Carousels!

For the series of Carousels, we'll be publishing every week from now on, Yash and I sat down together and came up with top points about each and every topic on how best we can convey it to the beginners of DevRel. We have created a decent content calendar and we will be writing together a ton of different content pieces for you moving ahead!

For this week, we're focusing on Developer Marketers, one of the less-known roles of DevRel. People often misunderstand the role of Developer Marketers, as just usually marketing, that is capturing the attention of the target audience. Well, a minimal part of it might be true, but not even near to their actual role. Developer marketing involves a lot more dynamics, as here the target audience is developers, who usually/easily sniff out marketing jargon and superfluous messaging, leading to negative connotations and distrust of the brand or claims.

So who are developer marketers?

The easiest way to explain this would be by explaining developer marketing, which is a form of marketing intended to target and capture software developers' attention, and the ones who do this type of marketing are called Developer Marketers. It's clear that their role is to capture the attention of developers, to make them interested in trying out the products. Developer Marketers grow awareness, adoption and advocacy of software tools, solutions, and SaaS platforms, focusing on developers.

Developer Marketing is a process of its own and can vary from one company to another. But at the core, it's about reaching developer communities to participate in constructive conversation and adding value as colleagues. It's about solving real-world problems by providing solutions to help developers with their tech stack, which improves the workflow and increases development efficiency. At the same time, dev marketing also helps in creating developer advocacy as they empower and evangelise developers to champion the target product within their professional and personal networks.

Now, this can also lead to a question, as to why just developers, why not go target product managers instead?

Although, in a typical organisational hierarchy, it is generally the product and engineering managers who make the decision of investing in a particular product or technology, they are not the end-users.

Developers have a huge product influence. \
Being the end-users, it is actually the developers who know about such products beforehand. They always prefer to test out various tools and decide which works better. These people are enthusiasts, they go to hackathons just to try new stuff!

But... There's a catch.

One of the mistakes traditional marketers make when engaging with developers is not fully realizing that the developers are only a piece in a larger structure. Messaging for a developer should not be focused on a procurement or product leader or vice versa. The messaging approach is the key 🔑 --- a developer marketer's approach is around making developers excited about trying things out, not purchasing them. Once the first step is taken, they'll themselves sell the idea to their managers.

Developer Marketing isn't traditional marketing

One of the main things to understand is that Developer Marketing isn't traditional marketing.

To better understand why we can't approach developers using traditional marketing, pointing out the most common hurdles that every developer relations team --- Developers HATE Marketing.

Developers are usually more technical than the rest of consumer leads, so they often are on the lookout for marketing language and unnecessary messaging, which can lead to un-favourable connotations and scepticism of the brand or promises.

Developer Marketers speak WITH Devs, not AT them.

Like we mentioned at the start, Developers sniff out marketing jargon and superfluous messaging, leading to negative connotations and distrust of your brand or claims, which makes it crucial for developer marketers to plan their approach.

This seems a bit confusing at first, but the more you read it the more it starts to make sense. The "marketing" in developer marketing steals the essence of it all, because here "marketers" build and optimize existing programs to help reframe products from the perspective of a target developer's need. They don't literally "market" to developers, rather, create developer relationships, support product adoption, and partner with developer influencers and communities to work towards common goals.

Way developer marketers engage with developers

Now there can be a plethora of ways that can vary according to the situation but let's try to list a basic process of how they figure out the way.

Figuring out the Developer Personas

*Personas*represent the goals and behaviours of a hypothesized group of users. They provide a composite view of a larger audience and allow to make that audience a part of the product's narrative. For non-developers in developer marketing, or just for those non-developers who are part of a larger team in general, personas help developer marketers to understand the audience with much ease.

" In most cases, personas are synthesized from data collected from interviews with users...They are captured in 1--2-page descriptions that include behavior patterns, goals, skills, attitudes, and the environment, with a few fictional personal details to make the persona a realistic character" --- Developer Marketing and Relations: The Essential Guide.

Messaging to Developers is actually the essence of Developer Relations. Literally, this whole field is centred around the strategies of figuring out the messaging. For Developer Marketers, this has a lot of elements to it, ranging from the collection of relevant data, testing, personalisation for advanced targeting and increased adoption to the first "welcome nurture". If the strategy works, they get a positive response from the developer, this eventually leads to a clear path for developer-targeted for newsletters, blogs, social media, content marketing and what not!

Brand Positioning or Repositioning as wherever the brand stands right now, one obviously aims to take it a notch higher.

This is like the title of some book --- contains just the title and you have the whole book to fill in. Brand Positioning can contain various tasks focusing on developer engagement and increasing it.

Developer engagements can further have a plethora of things inside them from providing online content, in-person engagements, free education about the products --- various use cases, creating a community... --- you get the book reference right?

Brand positioning is a program of its own and how an organisation wants to position their brand and what strategies they apply, it's totally up to them. However, the focus of a Developer Marketer dealing with this is always towards highlighting the inner essence the developer experiences with the brand, generating a sense of trust and belongingness for the community.

In all, Developer marketers are responsible for creating a developer marketing strategy, building a model of developer segmentation and personas. The approach and target of the product might change the various responsibilities they take, but usually, things like social media and content marketing, email campaigns, blogs, hosting events & conferences, establishing developer rewards and early access programs are among a few other responsibilities that you might see them contributing to on any given day.

I hope that this blog might have helped you dig a little deeper into understanding Developer Marketers and what they do. Make sure you follow DevRel.Page's Twitter and check out our website to stay up to date with digging deeper series!

We took a reference from multiple blogs online plus one of the best resources out there, ie. Developer Marketing -The Essential Guide. If you want to explore more about Developer Marketing strategies used by different folks around the world, we'd definitely recommend you to check that out!

Don't forget to bring your shovel ⛏ for the next blog in our Digging Deeper series.
Chao!~ 😊👋🏼

Developer Relations + Product - DevRelCarousels #5

Yashovardhan Agrawal — Tue, 18 Aug 2020 09:05:34 +0000

This particular carousel took me a bit more time than I thought it would, considering there's not much content available around the DevRel involvement in Product. Most of the articles available were around the best practices on both sides to work better together. But as a role, not a lot of people have tried to define something like this one.

After going through various of those best practices, talking to my friends involved in this role, and even reading a few job descriptions , I formulated some content for what I think DevRel Product Engineers actually do and what enables them to think about both DevRel & Product simultaneously.

DevRels are considered to focus more on the customer or the developer end of the product. Their role is largely to involve developers, make and grow the community and see if the usability and the experience are up to the mark or not. They're not directly involved in product decisions. On the product side, their job is more of conveying the feedback and let the product teams make decisions for the most part.

This is where the company needs a person who gets the DevRel as well as the Product teams. As DevRels get experienced, their grasp on the product becomes much resonant with what the community wants. This makes them the perfect choice for a person who can understand the DevRel team's point and work with the Product team to strategize the roadmap.

There are a lot of points one can make on this. Specifically, product thinking is an aspect one learns over time with the experience of being involved in its development. Be it a developer, a designer, an architect, we see product managers from every field. But, the added advantage of being a DevRel transitioning into Product is much more than that for a person from any other field.

A DevRel's whole experience shapes them into a person who understands the product and also the market for it - the ideal PM role candidate! Not just that, most of the DevRel jobs are also PM jobs themselves. Be it a Program Manager or a Community Manager; they're managing a program or a community, which in many terms is extremely similar to how a Product Manager will handle their product.

The primary job of a product manager is to understand the needs of the market and accordingly decide the best roadmap of the product and the features one needs to focus/ build upon. This is greatly achieved by their interaction with consumers and the community, though the focus is on paying consumers generally.

DevRels, on the other hand, spend a ton of time just interacting with the community. Their job is to ensure every community member is good to go with the product and their issues are being addressed properly. Through their engagements in events, hackathons, and workshops, they get high amounts of raw and unfiltered opinions of developers in the real world. This helps them detect the beliefs and opinions of the community and uncover the ideas that might not emerge in formal product team-led interviews.

DevRels are generally the first people to know if a new release or a company decision has got the right response within the community or not. Oftentimes than not, you can see a DevRel predicting the reception correctly much before the actual release. This is because their thoughts become resonant with the community. This helps the DevRel Product Engineers a lot in the general planning of the product roadmap, knowing what feature needs to be focused on and in what direction.

It's obvious that DevRels are community-focused, and their thinking reflects the thoughts of the community. As the company grows, they become the only source of on-field developer insight, which is generally missed by the Product team. Hence their involvement encourages the product direction to be a lot community-focused than it would be otherwise. Also, having insights into the product team's thinking, DevRel Product Managers will be driving the developer discovery process, which makes the product team know comments about their current thinking and the way to move from there. They also empower the product teams to speak at company-hosted meetups. Having updates about the product direction is a huge topic of interest to a community.

Documentation, online forums, community platforms, tutorials, workshops, meetups, hackathons, etc. There are a lot of things a DevRel takes into account while building the experience for every developer, be it a learner or an experienced developer.

DevRels collect a lot of data to know which specific developer they need to target and in what way their involvement will benefit the community. Similarly, product teams collect data to analyze the SDK usage, adoption of APIs and features, etc. When shared between the two teams, these sets of data can help create projects that can showcase the power of the product and add product value in the direction of what the community expects it to.

Any team depends a lot on numbers. Be it the engagement rate, usage data, crash analytics, every team has its own metrics on judging what is going well and where there's a scope of improvement. Numbers are always the key success metric for any product, project, or decision to be rated successful or otherwise.

But, generally, the numbers can vary a lot, and the real narrative behind them actually stands out to be the defining aspect of it. Having 100k followers with a 1% engagement rate and having 1000 followers with a 100% engagement rate differs extremely, though the numbers on both sides are 1000.

A product team also needs to justify their time spent with engineers, designers, and all people who directly depend on them for the direction. DevRels, being in touch with the community, generally knows the narrative well and comes very handy in these situations. Understanding the market and domain is one of the key parts of any product decision. A lot of companies have dedicated Business Analyst roles for this as well.

As mentioned, both DevRel and product teams aim to understand the developer perspective at a deep level. While the Product's perspective is more structured in user research and the dedicated product interviews, DevRel's perspective is very personal to the community. It comes from the various conversations they have within events.

The insights of both of these teams are stronger than either team alone. DevRel Product Engineers are the key in connecting both of these teams, being the source of information on either side!

Developer Evangelists 🚀 - DevRelCarousels #4

Yashovardhan Agrawal — Sat, 18 Jul 2020 15:19:37 +0000

This week, I wanted to dig deeper into the world of Developer Evangelists, one of the most important people in any tech company, with a focus on making developers aware of the platform.
As for any role in DevRel, their role is highly confused with a lot of others. A DevRel role always changes according to the company's needs and market fit. But, this is true for most unconventional or new jobs that get created due to a new development in the ecosystem. The Business to Developer (or B2D) market is fairly new, and DevRel, the key people in making it successful, must work in all pathways. They are the reason behind this ecosystem being much more inclusive, strong, and rewarding for everyone involved!
For the sake of this series, I've focused on an ideal Developer Evangelist job, shying away from the extra things they might need to handle alongside.

As the title suggests, let's clarify this in the beginning - Developer Advocacy and Evangelism are not the same thing.
People always argue that if you're in the field of DevRel, largely you're doing the same thing - i.e., talking to the developers. But they do not realise, as the B2D sector grew, the job role of DevRel expanded. This eventually led to all the different sectors, where the focus is on one aspect, and the knowledge of others adds to it.
The difference between Developer Advocacy and Evangelism is the same as between a Frontend Developer & a Backend one, a DevOps Engineer & a Cloud Engineer, a COO & a CMO!

A better way to portray this is, of course, imagining Developer Advocates as the ears and Developer Evangelists as the voice of a company's product.

Talking about a voice, a mic always comes into the picture. Developer Evangelists can be easily imagined as that person with a mic. Their ability to share information accurately and precisely is what makes them suitable for this job. Giving hundreds of talks in a year, Developer Evangelists are conservationists.
Being people whom developers tend to listen to, they are not just the mediators between a company and the outside developers using the product; they even help translate the product side to the internal technical team.

Developers are extremely loyal to products and technologies once they are happy while using them. Rarely we find a developer who might be cool with jumping from Ruby to Python to JavaScript to Go to some other programming language and in between Mac, Linux, or Windows.
It is someone they listen to who can make a difference here. Developer Evangelists are those people. They have to experiment with whatever's going in the market and let the extended community know about it. A curious engineer will always ask questions like "Why?", "What if," "How can this feature be improved?", "How does this work under the hood?" - a Developer Evangelist should have an answer to that.

It's not necessary for them to be a specialist initially or to have a successful coding background. Still, while evangelising a particular technology, they need to be specialists speaking the specifics, addressing the pain points/specialties, and talking with developers in their language.
Just imagine an Evangelist promoting a cloud technology who does not know how Serverless works. It would be a nightmare for them to tell developers how to use it. Though no one expects them to know everything, people expect them to speak the language of a developer who will be using it regularly.

Developers are free to choose between products and tools. If the competition has a better product for a use case and the developers reach out to ask which one is better, a developer evangelist should admit the case. If not, they'll be behaving like a traditional marketeer, which would ruin the developers' trust.
While this might sound like a defeat for the evangelist, in reality, this has a huge impact on the community. Developers understand that the company accepts that they cannot be good at everything, and their focus is on improving the product and not just selling it. Developers appreciate evangelists as people who understand good technology. This can also be a great way of market research, where developers themselves will tell about the competitor product making it nice feedback for the product team.

The best source of outward communication by a developer product is their documentation. Developer Evangelists also make sure that the documentation is at par. For a developer-focused product, documentation is one of the most important reasons for being adopted by fellow developers.
Not just that, they act as a steward of open-source projects that the company starts or sponsors, including performing code reviews, contributing code to the project, writing public, open-source libraries to wrap APIs for the company's products, or even helping to integrate those into existing open source projects that might make use of them.
Additionally, they are directly in contact with the PR and Marketing teams to help them understand the importance of the projects and the role that open-source plays within them.

I once read someone consider Developer Evangelism as a job of speaking at conferences, meetups, or hackathons - using companies' money to go around and have fun attending them.
While attending events is a major part of their job, the above statement cannot be farther from the truth. No company will ever spend money unless they see results out of it. It might look just traveling on the top, but engaging hackers is one of the major tasks - showcasing the impact one makes here is the ultimate goal.
The times of COVID19 have clearly showcased the impact Developer Evangelists make. Every week we're seeing some great ways of making an impact making sure that the community stays together and grows together, even in the tough times.

It's not about a company; it's always the product that matters.
The ideas, the focus, the way of representation - it all depends on how it will impact the product and how it will impact the developer community!

Developer Advocates 🥑 — DevRelCarousels #3

Yashovardhan Agrawal — Mon, 25 May 2020 21:04:32 +0000

Three weeks ago, I started this series called DevRelCarousels. The major inspiration for this was the lack of structured knowledge about Developer Relations (DevRel). Although being a vast field with companies investing in them heavily, DevRel remains a very ‘hard to get into’ field with people just knowing it over the top, even in the presence of some great articles by the awesome folks in the profession.

If I talk about becoming a Developer, getting into DevOps, or just writing code, it’s much easier to get a gist of the job role in a well-structured way. This is because these are rather popular fields in the market. But being a fairly new segment of both Development and Marketing, with rather unconventional ways of being in the job role, DevRel is highly misinterpreted.

Hence, I thought of starting this as just a small way of giving beginners an overview about what to expect in DevRel and continuing further, how even to approach it. I won’t say that this is the best structured way of interpreting it because this is my perspective and what I’ve learned over the course of two years, reading different articles, books and talking to people about approaching DevRel as a career choice.

Continuing this series further with this week’s topic — Developer Advocates. This week, I’m accompanying this blog alongside the carousels for the reader to get a further explanation about each slide, which was major feedback I got while rolling out the initial carousels. So starting here, let’s dig deeper into Developer Advocacy.

Developer advocates are the voice of the developers.

As mentioned in the slide, it's an integral part of their job to address all the queries properly. If a developer is facing any problem, they’ll always be there for them. Their position is such that developers willingly share their feedback and their knowledge about the product. There’s something about them that makes them stand out in a community of developers.

Developer Advocates are a respected & welcoming part of the developer community.

Be it any tech conference, if the community needs it, a developer advocate will be there for them. Even in a sponsored conference of a competitor company, there’s a high chance you will find a developer advocate. Why? Because the community needs their input, their point of view and expects them to be honest about it, even if it’s not their company’s own product. This makes them special and unique from any traditional marketing-based role!

Developer Advocates are great stalkers 😉

Well, not in a bad or creepy way, of course. They have to remain up to date with the achievements and the ongoings within the community. Any question or need — a developer advocate needs to know that. Using any of the mediums available, they closely follow sites like DEV, StackOverflow, read tech forums, blogs, etc., to gather as much information as possible on how the community is reacting towards the product.

Developer Advocates are the first people to try out a new developer product.

Being an advocate, one needs to put themselves into the developers' shoes they’re advocating for. They must know the insides of the product or the platform they’re are advocating for.
Having said that, developer advocates generally have a decent knowledge of other platforms, even those made by their competitors! Seems a bit out of place, right? But if you think about it, it’s pretty obvious. The developers choose to use different products and tools to build their apps — A Developer Advocate knows that!

Developer Advocates are active participants in the product development and planning meetings.

While planning a product, a company needs various perspectives. Feedback becomes a crucial driver here. Getting a varied perspective not only adds additional things to discuss and revamp upon, it also redefines the whole strategy of moving forward. Developer advocates step in here, making sure that the issues in the product which result in bugs or the difficulties of using it are brought to attention and are prioritized accordingly.

Developer Advocates are the top advocates of Open Source

As obvious as it sounds, open source is where developers reside. It acts as a safe space for any product developers, making sure the dominance and exploitation by a single large corporation in the market are not affecting the whole community of developers and the market that revolve around them.
This takes us to look at an interesting perspective. The influence of developer advocates within an organisation is that even companies like Microsoft ultimately understood the power of Open Source and why developers are inclined towards it so heavily.

Developer Advocates are Multitaskers — ultimately, it’s a DevRel job!

As we all know now, people in DevRel are known to be multitaskers!
Developer advocacy being a DevRel role at the end of the day, has to involve being a multitasker. They can always be found giving talks at hackathons, meetups, or conferences, assisting their part in writing important documentation, building technical demos for the team’s presentation — even when it’s not the core and only aspect of their role.

Tl;DR

Developer Advocacy changes the definition with every company and its corresponding needs. Adding different flavours into it, some are also called Program Managers, Community Advocates, or whatever else that suits the company's requirements. But one thing is for sure,

Developer Advocates are the facilitators of the developer community into a company — as much as they’re the pathway of a company within a developer community.