Investing in community with SJ Morris
SJ Morris' single most useful community health metric isn't size or growth — it's how often developers answer each other's questions before the company has to step in. Too much company involvement early on quietly turns a community into just another support channel.
Sarah Jane (SJ) Morris is senior manager of developer community at HubSpot, and grew her first developer community, at the email API startup Context.io, from 10 beta testers to 1,000 within a year.
We get into why feedback diversity matters more than raw feedback volume in a product's earliest days, why she thinks Slack quietly stops working as a community tool once it scales past a certain size, and why the presence — or absence — of a genuinely broad developer use case is the real predictor of whether investing in community early actually pays off.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How should an early-stage startup actually think about community before they have any kind of formal community space?
Community can feel vague and intimidating as a concept, but for developer tools specifically, it helps to get into the headspace of a developer trying to build something and ask where community genuinely helps them. In the earliest stage, before you even have an MVP nailed down, feedback is the crucial thing — there's always a group of developers excited to help improve a tool that makes their own workflow better. A developer community is really only ever going to be as good as your underlying developer experience, so the early focus should be on making onboarding as frictionless as possible while actively soliciting that feedback.
Why does feedback diversity matter so much in those earliest stages?
If you want a product with real long-term staying power, feedback needs to come from more than just your own network and friends, which tends to introduce bias into what you build. Make a deliberate effort to get input from developers at different career stages and skill levels, even while staying focused on the broad category your product serves — that diversity, built in from the start, becomes a real differentiator against the countless other dev tools competing for attention. Tools like Haxor, run by Ian Jennings, can help here directly — it records developers going through your onboarding, similar to UserTesting.com, benchmarks the experience against industry norms, and specifically helps recruit a more diverse set of developers than your own network would surface on its own.
How should a company treat that early group of feedback-givers to keep them engaged long term?
Focus on providing real value to that group before you start extracting more than you're giving. Actually act on the feedback you get — iterate visibly in response to it. Small gestures matter too: access to things like coaching sessions with founders or investors if some of them are entrepreneurs themselves, and yes, developers still genuinely appreciate swag, even if we've all got drawers full of stickers. You don't want to overly incentivize the relationship, since that can dilute the quality of the feedback, but showing genuine appreciation for their time is what keeps early developers engaged for the long run — they're the ones who will make or break your product.
Once a community moves past that initial small group — you grew from 10 to 1,000 developers in a year at Context.io — what shifts in focus?
In our case, a bit of press coverage, a TechCrunch write-up, created a traffic spike, and the real opportunity was converting a small percentage of that burst into genuine community members rather than just visitors. At that scale, around 100 people, we rolled out a forum, which made sense at the time but I'd think differently about today — forums feel outdated and are inherently asynchronous, and developers usually show up wanting an answer right now, often after they've already exhausted the docs, Google, and Stack Overflow.
What would you use instead of a traditional forum today, and why?
HubSpot has a developer Slack that made complete sense when it was first set up, but has since grown to a point where it's genuinely unsustainable as a community space — anyone in it can DM anyone else, which is a lot of unmoderated power with zero visibility for us. I'd lean toward something like Discord instead, which despite its gaming roots has much better built-in moderation tools and is increasingly used by developer communities. The trade-off is that a more instant, synchronous tool loses the SEO and long-term searchability benefit a forum naturally has, so it's important to feed recurring questions from those conversations back into your documentation and knowledge base deliberately.
How involved should the company itself be in those community conversations early on?
Early on, it makes sense to be quite involved, since you genuinely want that direct feedback from developers eager to give it. But there's a balance to strike long term — if the company always answers first, developers start treating the space as just another support channel rather than a real community, creating a dependency that undermines the whole point. As much as possible, facilitate developer-to-developer conversations and let them work through problems together — not every situation allows for that, since some issues involve private details like API keys, but a lot of the time another developer who's hit the same wall can give a faster, more relatable fix than the company can.
Community impact is notoriously hard to measure. What do you actually track?
It's genuinely difficult — this is long-term work that's hard to attach direct numbers to, but it's essential for the word-of-mouth advocacy a developer company depends on even more than a typical B2C company does. The single metric I find most indicative of long-term community health is community responsiveness — specifically, peer-to-peer response, developers answering and helping each other reach resolution, rather than the company always stepping in. Watching that number rise is a much better signal of a genuinely engaged community than raw size alone, though the right target size depends heavily on how niche your product is.
What tools do you actually use to track that kind of sentiment and engagement?
We use Common Room, which pulls in sentiment and activity across sources like Stack Overflow, GitHub, Twitter, our developer forum, and our developer Slack. A rolled-up sentiment score across all of those isn't hugely useful on its own, since comparing Twitter sentiment to GitHub sentiment isn't really apples to apples, but it's genuinely valuable for surfacing people talking about you that you'd never find through ad hoc, anecdotal community monitoring, and for measuring responsiveness — though even that gets technically fiddly, since something like Slack only counts a response if it's posted in an actual reply thread, which is why we ask people to reply in threads specifically to keep our own measurement clean.
Beyond tooling, what else do you rely on to understand a community, especially early on?
Surveys, especially in the early days or if you're inheriting an existing community of, say, 50 to 100 people. That's a great opportunity to learn where people actually spend their time — are they living on Stack Overflow, do they Google for answers, what technologies are they most interested in, what client libraries should you prioritize. You can also carefully start understanding the demographic makeup of your community to check whether your diversity efforts are actually working, which is a genuinely tricky area to do well. Project Include, an HR-focused group working on diversity in employment settings, has a lot of learnings that translate directly into community surveys and codes of conduct — codes of conduct being something I'd call absolutely crucial for any community space.
Startups often face pressure to hit short-term growth metrics, which can push community investment to the back burner. How do you think about when investing in community early is actually the right call?
Looking at Context.io and Twilio as a comparison, the common denominator in genuinely successful early community investment is a broad developer use case. Both companies solved something almost every developer might eventually run into — email interaction in our case, messaging and communication APIs for Twilio — and Twilio in particular has taken developer relations and community to an extraordinary level as a result. If your product is much more niche, serving a very specific slice of developers, investing heavily in community from day one isn't necessarily the top priority — you can only sustain genuine engagement once you have a reasonable volume of people in the space, though that doesn't need to mean a huge community by any means. The real long-term purpose of community is to act as a moat: it drives word of mouth and becomes an ongoing source of feedback, but for a hyper-niche product, it may simply not be the most urgent thing to build first.