Crossing the Enterprise Chasm is a podcast on how high-growth startups prepare to build with enterprises and Fortune 500 companies. Each week WorkOS founder Michael Grinich is joined by founders, early-stage team members, and product leaders who lead the charge to go upmarket. In every episode, you'll find tactics, strategies, and actions on how to successfully sell to and serve your crucial early enterprise customers.
Michael Grinich (00:02):
Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving up market to serving enterprise customers. I'm your host, Michael Grinich. I'm the founder of WorkOS, which is a platform that helps developers quickly ship common enterprise features like single sign-on. On this podcast, you'll hear directly from founders, product leaders, and early stage operators who have navigated building great products for enterprise customers. In every episode, you'll find strategies, tactics, and real world advice for ways to make your app enterprise ready and take your business to the next level.
Today I'm joined by Bear Douglas, who currently leads developer relations at Pinecone. Before Pinecone, Bear led developer relations at Slack for almost seven years. And prior to that she spent a number of years as a developer advocate at both Facebook and Twitter. We're really excited to dive into Bear's knowledge about DevRel and experience engaging with developers. Bear, welcome to the podcast.
Bear Douglas (00:59):
Thank you so much for having me. I'm excited to be here.
Michael Grinich (01:01):
So before talking too much about your wide breadth of experience, I want to zoom out a little bit and talk first about what is DevRel? How would you define DevRel and maybe specifically how does it interplay with product and marketing organizations? Often it sits kind of in between or near those two functions.
Bear Douglas (01:19):
It's true. Kelsey Hightower recently tweeted something along the lines of DevRel is what your organization thinks it is. I should probably look up exactly what he said, but it came across as a very spicy take, but it's genuinely just a true one. Developer relations can mean something different to every company that has it, and it really depends on whether your company's product is purely a developer product or if you have an API platform that is an aspect to your product and how it all affects your business strategy with regard to what developers mean for you in terms of revenue or engagement or growth in your product. So developer relations in a company that puts it in product might be more responsible for things like running product betas and making sure that the voice of the developer is heard in the product process. They might be doing things like creating enablement materials.
That's pretty common across DevRel, no matter where you are, is that you're creating enablement materials for developers in a form of code artifacts like samples, documentation, blog posts, all the kinds of things that make it easier for people to get started or to go deeper with your product. Some of the other ancillary activities depend on what the company needs from DevRel. So if you are orged inside of marketing, there might be more that you're doing to drive top of funnel growth. So outreach through other communities, building relationships with people is a common theme throughout developer relations. It's the relations in developer relations so that you have a good touch point and an authentic touch point with people who are using your product.
It means that you can ask them whether a new product release actually will help them in the things that they're building. It means that you have a group of people who you can go to, to vet any kinds of things that you might be interested in doing programmatically. It's helpful to know what kinds of problems they're encountering in the real world because even though we build developer products in theory for ourselves as developers, it can be easy to lose touch with the kinds of things that your customers are facing if you don't talk to them on a regular basis. So that part of relating and talking and keeping a continuous feedback loop with your customers is critical no matter where developer relations is orged.
Michael Grinich (03:25):
I've heard about it being orged in different parts of a company. How do you think that influences what success looks like? DevRel at different places might measure in different ways. What's been your experience there? As maybe people listening are thinking about where DevRel would fit within their own company and they don't have DevRel yet. What are the different places it can emerge and maybe how is it tied to the company's goals or success?
Bear Douglas (03:48):
I would say that you have to start by thinking of what you want somebody in DevRel to do when you're making your first DevRel hire. And this might be skipping ahead to questions that you'll want to talk about later, but I've talked to a lot of startups and I was doing consulting with startups for quite some time when they were figuring out who is the first person that I need to bring in the door. And generally I start with the question, what is it that you need them to do? What metric is it that they have to move or what are you expecting that you will do better or more professionally once you have somebody in developer relations doing it for you? For some people it is making sure that you have high quality documentation. And in those cases, developer relations often sits in engineering because the completeness of your documentation is about the quality of your release, and it's not necessarily tied to any success metric because there's no question that you have to document a product that you're putting out to customers.
For companies that say, "We really want to see top-of-funnel growth from a developer relations function, and we expect them to be pounding the pavement at all kinds of events and making sure that our brand is known and creating collateral that gets us lots of clicks, lots of eyeballs." Those types of companies often put developer relations in marketing. And it's both because they expect to see some kind of top-of-the funnel growth or ROI there. And also because they are the ones who budget in a way where developer relations can be a marketing function, you're willing to put the money behind going out to events, you're willing to think about the sort of costs that are incurred as part of getting that return.
For folks who are thinking about building a community of advocates and wanting to create a lot of people who will go out and evangelize the product or who really think of customer feedback as a product development function, often those folks end up in product and some of their success metrics are in things like the success of a beta rollout of a function, like how many bugs were filed or how smoothly did a release go as a result of it being battle-tested? And that's not a hard and fast rule. It's not to say that people who are doing the DevRel role in companies that don't have that exact organizational alignment aren't doing these other things. Those are just the common metrics that I see.
For example, at Slack when we were in Product, one of the things that I cared most about was retention through the funnel. We weren't necessarily driving top-of-funnel. That was what our friends in the developer marketing team were doing, but we were responsible for a lot of the surfaces and points of integration that developers would have with the product that would determine whether or not they've had a good enough experience to stick around. We cared about developer NPS [Net Promoter Score] and sentiment, and we cared about whether or not there were key places that they were dropping off, for example, because they had trouble using our SDK or they couldn't read our docs. All that was within the remit of DevRel to fix. And so that was what we hung our hat on.
Michael Grinich (06:36):
Let's talk about that a little bit more because I think we started off talking about DevRel a bit more abstractly, multiple companies, how it works. I want to go deeper into Slack. So you joined Slack early 2017. Going back to that time, kind of walk through what was the state of the product and the platform specifically because that's really what DevRel owns. I'm curious, as you started thinking about your role there and started leading those endeavors, why did the company start investing in DevRel at that point? Slack was already, I believe, a pretty successful product getting a bunch of users. Why invest in DevRel at that moment? And we can talk about how you carried it forward for the years to follow.
Bear Douglas (07:09):
For sure. And it's worth noting that I wasn't the first DevRel hire at the time that there was a platform or an API right away. It had kind of always been important to Slack because there were so many conventions from IRC [Internet Relay Chat] and from previous technologies people or that developers specifically were used to using, that kind got translated to Slack because people expected to see them there. So things like managing incoming webhooks and being able to set up a bot, all of that was essentially getting you to feature parity with what people expected from the ecosystem. And then from there, the company invested more and more in the platform because the potential for Slack was that people could have an integrated workday where if you were sitting in Slack talking with your colleagues and you had relevant information getting piped to you from other services, you could have this much more streamlined, much more pleasant experience at work where you had all the people, the information, and the tools streamlined for you in Slack.
That was the vision. The company was pretty bought into that, which was something that was important to me as a DevRel practitioner, knowing that all the way up through senior management, people had a vision for the platform, a vision specifically for what developers were going to bring to it, and no incentives at odds with each other. For example, we wanted to support developers, we wanted them to be successful, we wanted them to grow businesses on top of Slack. They even created a Slack fund for investing in some of these apps that were created for work. And so just making sure that there was that alignment all the way through was important for me when I was looking for a job. Why they made the investment was again, because of that vision of the integrated workday. And developer relations at the time was about six people broken up into the team that was working on our SDKs. At the time it was just Python and Node. They were relatively thin clients.
We had our team working on documentation and more broadly educational materials. And then we had the partner engineers who worked with partners in the Slack app directory for bringing new apps onto the directory and also making sure that when we released exciting shiny new features in the API, they were fanned out to some of the most used apps in the ecosystem.
Michael Grinich (09:14):
I want to ask you about community. This word is used a lot and thrown around in a bunch of different places, and specifically at Slack, I think the Slack platform had a really strong community of people building apps on it and exploring what it meant to build on this future of work platform. How did that kind of factor into your thinking around DevRel or how does it overlap somewhere like Slack? I'm just curious about your general thoughts on that as a focus for maybe skipping forward a little bit to kind of what you're thinking about with Pinecone as well today.
Bear Douglas (09:42):
Sure. So when it came to my decision to join the company, it was definitely important to me that there was an existing positive sentiment and rapport so that you weren't digging your way out of a hole where people say, "Ah, fool me twice, Slack platform." So it's good to not have any of that negative baggage when you're coming in as a developer relations practitioner, but community and DevRel go hand in hand. We built that feeling together and one of the things that we explored over time was how much overlap there was or wasn't between the broader Slack user community and the Slack developer community because we found that a lot of people who were developing Slack apps were also admins. So there was some pretty tight overlap there, but more than you might expect, the interesting things that there were to talk about on the Slack platform were also relevant to a more general audience.
So not the implementation details of literally how do you build this, but the ideas of how has using a Slack app or building a Slack app transformed your workday. And so I think one of the strengths that we had was that we did a decent amount of cross-pollination of content between all of these audiences because as the platform evolved too, and there were fewer things that required you to have any coding skill to do well, people who were general Slack users loved having these secret hacks and tips and tricks that made them power users and made their experience with the product completely different. So when we thought about building community, I think the thing there that was just helpful was to recognize that you don't have to have discrete tiers of community. You can see some benefit from having crossover overlap and inviting people into spaces that may or may not just be for developers.
Michael Grinich (11:21):
Let's switch gears and talk a little bit about Pinecone. So you've joined there, been kind of mid late 2023. Tell me about that, what you saw in Pinecone and how your role has evolved and maybe describe what Pinecone is for anyone out listening, actually.
Bear Douglas (11:36):
Pinecone is a vector database, which is a database that's designed for use in AI applications. So whenever you run your data through an embedding model or a large language learning model, you end up with representations of that data that are best stored and accessed in a dedicated database designed for that different representation of your data. It's a pattern we've seen play out in the past multiple times when you have brand new shifts in how we represent things like graph databases required a different structure of a database, so vector databases are becoming more and more common. Pinecone was one of the first, and it's one of the first that's purpose built so not just treated as a feature to an existing database. It is optimized for use on vector data.
Michael Grinich (12:22):
And talk about what you saw in that company as the right time to hire DevRel. We talked about that a little bit earlier why companies hire DevRel. Why was it the right time for Pinecone and what's transforming at the company that makes it the right motion to start investing in this?
Bear Douglas (12:35):
More and more people are being called upon to build AI apps for their companies and people who are otherwise full stack developers. They're not data scientists. There's this role shift and who's being made responsible for doing AI transformation and digital transformation within companies. The product is really designed with that developer audience in mind for ease of use. And for Pinecone, what matters is helping people see the art of the possible, just letting them explore cases where they really can make a transformative impact on their company's business and what they can do. And also educating them up on what vector data even is and why you need a vector database and what you need to know about the nitty-gritty of data processing in order to make good choices architecturally for your app. And so some of the things that my team has been focused on this quarter is creating collateral that is not just a Jupyter Notebook where you can click through some dummy data and it shows you a very lightweight integration of storing a tiny amount of data in one instance of a database.
We want to show you what a real data ingestion pipeline looks like and what good chunking strategies are for when you're breaking up this data. And I don't know how much your audience knows about AI data processing and how much you want me to go into background here, but all of this stuff is relatively new to developers who are now being tasked with building AI applications. And so we want to be the helping hand that makes them be successful and fills those gaps that they might have in their knowledge about how to get from idea to actual working demo or proof of concept.
Michael Grinich (14:14):
It sounds like education's a big part of that kind of developer education of the market. How are you approaching that? Maybe tactically if you could give some tidbits or advice of how you're approaching it? Is it through content you're writing? Is it slides that you have for customers? I know you're making videos. How do you think about educating a developer audience for, I guess it's like a new way of building apps, new way of storing data in these vector databases for AI?
Bear Douglas (14:38):
So we try and create different collateral and different media for how people want to consume it. We've been guests on podcasts, we've done lots of YouTube videos, we've done screencasts. We're doing organized learning content modules where you can go through steps of a tutorial and check along the way that you're building on knowledge over the course of that tutorial. We focus on a mix of concepts, some of which are Pinecone specific, but we tend to err on the side of trying to teach people about the ecosystem in general because that is what everyone needs to know and that will eventually help them use Pinecone the product. But some of our most popular articles and learning content are about one, what is a vector database in general? And two, those high level questions that people have like optimal chunking strategies and how should you think about approaching your data and designing your data pipelines. Those are the kinds of topics that people come to us for.
Michael Grinich (15:28):
You have a pretty interesting set of experiences kind of zooming back. I did mention it before, but you kind of started years ago at Facebook and Twitter doing DevRel focused work. So you have this experience in both Facebook and Twitter, the consumer world, like consumer social products, at Slack in terms of collaboration, B2B apps, and now Pinecone, which is very much like a developer focused kind of API as a product or infrastructure. These are very different areas and yet you're doing sort of the same role across them. I'm really curious about how you could share what's different across these in terms of DevRel for these different product domains and what's been a through line, what's been similar or identical in each role?
Bear Douglas (16:07):
A lot is different when you think about the role that developers have to the success of the company and what that means for how the company treats developers and where you get prioritized in developing the platform and company goals and so on. So what I've found is something that is important to always have an answer to is where do developers ultimately end up affecting your bottom line? Because if the answer is, "We don't know, we'll figure it out eventually," there will come a time when you have to pay the piper, and if you don't have an answer for how attracting more developers to your platform your API is actually translating into revenue, you're in trouble. And there is more scope for that to happen that I've found in consumer companies where you sort of see developers and additional apps that can be built on top of your consumer service as a way to grow top-of-funnel, and that will translate into revenue maybe, maybe not, maybe down the line.
The latitude that you have to ignore that question really depends on the company, in companies that are developer products or that are B2B, that tends to be a much more clear narrative from day one. But in terms of how you behave as a DevRel, your developers shouldn't have to think about that. You as a person might want to have an answer for what this is going to look like for the company, but when you're creating positive experiences on your platform, when you're advocating for good developer experience quality, when you're building tools and samples that people need, much of the work is the same.
Michael Grinich (17:36):
Last question for you before we wrap up. I think a lot of people here are probably in that early phase where they haven't hired DevRel yet, and maybe even it's the phase where it's sort of founder-driven sales or founders are writing blog posts about the product or editing their docs and everything. If you were to give advice to a founder around when the right time would be to bring in DevRel and what should they look for? You've talked to a lot of early stage companies and advise them, what would you say, what would you give, as much as you possibly can, generic blanket advice, which is never ideally the best, but what would you say as a getting started point for those types of founders and early companies?
Bear Douglas (18:13):
When I have those conversations with founders, I start them off by asking, what is it that you expect to hand off to this person once they get in the door? And when you're thinking about when the right time is to hire, it's about three months before the work that is currently being farmed out to other people that you would concentrate in the DevRel role gets completely unsustainable for them. For example, if you need a documentation writer and you've currently got your engineers writing docs, it's a business decision for you at what point it becomes the wrong use of your engineer's time to push docs all the way to production. And it's my feeling that engineers should always be involved in the docs writing process. That's a conversation for another time. But that's just an example of one of the things that you might consider. You might think also, if you're trying to hire an evangelist and the work that they're replacing is your co-founder going out and speaking at conferences.
How soon would it be valuable to have your co-founder's time back and could you reasonably hand it over to someone who is ramped on your product, who can go be an evangelist? And those are the types of questions to help you answer when is the right time to hire. But another factor that's important in deciding what time is right to hire a DevRel person is when you have a clear answer to the question, what is this person going to do? What does success look like for them? And also, will we still need this role as a full-time role in six months?
And that's another thing that I've found occasionally with people that I've talked to is that they have a short-term need for some amount of DevRel type set up work, but they actually don't anticipate having a recurring need for that type of role for more than say, six months time. Or they think that it'll substantially pivot in terms of the skill set needed or what they would actually need from the role. And so there is definitely a level of company maturity when you think about hiring an individual person to do a role that I like to talk people through in their plans.
Michael Grinich (20:04):
Bear, this has been really great. Thanks so much for joining us and sharing a bunch about your stories from leading DevRel as well as a bunch of advice that I think will be sage wisdom for people listening.
Bear Douglas (20:13):
Thank you so much for having me. Appreciate it.
Michael Grinich (20:20):
You just listened to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving up market to serving enterprise customers. Want to learn more about becoming enterprise ready? The WorkOS blog is full of tons of articles and guides outlining best practices for adding features like Single Sign-On, SCIM provisioning, and more to your app. Also, make sure to subscribe to this podcast so you're first to hear about new episodes with more founders and product leads of fast-growing startups. I'm Michael Grinich, founder of WorkOS. Thanks so much for listening and see you next time.