Building a SaaS platform that 3rd party developers will love is no easy feat for startups.
Community building requires dedicated time and resources. Traditional marketing and sales tactics don’t work for developers. Customer retention can be challenging if your product is easy to rip and replace or devs can easily build it themselves.
As part of SaaS School, I interviewed Dev.to founder Ben Halpern on the evolving landscape of developer communities and best practices for software companies that sell direct to developers.
In this talk, we’ll cover:
- How to engage with existing developer communities
- Motivations and incentives that get developers excited
- What it takes to build a SaaS platform that 3rd party developers will love
- Best practices for community building and measuring success
I’m excited to be joined on stage with Ben Halpern, CEO of Dev.to, for an open discussion on how to sell direct to developers and best practices for building a developer community.
So, Ben, we have a lot of startup CEOs in the room and for most startups hiring developers is hard.
What are your thoughts on how an entrepreneur should build relationships with developers and when does it make sense to start engaging with dev communities?
Ben Halpern: 00:24
Yeah. So, in terms of developing a community, I think it’s important to pay attention to the longterm fundamentals of marketing yourself on the internet, finding your voice, developing a brand that the people can relate to and understand that’s maybe different from some of your other customers.
If you sell directly to developers, you’re probably going to have a different brand than if you need to hire developers, but also sell to someone else.
Ben Halpern: 01:00
And then I think it’s a lot about paying attention to your wins, and running with it, but then also just doing a lot of listening.
So, the question is I think a little different if you’re looking to hire, and if you’re looking to sort of develop a community.
But one of the fundamentals of any of these things is to throw away some of your preconceptions about where the best developers are.
Be pretty flexible about the interests, and needs of developers because if you have some flexibility you’re going to find some really great talent. And then ultimately, be the kind of company that developers want to work for, and they’re going to tell their friends.
Brianne Kimmel: 01:46
What’s interesting, so we’ve talked about this, or you’ve said it, as well, where oftentimes the projects and the things that get developers excited is sometimes very different from the things that maybe more CEOs or more revenue-minded founders get excited about.
Can you kind of talk about what are some things that get developers excited, and how is that potentially different from that of a startup’s business agenda?
Ben Halpern: 02:13
Developers are often excited by some things that seem less exciting.
If an interesting test automation tool hits the scene, developers get very excited, but test automation is a very boring thing.
Just automating your code before it goes up so you have better visibility into whether it’s going to break.
Because developers, the more experience they have, the more pain they’ve lived through.
And the pain in software development is sort of the most memorable part.
People I don’t think act always on their favorite memories.
They sort of want to lessen the pain. So, vitamins don’t always work for software developers. Medicine and painkillers are very appealing.
Ben Halpern: 03:06
Software developers, in some ways they’re really excited about AI, ML, a lot of the trendiest sort of cutting edge stuff.
Everyone’s a little excited about that on some scale.
Some are really excited, but everyone’s pretty excited when a really polished tool hits the market that they feel actually fits their existing workflow.
They can see how they can kind of incorporate it without sort of changing everything else, without suffering a lot of pain through the process. So, when GitHub launched Actions, it really got people really excited even though it didn’t even hit the market yet at first. It was part of people’s kind of flow. It really helped their process.
Ben Halpern: 03:56
Even stuff like linting, it’s the process in software development of just sort of tabs and spaces, and linting tools get people excited. It’s funny. And it’s less different year to year than I think sometimes people realize in the startup community.
So, realizing that the most exciting things in the startup community are not necessarily the things that get developers as excited, and developers can get excited by some very boring things for other kind of people in tech.
Brianne Kimmel: 04:28
So, let’s say that one of the developer tools in the audience has built one of these painkillers for developers.
How would you go about getting taking this product to market?
How do you actually get it in front of the right developers?
Ben Halpern: 04:47
Yeah, so I think this is definitely one of those areas where things that don’t scale can really help.
Getting a few fans, users really on board really helps these things spread.
People love to give talks about things that they … that’s scored them some wins in their process, so you reach a few people who really love the tool, and can possibly give back to the tool in some way.
Leveraging open-source in that way is always helpful.
You score some wins with some of the right people, and they’re going to tell their friends.
People are going to write about it. It’s going to spread pretty naturally.
Trying to invest too much in paid acquisition, just like a lot of other startup ideas, the developer ecosystem can be chaotic.
It can be hard to kind of become sticky, and I think you do that by reaching a dedicated fan base at first, and hoping they tell their friends. And they will if it’s solving a real problem.
Brianne Kimmel: 05:57
Controversial question, but have you ever seen this go wrong?
So, you’re talking about building a community, and doing things that don’t scale which feels like a very organic way of growing, and kind of moving into more of a dev friendly company.
Have you ever seen examples, or have there been some lessons learned where either entrepreneurs or someone has tried to push into the developer community, and it hasn’t turned out well?
I’m trying to understand what is authentic versus inauthentic, and how do we balance both? Like move fast, but still maintain authenticity.
Ben Halpern: 06:30
Yeah. Authenticity is definitely one of the most important terms here.
Developers can smell bullshit, incredibly sensitive nose for that sort of thing. And it’s sometimes oversensitive.
Developers can become sort of jaded and cynical, and you try to reach them with the wrong messaging, it’s going to injure your brand.
You’re going to sort of live through some pain. Actually, I think as much as MongoDB has truly become a total success, and they’re a public company, and they’re skyrocketing in the public markets, and they’re incredibly successful, I think they suffered through some pain of being a database company that occasionally lost the trust of the community because data and trust go hand in hand.
And they worked through it. They had great relations. They stuck to the fundamentals.
They became the winner in a space that seemed like it was going to be the next big thing, and it turned out it was just Mongo plus … each of the major cloud providers has a solution, as well, in the no sequel community.
Ben Halpern: 07:57
There have been some other attempts which have sort of failed by failing to kind of work through the actually pain developers were having, and bring the product people cared about even if it was useful.
In contrast to Mongo, RethinkDB, another database, very similar model. It was an open-source database.
It lives on as a project with some popularity, but still a lot of pain, but the company folded.
They just didn’t really solidify the trust, didn’t get the messaging about why this was a really differentiated project.
I had some experience working with it. I think I remember it being a little bit more painful than it needed to be, and they just didn’t get it right even though the technology was.
Mongo failed in a lot of the same ways early on, and I think they did a good job of maintaining trust in their brand, and understanding the more boring value propositions that sometimes people cared about.
Brianne Kimmel: 09:17
Do you feel like with Mongo, with GitHub, with Twilio, with some of the more mature companies, do you notice a different type of developer that wants to join and work at these companies?
Do you see different ways of some developers or more early stage startup individuals others want to join because there’s different problems to solve once the company starts to mature?
How do you think about the various different types of developers?
Ben Halpern: 09:42
Yeah. That’s definitely a spectrum that exists. So, I think folks in the Silicon Valley area also tend to over index on the people that fit into their physical universe, which represents a pretty small percentage of overall developers.
Twilio has always had success because they solved a lot of really fundamental problems, but I think for awhile they had a harder time reaching the more excited developer community in some way, especially after I think SMS became a little less exciting for people.
Ben Halpern: 10:30
So, at the height of maybe the chat bot excitement, maybe Twilio had a certain bit of momentum which faded a bit, but they stayed strong because they have good fundamentals.
They’ve got sort of different markets, but it is like the people who care about the most interesting, innovative things that a company like that will do are definitely a different crowd than the people who think that the communication pipes of the software industry are the most exciting part.
And very different people, you don’t necessarily have to try too hard to overemphasize either one because if you’re clear about your value proposition, and you have a good looking brand, people are going to sort of understand.
Ben Halpern: 11:35
So, I don’t know if you want to over-communicate where you stand on that spectrum because you probably need to hire people on either one, but you should have an idea of what value you bring to each kind of person.
Brianne Kimmel: 11:47
Yeah, that’s a really interesting point.
What I love about Dev.to is the ability to communicate the things that they want to work on, or sort of the things that you’re currently thinking about versus maybe the things on your resume.
This is really important as people are switching companies, changing careers and constantly evolving in their interest areas.
Are you seeing any trends with decentralized companies where the need for community is sort of increasing over time? Is there a greater need for developers to connect with other developers?
Ben Halpern: 12:26
The decentralized nature of software development, and the idea of asynchronous communication as being so important has been sort of with us forever.
The start of the world wide web had all these fascinating asynchronous conversations between Marc Andreessen who co-founded Netscape and Tim Berners-Lee who invented the World Wide Web, who represent to incredibly different ends of the spectrum in terms of software development personalities, but two super brilliant people who understood the power of the web early on.
And that same sort of fundamentals of communication, and how community happens hasn’t ever gone away, and is probably having a resurgence because of remote work, which it’s possible is just the default in our industry going forward. I would say if I were to guess that I think that would be the case, and I think there’s going to be some purpose for campuses as part of a strategy.
Distributed work, and more fundamentally, asynchronous communication as the thing that enables it is critical, and you see a lot of companies building really good tools that help with this.
Ben Halpern: 13:47
Slack is useful for both synchronous and asynchronous. There’s a paper trail. Notion is a really great product that I think solves a lot of problems.
And then GitHub for asynchronous communication was really the big one for software developers.
The part where you use Git, and merge the code, and stuff is what GitHub’s built on, but that didn’t really mean GitHub was going to be successful. But they really understood communication, and continue to kind of innovate, and build on that.
Brianne Kimmel: 14:22
Specifically with some of the earlier stage companies here today, often times you’ll have maybe a few core team members, or early founders are based in Silicon Valley, but behind the scenes, you have an army of developers either in your home country if you grew up overseas, or you start to build more remote engineering offices sooner rather than later just due to costs in the Bay Area.
What are your thoughts on some ways to not only find the right devs, but also some ways to think about employee retention, and what sort of motivates them over time?
Ben Halpern: 14:58
With remote employees, retention and motivation is probably the hardest part.
Communication has gotten easier over time, but it’s really hard to tell if someone really hates their job if you don’t see them.
We have a portion of our team remote. We have an office in Brooklyn. I don’t even go in most days.
Early on we did more in person because we just had to kind of work through less organized stuff, but eventually, saving the time on commute became so much better.
Ben Halpern: 15:53
So, we have one person that works for us full-time as a contractor now in Russia.
And I communicated with her when we were hiring her. One of my co-founders I think talked to her via video call, but I don’t even know what she looks like.
But we have tremendous communication. We have great vibes, and then we’ve also had some issues with just … we had a hard time as the home base kind of communicating with folks.
I’ve seen it really go horribly wrong in some cases where you just have no idea what’s going on over there.
You’re just praying that this distributed team is doing the things you want them to be doing, and you just go downhill, and you fail. So, you need to be sort of agile.
You need to kind of develop an understanding of what’s going on, and really over-communicate everything.
Brianne Kimmel: 17:02
Got it. So, process, communication, you mentioned Slack is great for that.
Notion can be another, as well. What about in terms of career development and mentorship?
Because I’ve seen a couple of platforms played out as one where you’re able to get mentored by more senior managers at other companies.
Do you feel like there’s a need for ongoing education? Or how do you think about retention when it comes to not only hiring, but then training and continuous education with developers?
Ben Halpern: 17:32
I think with continuous education, there’s a sense that … I would think that the hardest part is that there’s probably not going to be any singular tools which are overly effective because of the hyper specific nature of a lot of software development problems.
So, you need to sort of learn by immersion, and that’s what’s great about when you’re hired into a company with an office. You can kind of be a fly on the wall in certain discussions, and stuff.
And that’s definitely not the case as much in distributed environments. I think the most important thing for the individual developer, and for a team looking to be successful when you’re looking to have your distributed team learn, and get better, I think it’s to look for self-starters, and for developers to become self-starters.
Because there is a huge amount of resources out there, and there’s a huge amount of helpfulness from the senior development community, and they’re always being proactive. The good ones are really getting ahead of things, but people get lost when they’re waiting around for someone to kind of solve their problem.
Ben Halpern: 18:51
Me, working at our HQ, or in my home, I have a hard time. I won’t know if you’re just struggling through one little thing, and I could just quickly help you out.
You need to be able to communicate back up, like what’s going on with your day.
We don’t want to know every detail you go through. We want you to be able to kind of take a walk with your dog, and come back to your computer.
We don’t want to know where you are, but we really need to know what you’re going through. It’s those little moments that sort of push you in the right direction, and you need to kind of communicate that back up. As the founders, as the people vested in the success of our hires, and our contractors, we need to make it easy for them to do that. So, that’s kind of the dynamic.
Ben Halpern: 19:44
And then the education happens on its own throughout the community. So much of what we do is education. There’s education everywhere. GitHub, Stack Overflow, organizations that specialize in the education process explicitly, and it happens very organically as long as there’s communication, good, solid, two way communication, and ground up communication from the newer developers and stuff.
Brianne Kimmel: 20:08
I’ve seen this in companies that have a culture focused on transparency. I think if you have a very open culture where it feels like no ask is too small, and you can kind of create these systems where it’s easy to communicate, it’s easy to ask for help without feeling embarrassed, or like you’re failing. It’s great to hear.
I think that you guys have done that really well. I think another thing that Dev has done really well is I think that by building a community you have been able to partner with other great tech companies.
Can you talk about how you work with companies like Netlify, Repl.it or Digital Ocean?
How do you view your job as a founder in terms of helping other companies, or in terms of building long term relationships?
Because I think for this audience, what’s interesting is we’re all around the same size and same stage, and I think there’s an opportunity to either do things as tactical as coming together for a hackathon, or just really starting to build the community from day one.
Do you have any thoughts on how you started that from the beginning?
Ben Halpern: 21:15
In terms of successes and failures in partnerships, and getting along with organizations, I think consistent learnings for us have been to walk away from discussions with some next steps.
Even if they’re the simplest things, and even if it’s … be good at having the right ask. You’ll leave a conversation with someone, and you’ll be like, cool.
You should start using our platform creatively. It’s hard to stoke creativity in people.
If you’re creative with our partnership, it’ll go great because you have all these tools we have for you.
But that sometimes doesn’t go far enough because people get busy with other things, things come up. So, some very simple takeaways is to kind of get the ball rolling, or help momentum happen, and stuff like that.
Ben Halpern: 22:17
I was just talking with an important contact this morning at a big tech company who would love to be kind of using our platform to help communicate with their developers, and things like that.
At the end of the conversation, he said, “How can I kind of help you today as much as possible?” And that’s kind of been a hard question for us to answer. Just like, I don’t know. Just be awesome. Be a good community member, and stuff.
But knowing that the vaguer it is, the less likely anything will happen, I gave some really boring things that they could do this afternoon that would just be helpful for us no matter what happens with our relationship.
One of those things was I asked them to put the Dev logo on their personal homepage just alongside Twitter just as a totally arbitrary, specific ask. But it sort of cemented like, let’s do one thing together, and then the next step, and the next step.
Ben Halpern: 23:18
Even though you could go in any number of direction, having a simple step zero with any relationship is incredibly important. It’s similar to kind of on-boarding a new user.
They’re not going to start becoming a power user on day one, but you want to give them a few simple steps to get started with your project, and then ultimately things happen through various a-ha moments along the way. Relationships build.
People kind of learn the tools, and understand the nuances, and that’s never going to happen if you’re just constantly expecting them to figure it out on their own, or leaving things vague because then you’re just going to kind of forget about it, and go home.
Brianne Kimmel: 23:59
I think that’s a really interesting point. I feel like with a lot of startups, we typically wait for awhile before we start to approach the big tech companies, or start to think about partnerships, or working directly with them.
I think oftentimes it’s like prioritization. How important is it to start building those relationships? And also how actionable is it going to be?
Because I think a lot of times when talking to some of the large tech companies you can kind of get into … you kind of go down the rabbit hole of meeting after meeting after meeting.
When would you recommend starting to build these relationships?
And what have been some ways where you able to kind of solicit those next steps, and make sure that there was followup?
Ben Halpern: 24:43
This sparks some good thoughts about our absolute origin stories when it was just me. Not even our, just me sitting around. But you’re always going through different origin stories, so I think things like this kind of help it, a kind of new beginning.
But when I had the Twitter account, I had a bit of a following. I had this new kind of blog I was writing on, and stuff. I had the idea that if I interviewed some bigger names, that they would share the interview after that, and that would be a great way to kind of build things.
Interviewing someone via blog was good, and I understand the issue. I’m a good communicator. I felt like if I have some good questions, it would be good content.
Ben Halpern: 25:32
So, I just emailed some huge names, and they responded. Literally, at that point I got 100% yeses. I emailed the right people. I didn’t even propose an interview. I just proposed me sending them a couple questions via email for them to answer, and then just let’s kind of treat this as if it were an interview, but I’m going to make it as simple as humanely possible for you. Just making the yes as easy as possible.
Before there was any traction, I got David Heinemeier Hansson, the founder of Basecamp, and the creator of Rails to do an interview. He was excited because they were about to launch Rails 5, and he wanted to get some of his thoughts out. And that was like an easy yes.
Ben Halpern: 26:28
I’m shy, introverted. I have to kind of work up the courage to do stuff like that, but it works if you understand that the person on the other end is going to say yes. A little self reflection in that way really goes a long way.
When you get an email, and it’s actionable, the ask is easy for you to do with your own knowledge, software developers I know just love blabbing about their things, like what we’re doing right now.
And making the ask easy, and simple, and within the person’s wheelhouse is great. I’m also kind of in a conversation with someone who proposed a fun little collaboration, and I’m actually personally struggling through it because I want to do it, but it’s requiring us both to be creative, and figure things out, and I would’ve kind of preferred if there was a very specific ask
Brianne Kimmel: 27:53
With developers, it feels like there are blurred lines between personal and professional.
You can build a personal following for your open-source projects that you’re building for your company.
Do you kind of lean into the personal plus professional, where you’re building relationships with the individual who may or may not stay at that current company?
They may go to a different company. How do you sort of view relationship building when it comes to the personal, and the professional side of things?
Ben Halpern: 28:41
Yeah. I definitely think that’s pretty key to everything. I have a friend at Microsoft at Azure, and when I met her she was at Google. Now we’re the total competitor in that specific space. And that was cool, and we kind of have to understand there’s a lot of fluidity there.
Most business relationships are more personal than professional really, honestly. People want to do business with people they can be friends with, and stuff. I think it’s important to understand appropriate boundaries for even just any personal relationship.
So, you have a relationship that’s different from being best friends because I don’t think it’s necessarily healthy if people just do work with their friends. But you know, seek out the personal relationships with a variety of people that they can have in their lives, and ask personal questions. Get coffee, and don’t talk only about the work or the opportunity. And that’s led to a lot of our success, my success, just being friendly, offering to help on things that don’t have an obvious payoff.
Brianne Kimmel: 30:13
Yeah, that’s a great point. I think that speaks a lot to also the format of this event, and why we’re hosting it at GitHub. So, GitHub, that’s part of their core ethos, and they still deliver on that to date. Where I think like you said before, when you invest in non-scalable things, and when you proactively bring people together, there’s always a nice support group, and people who are willing to be helpful. We’re super grateful to have this space, and love the work that GitHub is doing to actually just facilitate these conversations, and bring people together. So, that’s great. Ben, thank you.
Hosted by Brianne Kimmel and Ben Halpern.
Ben Halpern is the founder of Dev.to, one of the fastest growing communities for developers with 1.8 million unique visitors per month. Ben has written over 500 blog posts for developers and his Twitter handle @thepracticaldev is one of the most popular sources for developer news and education.
Follow Ben on Twitter: @benhalpern
Brianne Kimmel is an angel investor and startup advisor in Silicon Valley. Brianne previously worked on the go-to-market team at Zendesk focused on self-serve revenue growth, technology integrations and built Zendesk for Startups.
Follow Brianne on Twitter: @briannekimmel
This talk is most relevant for APIs, payment & e-commerce solutions, code editors, data & analytics tools, testing suites, deployment & hosting infrastructure and more.
For more thoughts on startup growth and go-to-market, sign up to get my newsletter delivered to your inbox.
Get my newsletter delivered to your inbox