In the past week alone, I've had multiple chats with startups looking for developers who can build community.
I think this is a generational shift in how devtools startups approach their users
quick thread on why **Technical Community Builder is the hottest new job in Tech**👇
Devs have always self organized community, but in the past couple decades companies arose where the dev community is **the competitive moat**:
- @StackOverflow serves 11m community Q&A's a day
- @github sells collaboration software to 56m devs
- Hacker News has >4m daily readers
If community can be such an advantage, who's in charge of community at startups?
Often the answer is: community managers handle forums, developer evangelists do outreach, marketing handles and events and mailing list.
Can we do better? How to take risks & break down silos?
Is community at your startup an afterthought or a key input to product, marketing, and support?
@lisaxunyc and @TheTeaGuns argue that community is moving from periphery to core. People who can scale code & community are going to be extremely valuable:
Does your community builder *HAVE* to be technical?
No, of course not. But 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 recs.
The job title probably won't stay "community builder", by the way. @patio11 observed that the DevOps movement led to "a once-in-a-lifetime upgrade in status, impact, authority, and career prospect" for sysadmins:
Traditional marketing and support isn't cutting it.
A developer's journey can start long before — and continue long after — their first contact and passage through the marketing funnel:
When developers make technical choices, you are just as likely to hear them praise the strength of the "ecosystem" as the core technical merits.
**Community is how developer tools cross the chasm** from early adopters to the majority.
Everyone must solve this to get big.
Community is a hiring advantage:
It can just as easily net you employees as it does users and customers.
If hiring is your biggest problem, like 99% of founders, then investing in community is investing in hiring.
Community is a marketing advantage:
An engaged community is highest-signal social proof and word of mouth.
You can't buy it, you have to earn it over time.
Community is a competitive moat:
Community a "feature" that cannot be copied.
By the 7 Powers Framework, Community helps you
- gain Network Economies
- increase Switching Costs
- Corner one of the most precious resources on Earth: Developers!
Community is many-to-many, where Marketing/Devrel is few-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 (with viable spinoff subgroups) scales by Reed's law — even better!
Community bears risks:
You do not "own" your community. The best you can do is lead by example, encourage helpful behavior, and enforce clear codes of conduct.
"User-generated content" bears particularly great responsibility. Poor handling can backfire horrifically.
One of the best measures of community success is when your users' relationship with you **outlasts their current employment**.
Help your users get jobs, help your customers hire ideal users. Feed this cycle and your LTV goes to infinity.
Come for the tool, stay for the network!
Commercial Open Source companies must foster a viable community to be successful open source, rather than being de-facto "source available".
In terms of @nayafia's Working in Public, you might aim for Federations or Stadiums, but both are def preferable over Clubs and Toys.
Product Insights:
Speaking to users helps you build things people want, but often this is 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 rings** around one that doesn't.
Dev Community always felt fringe. I helped run a >200k developer community and always felt like a middle schooler discussing it in a professional context: "that's nice dear, but let's talk about more serious work now"
Things have shifted. A lot.
Clearly the pandemic was a forcing function:
- People were displaced from their existing IRL communities, needed a replacement
- Geography doesnt matter (modulo timezones)
- Online communities are far more discoverable (searchable, join with a URL) and scalable, than in-person
Community-building software has also gotten a lot better:
Is #LearnInPublic suitable for everyone?
What if I look dumb?
My answers below, but I'd love to hear yours too!
(DM shared w/ permission)
1/ Learning in Public is *not* “broadcasting everything”. Nobody wants that.
It is about realizing you have a choice to go from 0% to not-0% public. The stuff you do share, you will learn faster, while building a network. It’s up to you to set the boundaries of what you share.
2/ Understanding how to turn your ignorance into power is a key career skill. If you want to grow at all you must make ignorance an old friend, and make friends out of ignorance.
Lean into the discomfort. Become a professional (but responsible) ignoramus
We are besieged by todo lists: Open browser tabs, YouTube Watch Later, Podcast queue, Twitter bookmarks, unread emails, notifs, messages.
Todo lists aren't good enough.
They just solve the easy problem: storage.
Actual Hard Problems: Prioritization and Scheduling
Calendars are todo lists with prioritization and scheduling **built in**. You *have* to answer questions like: "what should I do first?" and "what's my time budget for this?"
Most people's cals only track meetings with others. But why shouldn't we make appointments w/ ourselves?
A reader asked about mental models that I learned from my finance days, that are still relevant for developers.
Here's a quick thread in no particular order, let me know what resonates or mystifies:
1. The Role of Confidence (Being a Con Man)
- People are attracted to confidence for interviews and promotions
- We aren't as objective as we think
- Jobs which traffic in confidence are prone to bullshit
- Assess each choice relative to your other options.
- For employers: be great at finding and evaluating options in ways they care about
- For your self: Accumulating options = Building wealth
- "Making past mistakes look good" is not an option
I was asked about why declarative programming is at the heart of "newer" trends in tech all the way up and down the stack, from React to Terraform.
I replied in an email but here it is as a quick thread:
DOM APIs are imperative, which encourages manual setup/teardown of event listeners, and intermingling of business and presentation logic.
At best this is just quite verbose and disorganized, at worst this creates runtime bugs and memory leaks. Lack of structure is painful.
We use React/Vue/Svelte to organize code into declarative components, help us organize the above and automate the boring parts. It also lets us *share code* much easier because the markup, state, and styles are scoped to the component, so they don't leak to the rest of the app.
We often get caught up in other people's games. Ladders, likes, follows, points. Winning can bring a short-term rush, but feel empty after. These games are traps for competitive, ambitious people.
The primary beneficiary of you being #1 on Product Hunt is Product Hunt.
The primary beneficiary of you being Employee of the Month is your Employer.
The primary beneficiary of you going viral on Twitter is Twitter.
Youre surprised *everything* around you is designed this way?
- Zero sum
- Finite game
- Single number
- Regular schedule
- Costs them nothing
- Rules clearly stated
- Winner irrelevant in 1 year
- Timing matters
- Microcopy matters
- Social proof matters