For businesses to compete today, they need to be agile, innovative and scale more than ever. APIs can help an organization achieve these goals but before an organization can reap the benefits of APIs, it must set up an API strategy.
Developing an API strategy can be broken down into four stages: establishing your strategy, aligning your organization and culture, building the technology needed to support the strategy and engaging with your ecosystem. This series of articles examines what the world’s leading developer relations practitioners are doing with respect to that fourth stage.
All successful API providers make it a priority to actively engage with their developer communities. Doing so helps build a vibrant ecosystem of developers and partners who can extend the reach of their API strategy. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article will focus on Cockroach Labs, creator of CockroachDB, a cloud-native, distributed SQL database. We spoke with Lisa-Marie Namphy, Head of Developer Relations at Cockroach Labs.
Cockroach Labs is in the early days of building out its Developer Relations program and Lisa-Marie was recently brought on to spearhead the process. To that end, Lisa-Marie discusses the types of people that thrive in a dev rel position stating that, “If you don't absolutely love your community, you are not going to be able to build a community and you're going to burn out. You have to do it as if you're not getting paid for doing it.” Namphy also stresses that developer relations efforts are never done in isolation and require working across product management and engineering teams. This focus on community extends beyond the company exemplified by Cockroach Labs’ commitment to open source. This approach can make the company more transparent, foster excitement in the community and can help small companies achieve beyond their head count. As Namphy says, “why have 150 developers in your company when you can have...20,000.”
We also discussed strategies for hackathons, both traditional and in a post-COVID world, and talked about why it’s important to look for developers outside of the traditional name brand universities. To find out more about Cockroach Labs’ approach, read the transcript of the interview below. This interview has been edited for clarity and length.
ProgrammableWeb: Hi this is Wendell Santos, editor of ProgrammableWeb and today I’m speaking with Lisa-Marie Namphy, Head of Developer Relations at Cockroach Labs. Pleasure to meet you, Lisa-Marie. Could you tell our readers a little bit about yourself and some of your background and then also a little bit about Cockroach Labs.
Lisa-Marie Namphy: Okay. Sounds good. My name is Lisa Marie Namphy. I go by Lisa. I've been in this industry for many more years than there was an actual advocacy or DevRel role. I started my software career mostly at Oracle. It was probably my first significant job that I had. So I started in databases and now I've come back full circle.
So it's super exciting to be working at a cloud native database company. I've been in open source communities for probably the last 10 or 12 years. And even when I was at places like HP or my last startup was Portworx, I always worked very closely with the open source community.
We started the first ever OpenStack user group and I ran that for eight years or so until we morphed it into more of an open infrastructure and then cloud native. We just took the conversation more up the stack. And then everyone wanted to talk about containers. So I ended up transitioning the user group into cloud native containers, and now it is the world's largest CNCF(Cloud Native Computing Foundation) user group.
And I still run that out of the Bay Area, and we can talk about the importance of meet-ups in DevRel and Dev advocacy, if you want. But we ran that user group. We ran meet-ups twice a month, in some cases, for years. And we still do, now it's virtual, so it's not as often. But it's still a very, very active community. And through all that work, I ended up becoming a CNCF ambassador.
So I wear that hat as well. Again, those are all upstream things that have never really been attached to the actual company that I was working for. I just liked to work for companies that are very open source minded, contribute a lot back, because that's how I believe software should be built. And we all consume open software, so if we're not contributing back, then who is? And how are we moving industry forward?
So my job is always split a lot with open source and upstream. And what's so cool about Cockroach is what we do is out in the open. This is why we have so many stars on GitHub and why the trajectory has gone up so fast, because people really appreciate that transparency and they want to be a part of that. So that definitely factored into my decision to come here and help put a real structured program around what has already been just amazing organic work from the team here at Cockroach and the things they've been able to accomplish up until now, just kind of grassroots stuff.
Cockroach is just a really, really exciting place to work. I don't know how much you know about Cockroach Labs, but the three founders, [were among the] early folks at Google and then they all met each other, I believe, at Berkeley University.
Together they make up a different kind of management team. They understand the value of open-source. They understand the value of developer communities. They've built a very developer-centric, developer-first product, and therefore all the messaging in the company is very developer-centric. That makes our jobs a lot easier and that's how they've been able to accomplish so much organically.
They also really care about their employees and they've fostered an amazing community within the company. Diversity and inclusion is something they pay a lot of attention to, and that was very important to me when choosing where I was going to work next. As far as the product, it was rewritten from the ground up to be a hundred percent cloud native, and all the things you're supposed to know about cockroaches, right? The indestructible, resilient database that's scalable. It's a good analogy for thinking about the technology they built.
So it was a sort of a perfect match of technology and people and the right place they are and building something from the ground up and being able to get super exciting developers organized and give them a place where they can really have a voice and a community and come together.
PW: That's interesting. So clearly what I'm hearing is a lot of focus on open source, kind of a grounding around that and being open and having a community really engaged in that way. As we start talking about developer engagement, at a high level would you say that's part of the strategy? Would that be part of the strategy going forward. And what are some of the things that you guys are trying to do or have done successfully that have really made a difference in terms of engaging with your community?
Namphy: When I started digging into why we have 19,000 stars in GitHub compared to less than 5,000 just a couple of years ago, I mean, this has all happened really, really fast. We have 1,600 members in our community Slack, and I think that's really been growing over just the last year.
One of the contributing factors is that our entire development process is put on GitHub where it can be seen publicly. We also write a lot of blog posts highlighting that process. There's a lot of appreciation I think for that. We're one of the biggest Go projects out there, which is unusual. So I think all of that is what fosters all this excitement in the community.
We just participated in Hacktoberfest, a hackathon to get more open source contributors and to get a lot of more first-time contributors. So we made it easy for people to contribute. We wrote a blog telling people the ABC's if you're a first time contributor and how you can contribute to our projects. I think we had 29 commits to our docs just that came out of Hacktoberfest.
We had a bunch of commits to the spatial features that are coming out in our next release that's coming out next month. People were tweeting about, "This was my first pull request accepted." There was a lot of enthusiasm around that. So there are a lot of ways to contribute. I think we use open source as a way of building the community and helping getting the community involved. It's not going to be on every level of the product, but there are a lot of places where it does play a key factor.
PW: You said something interesting about having people feel like they're making a meaningful contribution. Are there things that you do that truly lets the community feel like, “hey, I am making a difference, I am making a meaningful contribution?”
Namphy: Yeah, I think we do highlight. If there's somebody that's done something significant, at the very least we're sending them a t-shirt. But one of the programs I want to put in place is holiday gifts for our top contributors, just as if they were our customers.
Also, Cockroach has a strong swag game. They really do. So I see the love getting tweeted back out, or somebody putting a picture on LinkedIn. Last week I just saw a developer who was one of those open source contributors saying, "Thank you, Cockroach Labs, for the shirt." And he posted a picture of himself wearing it. And that's just so cool.
And we have this community channel, too, where we try to give acknowledgements and really say thank you. Even in the press release for 20.1, before I even joined, I remember reading that press release and they thanked the open source contributors in the press release. I mean, how cool is that? So I think that they do feel that their contributions are valued, and I want to continue doing an even better job and really showcasing those folks and just letting them know. After all, they're really valuable parts of our community and we want to keep them as engaged as possible.
PW: How many people are in the company right now?
Namphy: I think we're around 200, and we're growing really fast. I believe that we've doubled in the last six months, I think. I want to grow the open-source contributions as well, because why have 150 developers in your company when you can have 200,000 developers in your company or, maybe a more realistic number, 20,000.
But that's the beauty of open source and that's why I push strongly for it. And again, you still have to hire the best and brightest to work a hundred percent on your product, and we have that too. But if you're talking about some of those integrations that need to be built just to [help developers]. Developers have their favorite tools already. So if you have a Django developer or Hibernate, you better be able to have integrations and be able to let them use the tooling that they already want to use for whatever app development is happening.
And that can't all happen from within. You have to have a good program where you're reaching out to people in the community to [get them to] say, okay, I love this tool, but I love Cockroach. So I'm going to write this and I'm going to let everybody use it. And we're going to make everyone's life more happy and it's a win-win. So that's the kind of stuff that I think we really need to do to scale.
And there's been some of that done, but there just hasn't been a formal program. The engineers, the product team, product managers [have done a] lot of grassroots stuff that we really want to scale. So we want to build a really legitimate DevRel team, and we're in the process of doing that. I was employee number one in that effort, and then I've just brought on employee number two to DevRel in Cockroach. But hopefully as these programs get more momentum, we'll be able to grow the team to much bigger.
PW: That was going to be my next question. Obviously DevRel is a team that is small and going to be growing. If you had your way, what would your DevRel team look like even six months from now? What might the composition of a team look like?
Namphy: The way I think about community, and probably the same thing applies to the team, it's not just... Who is this community that we're talking about? There are a lot of developers in existing Cockroach customer accounts. There are our open source developers. There are operators versus app developers. There are developers at Cockroach Labs itself. There are a lot of users out there. So all of that is community. And each part of those communities are going to have maybe a little bit of a different focus. They don't all have the same goals or the same desires. And so how do you bring a community together when you have kind of these different parts of the community?
I think about the team the same way. Even when I was an army of one, I was never an army of one. I mean, that's the whole thing about community, right? So working very closely with the product management team, working very closely with the engineers. We have this amazing engineer that runs his own Twitch stream every Friday. You can sit there for six hours and watch him code, and a thousand people do that.
What he's doing is so cool. And he's absolutely a dev advocate and part of the DevRel program. There's a couple of product managers who have been kind of doing this, who are building a hackathon program, who are working with Major League Hacks to reach out to students, to reach out in different places. These programs were started before I even got here.
So what my team would look like would be maybe there's three or four of us, a technical evangelist, a developer advocate. I've hired someone from the docs writing team. So docs are super important. So she's going to continue doing a lot of the writing. But we still have dotted lines in the docs team and dotted lines in engineering. Everybody needs to have a stake in this.
If you're a community architect, chances are you're doing that whether it's your job or not. And I think this is something that I've talked a lot about my approach to my career. People will ask me all the time, like, how did you build this huge user group and how do you keep the energy? How do you not burn out? All of that stuff about community development.
If you don't absolutely love your community, you are not going to be able to build a community and you're going to burn out. You have to do it as if you're not getting paid for doing it. And I can honestly say that because for about the last 8 to 10 years, I have not gotten paid to do these things in open source and communities. And that's all of open source.
People do their job and then they go and write code at night to contribute to their favorite project. That happens all the time. And running communities is the same way. You do it for the love of it, for the love of the community, for the love of the technology because you believe in what you're building, and you understand that it takes a group of people to do this thing.
And if you don't nurture that group of people and make sure that everybody feels valued, that they have a sense of belonging, you're just not going to retain that community and it's not going to grow. So it's the same thing internally. I'm looking for those people that are already doing that job, and those are people that I gather and that's the team. Those are the people that we work with.
So it's a little bit of a different approach. But if someone doesn't have that [drive], I can't go make this be somebody's job because they're going to burn out. They're not really going to want to do it. They're going to complain to their manager this is like taking extra time away from their other job. You have to really believe in it and really want to do it. I'm blessed that I'm working with so many people that do believe in it, that do feel like they have a stake in it and that are willing to give the time.
PW: That's interesting. You talked about some of the champions, I've called them champions, but internally, these are the people that care about the community. You had mentioned earlier that some of the people that use your product, perhaps you would call them partners, but that they are also champions. Do you leverage them in any way to kind of help you scale because you need to have those champions really help you broadcast your message to a bigger group?
Namphy: Yeah. That has been done before I got here. That is absolutely part of the plan. That's necessary. If somebody else tells your story, it's so much more believable than if you're telling your own story. So we want to build a product that's so fun for people to use and so interesting and allows them to do really cool things in their job. Tell us that story.
We don't have a formal like visitor blog set up yet. It's been organic and we try to grab it. We'll use a tool like Mentions or something where we actually get to go kind of see that there are a lot of people chatting about us here and there. And there are some people who have posted blogs or some folks who have done different things in different forums.
I would love to have a lot more of that. I'd love to build a program where we can kind of foster and nurture that a little bit more. And we do have a lot of amazing customers/users in our community that are doing really cool things. So that's part of the plan. Again, I'm in my 30 days, so I haven't had the time to go and do all of that. But some of it has been done in the past and we definitely want to continue doing that.
PW: Okay. Let's talk about events, because you mentioned Hacktoberfest and some of the other events similar to that. You said your team was working with Major League Hacking. How does that look like nowadays? In the old days, you'd get a hackathon, throw everyone in a big room for the night, the weekend, and there you go. What does that look like nowadays? What's the enthusiasm level? Has it changed? Can you speak to any of that?
Namphy: Yeah. You don't have that person walking around the room for instant support, like tech support, and it's also you don't have the hallway chatter to influence or to even kind of hear like, oh, what are they saying? Are they struggling? Is it easy to use? So you really have to pull that information out. But the biggest thing is you have to give them the tools to be successful.
So you need the one-pager cheat sheets. Especially something like Major League Hacking, where I believe the participants have a choice of which technology they want to use. And so they're choosing Cockroach for their database if they want to, but they could choose something else. If they choose us, and we're not easy, and they're struggling and they don't have a very quick go-to, how are they going to get supported? Where are they going to find the information?
So docs are crucial, but even kind of like one-pager install guides, whatever it is to get people up and running. Also, here's where you go for questions. We've got the community Slack channel, we've got Slack overflow, we've got our GitHub repo. There's a lot of places you can go to communicate with us and we'll get back to you right away.
The point is to be really clear, don't overwhelm [them] with a full set of docs. But whatever that people need to make sure that they can get successful and also if you want to point them to here's the really cool stuff about the product. Try this, try that. Just kind of lead people to help them have a good experience from the beginning. So I would imagine that there's stuff like that, but I think we were very hands-on with supporting whoever needed help with people at Cockroach.
So I think the support of those events and the marketing of your own technology within them is a little bit different than it used to be. But I think our community is so used to being online, that part of it isn't strange to them. Some hackathons are trying to break people up into teams. That gets a little bit difficult. You don't have these breakout rooms of four people to go and kind of work on something together.
I think you're getting a lot more individual stuff, which is kind of a shame, unless people are really proactive about figuring out how they get together. Major League Hacking focuses on universities. So they might target a group of students that can work together. But not every hackathon is like that. So we just really try to support where necessary.
For Hacktoberfest, we had a lot of enthusiasm, and I think a lot of it had to do with putting a survey out before where we said, “okay, what would it take for you to engage? What can we do that we haven't done already to help you engage with us and contribute to our open source?” And the survey responses came back, unanimously, to make it easier. And that's why we wrote that [ABC’s] blog.
I think we published it on Dev.to and it got around 5,000 views of just kind of the ABCs of if you're a first time contributor, here's what you do. If you want to go middle-of-the-road, we have this app, I think they called it a to-do, that was in a different bucket. And then if you're hardcore, here's what you can do. So we put it into three different levels.
And that really resonated with people. They were very grateful. We had the product team really supporting when people were struggling and really helping out. And we got a lot of love on Twitter and on the Slack channel and people saying thank you. Thank you for all that hands-on. And we had a couple of people who got all four [commits] there.
I don't know if you know how Hacktoberfest works. In order for you to get your prize from DigitalOcean, you have to have four commits, I believe. Your pull request has to be accepted, and it can be from four different companies. And we actually had several people who chose all four for Cockroach in order to get their prize from DigitalOcean.
So we sent everybody a shirt and we're writing a blog about the cool apps and the cool stuff that people did. We'll post that blog probably in a couple of days just to show that we really did appreciate this and we want to do more of it.
But one thing I want to say about the Major League Hacking, and this is one of the things I love about Cockroach, when we decided to sign up with Major League Hacking, they asked us “what universities do you target?” Because a lot of these hackathons, they'll just go to the Stanfords and MITs and the technology colleges especially on the East Coast.
A couple of the founders came from public schools. They're not Ivy League and they're really proud of making the point that you don't have to [go to those schools.] Like Google wanted to only hire from Stanford for a really long time. That's crazy. There's a lot of really good people out there. And since Cockroach is very concerned about diversity and inclusion and equal opportunity, we actually went back to Major League Hacking and said, "We want you to target public schools."
And we gave a list of community colleges and Major League Hacking [told us] no one had asked for that before. So that was really cool, because we do feel like there's just so many developers and even more when you go internationally, but so many developers in places that traditionally recruiters necessarily haven't looked. We wanted to enable some of those folks to be able to have the Cockroach experience.
PW: That's amazing. I think there's this fallacy that if you're not hiring from the top brands, and this is in any profession, if you're not hiring from the top line, you're not getting the top line talent. And there's nothing to back that up. It just is not the case. It perpetuates that cycle of exclusion. So that's a really cool thing to hear from you.
Namphy: I mean, especially when we're talking about developers, everybody can sit in their garage if you have a computer and start hacking away. And those aren't the people necessarily at Harvard. It's just the wrong place to look. So I was really impressed that the leaders of Cockroach and the marketing team, the CMO, are amazingly diversity minded. He went through public schools, and I was a public school person as well. I went to Palo Alto high school.
I'm a big fan of public schools. And so I think there's a lot of people at the company that really understand that coding can be a great equalizer. So we need to very much broaden our mindset of where we're looking for the best developers.
PW: And what's the response been like as Major League Hacking has started to reach out to those public schools?
Namphy: I believe they did about four hackathons in the last week of October so we're starting to get the data back now. I think we had a goal of 500 students and we already got back a list of some really, really cool applications that people are building.
I mean, this is the kind of fun thing. It was like watching students think outside the box. It's the sort of stuff that when you're in a corporation you're trying to solve corporate problems. But there were two apps on COVID tracking and there was an app on food distribution and planning and just really cool stuff that I was so proud of the students. So we want to look at what people build and write about it and highlight some of that really fun work that they're doing.
PW: That's great. I was going through your developer section on the site this morning and something that caught my eye was university. And I don't know if you are able to speak to that, but it seems like that is a way to train developers on Cockroach. Do you want to talk about that at all?
Namphy: Yeah, Cockroach University is great. We all have internal requirements as well to go and take the classes. That is a place that we want to push people towards, and it will help them be much more successful with Cockroach. So that is one of the KPIs that we track, Cockroach University courses and how many students come and then how many courses they take.
So that's a metric that we think is going to make our community much more successful. So we are trying to push more people [there]. I'm not surprised you found that, because I think the marketing team has a lot of stuff that is going to direct folks to Cockroach University. So we hope that'll help make people more successful. And I know we do put a lot of love into that.
PW: Are you able to speak to any other KPIs that you guys feel are important?
Namphy: Yeah. It's funny with DevRel. In fact, I was just talking to my manager before you called and we were going through some of our, they call them OKRAs (Objectives, Key Results, Actions) at this company, or OKRs as most people call them. And tracking hackathons was one of the things. Obviously new members to our Slack, our community Slack channel, we have metrics around that. I would like to not track posts on stack overflow, but response times, how fast can we get back to people?
Because until we get to a point where our community is big enough where the community is responding to the community, we have to nurture that a little bit more hands-on. And so before I joined the company, I looked at what some of the posts on Stack Overflow were, and the good news is nobody was flaming us or saying anything really [negative]. It was all just really people trying to solve problems.
But what I would like to see is that response time coming down. I haven't found a great tool to track that, and same with Slack, how quickly can we respond? It's just me looking at it every day and then trying to have some kind of internal incentive programs to get people to want to pay more attention to it. I've seen people do it different ways.
You can have stoplight reporting and issues and then ones that have been solved and stuff like that. Or you can do kind of like a star method. So how many times did you solve a problem for someone and how fast was the response time? But that's a pretty manual thing. But it is a KPI that we are tracking. My KPIs are generally around a couple of different buckets like driving awareness and then increasing engagement.
And then there's kind of an open source, more creating advocates KPI. And so we'll track open source commits, open source contributors, community Slack engagement, social posts. That stuff is easy. What are people saying on the different channels and how much kind of organic versus something coming from Cockroach, dev page growth, Jordan's Twitch stream views, that kind of stuff, and reaching out into high school, coder schools, Cockroach University, how many people can we reach there and get involved and get trained? So, yeah, blogs. I think the usual stuff. Is anybody tracking anything really cool that I should know about?
PW: Well piggybacking on what you said about response times, I spoke to Nick Tran at Postman recently and what they do, in order to empower the developer community, is he tells his team, give it 24 to 48 hours when a question is asked so that our members of the community will come in and answer questions, and they feel like, hey, I'm really helping and contributing.
And then if it's still out there or if the question isn't answered quite fully, then they'll come in and answer it. But he likes to give them a little time to simmer and stew and let the community kind of answer that. And that's just a way to let them feel really like they have a piece of ownership in that community and they're all helping each other, so kind of becomes a virtuous cycle. I thought that was a cool approach.
Namphy: Yeah, that's the goal. If you have a big enough community and you can get there, that is wonderful. You always want a community helping and nurturing each other and itself. We're not there yet. So that's one of my long-term goals. But right now I can't let 48 hours go by. I want that response time way down. I'm a perfectionist. I want it down within an hour, but that's wishful thinking because everybody has a day job.
But I want to make this 10% of 20 people's jobs so we can pass it around and make sure we respond. It's like, we hear you. Even if it's just, yep, I'm on it, I'll get back to you, whatever it is. I mean, you know how it is. If you're just sitting there waiting for something and you're not hearing anything, it's like, I need like an hourglass, and you know something's happening. Not just like a spinning beach ball.
PW: Lisa there is a lot of great information that you’ve shared. I know you’re still getting your feet under you so I’m happy to circle back with you in a few weeks to hear what has changed.
Namphy: Thank you for saying that. I am sure that every single day I'm going to learn something and I'm going to be like, oh, I should've told Wendell that. But that's going to happen every day for the next five years. There's so much learning on the job, so much trying stuff, what works, what doesn't work. So like I was saying in the beginning, this role wasn't even really a role.
I mean, Guy Kawasaki talked about developer advocacy, but people didn't have DevRel teams until kind of in the last 10, 12 years. And when I was at Oracle, I was one of the people that started the first tools user group. It was called ODTUG, the Oracle [Developer] Tools User Group. I never thought I was doing developer relations. And then 20 years later, one of my friends was like, "You know, Lisa, you actually started one of the first developer communities at Oracle." And I'm like, "I did?"
But I just kind of did it because I needed to get people together and I needed to get them supported and I needed to get them talking to each other. And it was like, we were doing that with customers for a cab. Why don't we do that with people building on the tools? And it just seems so obvious to me. But it was never called that. So we're all figuring this out as we're going along. It's a career that's evolving and it's so cool to see so much excitement about it.
It's also a role that companies are really still trying to figure out, does it live in marketing? Does it live in engineering? What kind of budget should it have? All of those questions, which every place I've been has done it differently, and with pluses and minuses for all those things. For me, it just comes down to the people that you have doing it. It's a difficult role.
It takes a bizarre set of skills that are not usually found in one person. So that's why it's so hard, but I can't think of doing anything else. It's so rewarding.
I’d like to thank Lisa Marie Namphy for taking the time to speak with me and share Cockroach Labs’ approach to developer engagement. This is part of a series of interviews with developer relations experts such as Nick Tran at Postman, Quinton Wall at Twilio and Randall Degges at Okta. Be sure to keep an eye out for future interviews coming soon.