Building High Impact Developer Communities
A GUIDE TO GROWING DEVELOPER ECOSYSTEMS
I’ve spent the past 10 years of my life building developer communities in some capacity. From meetups, to coding schools, to conferences, and from FAANG, to blockchain protocols, to DAOs, I’ve learned a lot of valuable lessons from my failures and successes along the way.
Due to the flywheel of network effects, strong developer communities are one of the most sought after components when building out a developer-facing software company or product. In fact, network effects are one of the most important things that come to mind when understanding the value of developer communities:
Network effect - “A phenomenon whereby a product or service gains additional value as more people use it.”
In software, and particularly in open source, the value of an ecosystem continues to grow stronger and stronger as more developers build within it.
A good analogy would be a popular ingredient like Sriracha hot sauce entering the market that becomes so popular that everyone starts creating recipes based on that brand itself, using it as a core building block. A new, better hot sauce could enter the market, but everyone knows and trusts the older brand, and there are 1000’s of recipes who call it out specifically, with dishes even named after it. It is hard to compete once a brand has achieved market saturation.
We often see superior software products enter the market, while remaining unable to gain market share in their category due to the fact that they have no interoperability with everything else that has been integrated with an older, and what could be considered inferior, product – but one with a larger and more mature developer ecosystem
One of my favorite things to point out is that the more people building in an ecosystem, the more people build in that ecosystem. So how do you bootstrap a strong and resilient ecosystem, and do it as quickly as possible?
This is what this post is about.
To understand my perspective
I think it’s worth understanding my own story and background of how I got into the industry. Or, we can just jump to the main points.
One of the most popular tweets I have ever made was outlining my own personal journey as a developer:
This tweet resonated with a lot of people because it showed how late I started programming, the fact that I did not have a formal education, and that I was not ashamed of either of those things.
The main takeaway I like to point out from my experience getting my foot in the door is that I am self taught, but that I owe all of what I know to people who came before me that I label bridge builders.
A talk that had probably the most impact on me in my life was a keynote titled Building Bridges by Aaron Frost at NG Vegas 2015.
In this talk Aaron cemented powerful values that had already been living in my head for sometime — that many of us are here, living happy and succesful lives, due only to the fact that there have been countless people that have helped us out along the way.
This poem in particular touched me a lot:
The Bridge Builder
An old man going a lone highway,
Came, at the evening cold and gray,
To a chasm vast and deep and wide.
Through which was flowing a sullen tide
The old man crossed in the twilight dim,
The sullen stream had no fear for him;
But he turned when safe on the other side
And built a bridge to span the tide.
“Old man,” said a fellow pilgrim near,
“You are wasting your strength with building here;
Your journey will end with the ending day,
You never again will pass this way;
You’ve crossed the chasm, deep and wide,
Why build this bridge at evening tide?”
The builder lifted his old gray head;
“Good friend, in the path I have come,” he said,
“There followed after me to-day
A youth whose feet must pass this way.
This chasm that has been as naught to me
To that fair-haired youth may a pitfall be;
He, too, must cross in the twilight dim;
Good friend, I am building this bridge for him!”
For most my life I had rarely been able to give anything back as I myself was still figuring things out for myself. But as I found myself gaining some tiny traction in the software industry, I became deeply compelled to start doing everything I could to give back in any way I could.
As a self-taught developer, I also felt so much gratitude to those who came before me that I became enthusiastic and almost obsessed with passing on anything and everything that I picked up that helped me along the way in the hope that it would also help those who came after me.
Building bridges as a developer
I realized that as a developer, there are many ways you can be a bridge builder:
Teaching / speaking at meetups and conferences
Answering questions on stack overflow
Mentoring new developers
Open sourcing your work
Blogging / videos about what you’ve learned
Building communities focused on public goods
Sharing ideas and opportunities on social media
The goal being to genuinely help those who come after you to achieve what you have achieved and more.
Some of the ways that I built bridges in my career:
Created first MS coding meetup meetup 2014
Created first MS coding school in 2014 (failed)
#1 on Stack Overflow for React Native
Built and open sourced React Native Elements
15,000,000 views on technical blog
Founded Developer DAO
Bridges to networks
Something I did not realize was happening early on during this time was how valuable the networks I began organically building were becoming.
As you make this part of your day to day, you often lose track of how many people you’ve helped in some way. Often people will find your blog posts or video,s use it to kick start a company or land a job. Every time you help someone become succesful, they remember and hold on to that experience.
Over time you build out an enormous network. If you’ve done things right, people also begin to gain trust in you — or at least trust that you’re being honest and straightforward even when you are wrong.
During my career, moving from engineering, to running my own company, to participating in DevRel at scale, what I came to realize was this:
The most important component of building high impact developer communities is Building Bridges.
Framework for Developer Impact
FOR THE INDIVIDUAL
Before we get into building communities, let’s first start with the individual. To make this simple, I created a visual hierarchy that to me can be a framework to aspire to as an individual working to build a great developer community.
While I believe starting from the bottom and going up is a good approach, there are always hacks that enable higher impact while skipping some of the in-between.
Framework for Developer Impact
FOR THE COMPANY // TEAM // PRODUCT
While I have had experience in the past year taking part in building a shared community with Developer DAO, most of my experience comes from building communities around software ecosystems and products, so that is really the main focus of this post and the following framework.
1. Build something useful
This should be obvious (but obviously isn’t), but you first need to have something that people want.
Instead of trying to build a community around something mediocre or worse, you should go back to the drawing board and experiment more.
2. Have amazing docs
Once you have a quality product, your documentation will be the main entrypoint to your developer ecosystem. If you’re lucky enough to get developers to notice you, you absolutely have to give them the best shot possible at being successful by having pristine docs.
It’s unreal how many times I’ve seen multi-million dollar companies spend countless hours (and large amounts of money) to build an incredible piece of software, while having documentation that loses 99% of the developers who try and use it for the first time.
Your developer docs should have a no-brainer quick-start guide that makes no assumptions and gets developers from zero to one, preferably all in a single page without needing to navigate anywhere.
Giving new developers this mental win and quality first impression is unbelievably important, and should be top of mind when building out your documentation.
3. Provide a place for conversations to happen.
Most teams know this at this point, but there should be a dedicated channel or platform for everyone in the community to gather, ask questions, and form relationships.
You can go beyond this and create curated community chats with the top builders within your community. A good way of going about this is creating a private Telegram group where high profile people and engineers from your team are invited along with the most active and high quality builders in your community. This gives builders the opportunity to have direct contact to answer important technical questions, but also gives them a feeling of importance as you are placing them in a special group. It is a win-win and not a heavy lift.
4. Optimize for many-to-many relationships
Once you have the foundation in place to bring developers success, it’s time to focus on building many-to-many relationships with your community.
There is only so much an individual can do to have an impact. Building a strong developer community means being active on social media, providing high quality documentation, creating tutorials and videos, collaborating with creators and builders in the ecosystem, speaking and teaching at conferences and events, … the list goes on.
Instead of trying to do all of this yourself, or with with your team (regardless of the size), find ways to incentivize community members to take on some of this responsibility.
The way this is done is by identifying and incentivizing high quality the superstars within your community.
5. Identify and incentivize your superstars.
Superstars in your community can be OSS developers, blog authors, YouTubers, speakers, teachers, succesful teams building software with your product, or trusted developers with their own large networks.
Ambassador programs have become a popular way to do this, providing builders with exclusive privileges, special Discord roles, swag, and VIP access to private events.
Beyond this, you can do things like have profile people within your team share their work and wins publicly, create private one-on-one communication channels with engineering or leadership support, or just straight up pay or hire them on a contract basis.
How to effectively identify these standout community members? You can of course do this manually, but Orbit does a pretty good job of automating this. I’ve used this in the past with some success and would recommend trying it out to identify who your most active community members and contributors are. You can also learn more about the Orbit Model of community here.
6. Optimize for scalable digital content
This idea is simple yet teams rarely truly understand how powerful it is.
If you think about the ROI for attending an event vs creating something digital that is of high value / quality, almost all events are blown completely out of the water. As you’ll see in the next section this doesn’t mean you should not prioritize some budget for IRL events, it just means you need to think about them in a different light.
Let me give you an example:
At events like ETHCC, Token2049, and ETH Denver, I witnessed over and over people who flew across the world (literally), spent thousands of dollars, and checked out of their day-to-day work only to sit on a panel or present on a stage with a crowd of 5 - 30 people.
In contrast, I’ve seen high quality educational content reach 10,000 to 100,000 people on average.
A video clip usually costs ~50x less to produce and receives ~100x as many viewers as an in person talk. This means mathematically, even if we’re scaling these numbers down, in-person events are around 500x less scalable and efficient.
Imagine sending 5-10 people to speak at most of these events, blowing through hundreds of thousands (often millions) per year, only to hit around 1% of the reach as someone sitting in front of their computer writing a tweet or recording a video.
Take this seriously. Weave it into your DNA. Make it part of your strategy. Every time a dollar is spent, ask yourself this: could this dollar be spent elsewhere to have a higher impact? When talking about events, the answer is usually yes.
7. Use IRL events to build relationships, not educate
I wrote more in depth about my event strategy here.
I still think in-person events are important, but for different reasons than I did in the past.
Outside of hackathons, use IRL events to meet and form stronger relationships with developers, founders, community members, etc… That’s literally it.
The one nuance I’d call out regarding educational events is that in-person hackathons offer an opportunity to educate as well as form relationships, and I think are valuable.
I think some realistic numbers to keep in mind might be 2 in-person hackathons per year, and an in-person event per year in each main region you are interested in (e.g. USA, Europe, APAC, Asia, etc..).
This might equal 4-7 in-person events per year for your main or DevRel team, and for everything else, it can be scaled down dramatically by sending a small handful (1-3) of high impact team members to other important events.
By taking this approach, you’ll free up resources to focus on more scalable content and educational resources.
8. Prioritize diversity
The world is a large and diverse place. We often grow up in and around environments that are bubbles of what is actually out there in the real world.
Regardless of how much we read, experience, or go out of our way to understand other people’s lived experience, we will never be able to have the perspectives of people who have lived different lived experiences.
More diversity of lived experiences results in more diverse ideas and synergies, as well as an understanding of the wants and needs of people on the other side of the screen of the products that we are building.
We should go out of our way to optimize for diversity in all aspects of our community, from gender, to sexual orientation, to geographic region, to income level, to … well everything!
From a straight up business / logical perspective, this will also create a more welcoming space, enabling a larger pool of developers to feel comfortable joining and being a part of your community.
9. Help people where they are
EVEN IF THEY ARE NOT BUILDING WITH YOUR PRODUCT.
A huge mistake many community builders make is that they make it all about themselves or about their own products.
If you want developers to listen to you, you have to build trust. It’s hard to build trust if you are constantly only shilling your own product at every opportunity.
It’s simple really. Find opportunities to be there to help developers, and actually try to help them regardless of what the solution is.
This means that if someone has a question that has nothing to do with what you do or what you are working on, do your best to help them, and point them to the proper solutions even if it means pointing them to a competitor, and if it means you never get to talk about what you are doing
10. Be transparent about tradeoffs
Another part of building trust is being just as transparent and straightforward as you can be about the negatives of your product as you are the positives.
When someone asks you about, or you have the opportunity to talk about, what you are working on, being transparent about both sides builds trust in that you are indeed telling the truth.
While these last two points might seem obvious to you, you’d be surprised at how many teams do not act in this way.
11. Contract out your weaknesses
At the time of this writing, DevRel (Developer Advocacy and Developer Relations) is among the most in demand roles that I know of in the software industry and the demand continues to grow.
A good DevRel is good at programming, communication, writing, speaking, content creation, social media, and many other things.
When hiring for Developer Relations roles its often hard to find someone who is able to do all of these things and do them well. Even if you do find the right person, most people usually have a handful of things they are naturally better at, and hiring for a handful of these specific qualities often enables you to find people who are exceptional at certain tasks.
Instead of looking for those few unicorns, consider instead hiring one high quality individual who can manage the DevRel responsibilities, then outsource the rest.
There are actually numerous benefits to this approach:
It’s less expensive. Instead of hiring someone full time, you can contract out individual tasks like creating a tutorial, video series, or OSS library.
There’s less risk. Instead of hiring someone full time and buying in with all of the things that go along with a full time employee, like benefits and such, you are on a month-to-month contract that has no obligations to continue at all if they are not performing well.
More specialization. You can hire for the exact things you need.
Better talent. Because contracting is less expensive, you can theoretically pay more to get the highest talent available. If you are paying someone $200K / year salary + benefits + etc.., this comes out to around $16,000.00 per month. This type of money opens the door to some of the highest quality talent around. If your budget is higher, you will be able to hire almost anyone, but to be honest you can bring in high quality specialists for around half of that per month on a contract basis.
If you break the above budget down and instead decide to use it to incentivize community members, it also goes quite a long way. Imagine if you decided to pay your top 15 community contributors $1,000 per month for work they were already essentially doing?
Wow, thanks for writing this Nader. Learned a ton from it.
Gotta bookmark this.
By the way, you really inspire a lot of us. Please, keep building and sharing stuff with us.👏👏👏👏🥳
Thank you for sharing this framework for community building.
Not only do you demonstrate thought leadership, Nader, but leadership in action.
Kudos!
👏