Home
Latest
- Went from 10k MRR (Series A, ~$50m valuation) to 200m ARR (acquired, $6.5b valuation) in 6 years
- solid discussion on Software Defined Talk: https://www.softwaredefinedtalk.com/288
There's a big shift going on in how developer tools companies approach their userbase. In the past week alone, I've had 3 chats with startups that all concluded with some version of:
"By the way, we're really looking to ramp up our community effort right now. If you can think of anyone who can help us build a developer community, can you send them my way?"
One week, three pings. If this isn't a big trend already, it's at least worth writing about (per my Three Strikes rule). Who builds developer communities, why are companies investing in them, and why now?
Who's Job Is It Anyway?
Developers have had a long history of spontaneous community formation dating back to the IRC and BBSes of yore. (Misery loves company?) There is still a strong ethos of self organized community in modern dev culture, but the vast majority of this lies on the shoulders of a small group of under-funded volunteers.
But in the last couple decades, company-centric communities, where the community is almost the entire competitive moat of the company, have become a central part of developer life:
- StackOverflow serves 11m visits a day with community contributed Q&A's and sells ads and knowledge base software on the side.
- GitHub builds developer collaboration software, but at its core is a 56m-developer social network atop Git.
- Hacker News (serving at least 4m a day) is a big part of Y Combinator's unfair advantage in getting both founder mindshare and hiring talent.
You would expect that this realization would spawn a dedicated discipline to prioritize it, in the same way that Startups = Growth justifies the need for a Growth Hacker at every company serious about growth.
But as far as I can tell, it hasn't happened.
Sure, companies do hire community managers to groom their forums and post inoffensive memes (j/k of course, good community managers do much more than this). Some developer advocates may focus on community, but most developer evangelists create content and do outreach to other communities, to "meet developers where they are". Marketing folks might run the company mailing list, host webinars, or organize conferences, all mini-communities in their own right. Everyone intuitively gets the importance of community, and does their best within given boundaries.
But who's job is it to define the overall community strategy, and has the resources to develop it as aggressively as engineering? If this describes someone in your management team, great. But often the community builders are at the bottom of the totem pole.
The Venn diagram of people who can scale code and people who can scale community is going to be exceedingly valuable. You don't strictly need to be technical to run community — Ben Popper, StackOverflow's Director of Content, is still new to code — but developers can tell when they aren't talking to a technical person and that limits the depth of conversation. A technical community builder will have instincts informed by direct personal experience, and be able to empathize with member needs and make targeted recommendations.
The job title probably won't stay "community builder", by the way. Patrick McKenzie once observed that the DevOps movement led to "a once-in-a-lifetime upgrade in status, impact, authority, and career prospect" for sysadmins. I think a similar rebrand is due. As community goes from a side activity to a core driver of product, support, and marketing (great thoughts from Lisa Xu on this), the status and pay change will need a new name for people to rally behind.
What shall we call it? "Community Tummler"? "Community Developer"? Let me know if you have a better name. I've settled on "Technical Community Builder" for now, in the same way that Microsoft and Amazon have Technical Product Managers.
Why Invest in Community?
TL;DR: Traditional marketing and support isn't cutting it.
Devtools companies get that "build it and they will come" usually doesn't work. The sub-industries of technical marketing and developer relations are well developed enough now that there are books and conferences about it. We get that marketing can be just as important as product. (Let's leave the topic of "how much devrel and marketing overlap" for a future post...)
But a buyer's journey can start long before — and continue long after — their first contact and passage through the marketing funnel:
- Marketing attribution in developer tools is kayfabe — we play at tracking Twitter clickthroughs and podcast direct response, but everyone in marketing knows you need at least 7-13 touches before someone really considers you. As a developer I often wait out an entire year after hearing about something before even trying it out, just to see if it has staying power.
- After buying into a solution, I still need help to be successful with the tool. Developer tools are ultimately creative tools, and sometimes the imagination needs a little inspiration. Setup hurdles need to be overcome. If I buy something and end up not using it, it's going into the do-not-use pile for a very, very long time before I ever give it another shot.
This adoption process needs to turn from a mostly-transactional, finite game, to a relationship-based infinite game. You might envision Community as carefully designing the broader environment around the traditional sales and marketing funnel:
"Characterizing the developer journey as a linear funnel doesn’t really tell the whole story, as it’s essentially scoped to awareness and conversation — the journey is much more complex. I think onboarding to the community itself, retaining over time, and advocating for others to join, is a huge part of the journey... In this world, you want to understand how folks are engaging with the community as well as with the company/product, with product metrics (activation, adoption, etc) existing as second-order effects of the community. The Orbit Model, versus the funnel, tries to tell this nonlinear and comprehensive story."
When most developers make technical choices, you are just as likely to hear them praise the strength of the "ecosystem" (aka a community, with thriving third parties) as they do the core technical merits. In terms of the Rogers curve, this is the kind of argument made by "mainstream" developers:
Community is how developer tools cross the chasm from early adopters to the majority. Every devtools company looking to scale eventually has to figure this out, whether consciously or otherwise.
Other arguments in bullet point form, but feel free to request elaborations:
- Retention: Build product and they may not come, but build community and they will stay.
- Hiring: Community can just as easily net you employees as it does users and customers.
- Marketing: Community is highest-signal social proof/word of mouth you cannot buy.
- Moat: Community is a "feature" that cannot be copied. By Hamilton Helmer's 7 Powers Framework (the strategy framework du jour), Community helps you gain Network Economies, increase Switching Costs and Corner one of the most precious resources on Earth: Developers!.
-
Scaling: Community is many-to-many, where Marketing/Devrel is one-to-many. The value of a community-focused user base scales by Metcalfe's law instead of Sarnoff's law. A thriving third-party ecosystem scales by Reed's law — even better!
- Risks: But you also do not "own" your community - the best you can do is lead by example, encourage helpful behavior, and enforce clear codes of conduct. Community is "user-generated content", and that bears with it great responsibility. Poor handling can backfire horrifically.
- Free Work? Community members can answer questions to each other and develop integrations to help you grow beyond your limited resources. To avoid expecting members to "do free work", this effort must be reciprocated by careful stewardship.
- Lifespan: One of the best measures of community success is when your users' relationship with you outlasts their current employment. Come for the software, stay for the community. Help your users get jobs, help your customers hire your users, and you will have fans for life.
- Open Source: Commercial Open Source companies must foster a viable community to be successful open source, rather than being de-facto "source available". In Nadia Eghbal's terms, more Federations than Stadiums, but both are definitely preferable over Clubs and Toys.
- Product Insights: Speaking to users helps you build things people want, but often these conversations are done by outreach (user survey or feedback session) rather than observation (in situ, natural environment). Community is where your deepest and most authentic user insights will originate.
All in all — a devtools company that prioritizes an engaged and inclusive developer community will run circles around one that doesn't.
There are multiple ways to do this well, but I am particularly fond of community that "serves a bigger purpose". A community that is strictly centered around a company (eg Dreamforce → Salesforce) is less appealing than one with room for multiple players (eg No Code → Webflow, Jamstack → Netlify), at least while you aren't yet a decacorn. Every great community is a great marketplace (tbc in a future post...), and every marketplace is a kind of platform, and every platform must respect the Bill Gates Line with its participants.
Why Now?
Dev Community has felt fringe for as long as I've been involved. I always felt like a bit of a middle schooler talking about my /r/reactjs work to companies, like "that's nice dear, but let's talk about more serious work now". I have friends running other popular Discords and forums that feel the same way.
That's why this shift is meaningful. This thing we used to do for fun, in service to our community, is suddenly a legitimate and highly in-demand skillset.
I don't know why community building is trendy again (there have been several waves), but D'Arcy Coolican at a16z nailed the current wave with his thesis on the Power of Social+. Technical Community is the marriage of software eating the world and social eating software.
Clearly the pandemic forcing everyone online was a forcing function:
- People were displaced from their existing IRL communities and needed a replacement
- Geography doesn't matter for online community (modulo timezones)
- Online communities are far more discoverable (searchable, join with a URL) and scalable (no room limits on community!)
Community-building software has also gotten a lot better:
- Realtime: Twitch and Discord and Clubhouse
- Conferences: Hopin and Bevy
- Async: Circle (where I am an investor), Forem (the creators of Dev.to), and Hashnode
- Metrics: Orbit.love (Martin Casado writeup here) helps quantify developer engagement (Commsor is less dev centric but noteworthy)
I also think the developer relations field has reached a level of maturity where companies are feeling the limits of one-to-many content creation and hiring developer influencers, so they are exploring other ways to scale their community engagement as an enablement role.
Become a Technical Community Builder
One of the telltale signs that this field is rife with opportunity is how much cruft it lacks. There's no book or course or conference teaching you how to do this job. There's no set career path, and "Chief Community Officer" isn't really a thing. We don't even have a commonly-accepted name for this role! And we certainly lack role models and thought leaders and the rest of the paraphernalia that comes with a mature industry.
- If that excites you, rather than intimidates you, get in touch with me and I'll send you to the exciting startups hiring for this role: WorkOS, Render, Begin, and Temporal.
- If you're starting a company to help Technical Community Builders (or whatever we end up calling this), you can browse my angel network here for investment and advice.
- If you just want to keep up on this space, you can follow the DX Circle blog where we will discuss Developer Communities, Developer Tools, Documentation, and everything else Developer Experience!
nice discussion on hitting the front page of HN (michael does this fairly consistently)
Nadia Eghbal identified a 2x2 of how open source communities work in her book:
A lot of projects (like this one) end up as a Toy or Stadium. Jani Evakallio ran directly into this with the Foam project and writes about it here:
https://jevakallio.github.io/notes/foam-six-months-later
Having such loose leadership was unsustainable. His solutions are:
A lot of projects (like this one) end up as a Toy or Stadium. Jani Evakallio ran directly into this with the Foam project and writes about it here:
https://jevakallio.github.io/notes/foam-six-months-later
Having such loose leadership was unsustainable. His solutions are:
- make the project leaner - move out some unsupported features or kill them
- kill the RFC process
- clarify what contributions are welcome
- bring core features in-house
- open the Foam API for third party extensions
Really interesting article by Anders Ericsson detailing his researches about deliberate practice (in the text he calls it purposeful practice).
In his experiment a lad learned to memorize sequences of 82 random digits.
In the first weeks he could only memorize 8 (or 9 when lucky). But after using some techniques he was able to improve.
The "game changer" in the progress happened when they decided to change from "memorize as many digits as you can" to "focus on memorizing +X digits than you memorized in the last session (and don't move forward until you're comfortably memorizing this amount)". This also reminds me that thing about SMART Goals.
In his experiment a lad learned to memorize sequences of 82 random digits.
In the first weeks he could only memorize 8 (or 9 when lucky). But after using some techniques he was able to improve.
The "game changer" in the progress happened when they decided to change from "memorize as many digits as you can" to "focus on memorizing +X digits than you memorized in the last session (and don't move forward until you're comfortably memorizing this amount)". This also reminds me that thing about SMART Goals.
Here are my main takeaways:
- Once you have reached a satisfactory skill level and automated your performance, you have stopped improving.
- Generally speaking, once a person reaches that level of "acceptable" performance and automaticity, the additional years of practice don't lead to improvement (he calls it naive practice).
- Moving from naive to purposeful practice can dramatically increase performance.
- If anything, the doctor (or driver or whatever) who's been at it for 20 years is likely to be a bit worse than the one who's been doing it for only five, because these automated abilities gradually deteriorate in the absence of deliberate efforts to improve.
Anecdotal conversation
Music instructor and yong music student:
👨🏫 - Your practice sheet says that you practice an hour a day, but your playing test was only a C. Can you explain why?
🧑 - I don't know what happened! I could play the test last night!
👨🏫 - How many times did you play it?
🧑 - Ten or 20.
👨🏫 - How many times did you play it correctly?
🧑 - Umm, I dunno... Once or twice...
👨🏫 - Hmm... How did you practice it?
🧑 - I dunno. I just played it.
👨🏫 - How many times did you play it?
🧑 - Ten or 20.
👨🏫 - How many times did you play it correctly?
🧑 - Umm, I dunno... Once or twice...
👨🏫 - Hmm... How did you practice it?
🧑 - I dunno. I just played it.
Purposeful practice characteristics
Purposeful practice...
- ... has well-defined, specific goals.
- it's all about putting a bunch of babysteps together to reach a longer-term goal.
- break it down and make a plan
- ... is focused
- you seldom improve much without giving the task your full attention.
- ... involves feedback
- without feedback - either from yourself or from outside observers - you cannot figure out what you need to improve on or how close you are to achieving your goals.
- ... requires getting out of one's comfort zone
- it means tryint to do something that you couldn't do before.
- sometimes you may find it relatively easy, but sometimes you run into something that stops you cold. Finding ways around these barriers is one of the hidden keys.
- try harder != try differently
Quincy, founder of FreeCodeCamp and an original inspiration for Learning in Public, did a two parter on Developer Tea recently. I highly recommend it (as well as donating to them to help fund broader access to programming education):
https://developertea.com/episodes/238e87fa-f04b-4bb6-b2a6-802fed99a5e6
https://developertea.com/episodes/f749d957-0977-469f-8284-9cfa686b5c49
https://developertea.com/episodes/238e87fa-f04b-4bb6-b2a6-802fed99a5e6
https://developertea.com/episodes/f749d957-0977-469f-8284-9cfa686b5c49
Lets have a little more heads up time - shall we do lunch, March 13 or 14? (sat or sun)
Anyone have a place they want to seek out -
Kai
or
wasabigeek
or Josh anyone else?
Anyone have a place they want to seek out -
1. How to be a tech influencer - not the type of piece you'd think it is based on its title. The author is Will Larson, CTO of Calm, who has a healthy skepticism of influencer culture.
2. Take the boring common answers to an overdiscussed topic, and identify what else is NOT being said:
33 four ways to keep up your Consistency
From our community:
2. Take the boring common answers to an overdiscussed topic, and identify what else is NOT being said:
From our community:
-
Nanda Syahrasyad published their first blog with interactive examples! https://nan.fyi/sliding-window -
Christian von Uffel published his first tutorial on Tailwind CSS! -
wasabigeek published his GUI for Rails Generators project!
We're going to meet up for chicken rice at Katong Shopping Centre, 6.30pm on Saturday 27 Feb!
Featured guest is Thomas Gorissen who organizes JSConf Asia and does some cool crypto stuff.
Thanks for coming!It was a blast meeting up with everyone and sorry
Kai
that we didn't have space for you!
Featured guest is Thomas Gorissen who organizes JSConf Asia and does some cool crypto stuff.
Thanks for coming!It was a blast meeting up with everyone and sorry