Redpoint Office Hours with Astasia Myers & Adam FitzGerald (HashiCorp)
Earlier this month, we hosted the first in a new event series, Redpoint Office Hours, meant to bring together bright minds for spirited discussions on building and scaling great products and companies and trends that are on the horizon. For this month’s Office Hours, Astasia Myers of our early stage investing team and Adam FitzGerald, the VP of Developer Relations from HashiCorp, came together to chat about everything from the difference between DevRel and marketing, how to know whether — and when — to hire DevRel, and how to measure success for the function.
Some key takeaways from the conversation include:
- DevRel responsibilities involve 1) documentation and technical education, 2) evangelism/developer advocacy, and 3) community/events
- It is about building trust with the practitioners you’re trying to reach
- DevRel is different than developer marketing
- DevRel doesn’t change significantly between different GTM motions (open source vs. closed) as it is about helping developers and end users get their problems solved with technology quickly. However, the mix of responsibilities and measurement may be different.
- Founders should ask themselves two questions before starting a DevRel program: 1) Does your product or technology that you’re making actually solve a real problem that practitioners have? and 2) In the critical path of making my company successful, what is the role of the developer in enabling that success?
- Founders should start building a DevRel team when the company is 25–50 people
Below is the full conversation that has been edited for clarity.
Travis Bryant: We are live with Redpoint Office Hours. Thanks everyone for joining. Good morning, afternoon, and evening. We have people checking in from Berlin, from New York City, from Austin, Tel Aviv, Brazil, so this is a global event, which is fantastic to be able to take advantage of the virtual nature that we’re all living in these times.
I’m Travis Bryant. I’m the Head of Founder Experience here at Redpoint and really thrilled to have Astasia Myers, an investor from our early stage team, and Adam FitzGerald, the VP of Developer Relations from HashiCorp, joining us today for a spirited discussion on developer communities.
I’ll turn it over to Astasia.
Astasia Myers: Great, thanks, Travis. And welcome, Adam. You have an amazing background. You are currently the VP of Developer Relations at HashiCorp, but you also have worked in DevRel at large public companies. With nearly two decades of experience across different sized businesses, you have an incredible view of developer relations and developer marketing. Do you want to briefly introduce yourself?
Adam FitzGerald: Great. Well, thanks for having me, Astasia, and hi everybody. I’ve been doing developer relations for a while now. Hopefully I’ve learned a lesson or two along the way. I got my start in technology, basically in doing education, technical education, teaching people Java development and Java server administration, but that segued into becoming an evangelist myself for BEA Systems, and then I left there to join Rod Johnson and the SpringSource team as an early-stage company and built the developer relations function there.
We were acquired by VMware, so I worked at VMware for maybe four years on various different functions, specifically building the developer relations team around Cloud Foundry. We were spun out into Pivotal. I helped with a lot of the work there.
Then I left and joined AWS, where I worked for six years, leading the developer relations evangelism teams, as well as wearing a few other hats like startup marketing and enterprise strategy. Then I joined HashiCorp last year to put some structure around the developer relations program.
Sort of the through-line for all these companies is they’re places that really care about developers as the critical part of what enables their business, and I think that’s sort of the crux of it all. We’ve seen, over the last 20 years, how important the developer has become in being the anchor at which technical decisions are made, and so, developer relations is really just sort of the response to that trend in technical decision-making and finding companies that understand that and take advantage of that and see that is really important.
Astasia Myers: Awesome. So let’s jump right in. Starting with the basics, many people wrote in asking for clarity around the DevRel role. From your perspective, what are the various roles and responsibilities within the DevRel team?
Adam FitzGerald: Sure. DevRel generally breaks down into a couple of large-scale buckets. The first one is basically documentation and technical education, like telling technical end users how to use your product or technology. If you’re building a tool that’s going to be used by technical people, you need to tell them how to use it.
The second one is evangelism or developer advocacy. This is really a mechanism for elevating the messaging that you’re producing around your product or technology and then connecting with the community of users that might be using your technology. Then the other part that’s commonly associated with developer relations is the community/events side of things. Sometimes that’s hosting conferences or running events, or enabling meetups, or sometimes it’s working out what events to go to and sponsor and participate in, but those are sort of the three main buckets that things fall into.
You can have more nuance in places, for example considering what the developer experience looks like across your platform — so that’s some kind of combination of user experience and API design and things like that. Some people consider that to be developer relations, but it isn’t always. It kind of depends upon your organization, what sort of things you’re building, whether that makes sense to be developer relations, but truthfully, the crux of developer relations is those three things: documentation, advocacy, and events/community.
Astasia Myers: Awesome. Yeah, there’s a really great report from the WIP that recently came out, discussing these three buckets and the mix in which people spend their time in DevRel roles, so it seems like your personal experience mirrors most of the community.
Now, here’s lots of different types of dev-oriented businesses. Some have bottoms-up go-to-market, some have top-down. Some are a mix of go-to-market. Some are open source, some are closed. Do you think the DevRel role changes based on the go-to-market style of the business?
Adam FitzGerald: At its core, no, not really. Developer relations is mostly about helping developers or end users get their problems solved with your technology as quickly as possible. That’s the fundamental responsibility. And in that sense, it doesn’t matter what type of delivery mechanism or distribution mechanism you have for your product. You’ve still got the same kind of mission.
Where the difference comes in is when you’re thinking about what the mix of responsibilities are, how you’re being measured, how you should consider foundering responsibility for what people are doing, and so, those are the things that sort of change, but the fundamental mission is basically the same, and the fundamental functions are basically the same.
It’s just a matter of what is the mix, what is the most important thing, and usually, you can work that out by asking yourself a simple question, which is, what does a practitioner mean to my business? What does a practitioner mean to my product? What is the value of a developer?
Based upon what your business model is, your answers are going to be different. In a bottoms-up approach, for example, you’ve got a very clear idea. You’ve got some sort of sense of what their value is and whether they’re transitioning into something that’s paying a substantial amount or a recurring amount.
In a tops-down business, it’s much more like, well, we’re going to need a army of these guys that are on board in order to convince the executives in the business to go buy this product, so the individual value of a practitioner is much less important, and it’s more about the total volume of practitioners or total volume of developers that are using your tools.
It kind of depends upon what your business model is as to what the mix is and what the independent value is, but that fundamental mission is the same, regardless of what type of company you have.
Astasia Myers: Yeah, it sounds like there’s some consistency about the role, regardless of the go-to-market or product delivery mechanism.
Adam FitzGerald: Yep.
Astasia Myers: So you’ve been able to sit in developer marketing and DevRel, and sometimes, these are confused as different roles. So can you kind of flush out how developer advocacy is different from marketing, and kind of what is the ownership split there?
Adam FitzGerald:I would say this a little facetiously here, but the biggest difference between marketing and advocacy is the rate at which data comes into the company versus out of the company.
Marketing is largely about saying, “These are the things that we believe, this is the language we use, this is the position we have for our product. Now I have to go convince as many people as possible that that is true,” whereas advocacy is much more of a conversation with the end users. It’s like, “What is your problem set? Tell me what your problems are. How does my product address those problems? OK, how can I make sure this product is more accurately a solution to your problems, and if there’s a missing feature or missing capability, how do I take that information and put it back inside the product teams?”
That is kind of the fundamental tension or difference between advocacy and marketing, and advocacy’s kind of like a really strange word for it. Evangelism was even stranger when it was the popular word because it felt like you were preaching to people and trying to convince them to do things, where it’s much more about listening to people and taking that input and using it to adapt and improve your product to address exactly the problems that practitioners have.
Astasia Myers: Makes a lot of sense. There is quite a bit of difference between the two roles, and people should be thinking about how they interrelate, but how do you staff appropriately? We’re going to dig in, soon, about building your first DevRel program, but before we do, what are the three things any early-stage founder should know about DevRel when they get started?
Adam FitzGerald: There’s a couple of fundamental things. I think the first thing founders should do is ask themselves seriously, do they actually need DevRel. You can do the appropriate gut check by asking yourself two very simple questions.
The first one is, does your product or technology that you’re making actually solve a real problem that practitioners have? Are you building the technology because you’re excited about it or you think it’s super interesting? I’ve been in a company where we built an entire product that was just amazingly engineered but didn’t actually solve a problem that anybody really cared about, and so, it went nowhere.
It’s entirely possible to miss that sort of signal, so you’ve got to just ask yourself really honestly, does what I’m building actually solve a problem that developers have? If it doesn’t solve a problem that developers have, then you might be like, “OK, maybe doing developer relations is not the most important thing for me.”
The second question is, in the critical path of making my company successful, what is the role of the developer in enabling that success? So if you’re selling, say, an IDE or an integration tool or a CI/CD tool, it’s pretty obvious. You need an end user, and the end user’s probably the developer, and so, they’re really on that path.
But if you’re selling a tool to an enterprise that’s used at large-scale, then the question is, where is the developer in the critical path in that? You’re not going to make the decision to buy that tool unless you’re the CIO of a large Fortune 500 company, for example. In which case, what is the role of the developer, and you’ve got to have a really crisp understanding, saying, “This is what the developer actually means. We won’t get the CIO to buy this product unless the developers are on board with it as a product in technology,” for example.
If you can answer those few questions honestly, then you’re going to have a pretty good understanding about whether you need to do DevRel, and if you say yes to either of them, you probably need some kind of DevRel responsibility or function that operates inside your business.
The other important thing to take away is that developer relations is essentially a game about building trust with the practitioners you’re trying to reach out to. Developers, I don’t want to generalize too much here or stereotype, but developers are usually super analytical. They’re very, very thoughtful, and they spend a lot of time trying to sort of improve and automate and increase efficiency in the things they’re building and the things they’re doing.
In that sense, they’re kind of allergic to sales plays and pitches that are trying to convince them that solutions are all singing, all dancing, and can solve all their problems, and so, the way to build relationships with those types of individuals is to build trust with them, and you do that with consistency, repetition, reliability, honesty, humility, all these things that actually take a really, really long time to build up, and trust is sort of like the critical element of it, and trust can be very easily lost. So if you’re thinking about doing something that involves engaging with developers, you’ve got to take a long-game look at it. It’s got to be a through-line throughout the business for a very long time.
And then echoing back to what I said earlier, developer relations, in general, is more about listening than it is about speaking.
It’s about listening to the signals that practitioners and developers give to you about what you’re doing or what your product can do. It’s about listening to the way they use your product and adapt it and understand what that means for the way that you’re able to do things, and in particular, if you’ve got any kind of open source component to whatever it is you’re building, listening is incredibly important to understanding how that product winds up evolving and developing.
So just summing up, you have to ask yourself a serious question, do I need DevRel? And then recognize that if you’re going to do DevRel, it’s about trust. You’ve got to build and earn that trust, and make sure that you’re listening to the developers that are spending their time talking to you, because their feedback drives the product and conditions the future success of whatever you’re building.
Astasia Myers: Great. So let’s say I’m a founder. I have a good understanding of DevRel versus developer marketing. I’ve answered your two questions, and I’m thoughtful about the product adding value to the developer and them being part of the sales process. I think I know how to build trust. I am a good listener. Now, I’ve really got to start this program. At what stage in a company’s growth journey should it consider building a developer relations team?
Adam FitzGerald: That’s a great question. If you really are building a company where developers are the primary audience for what you’re producing, you probably don’t actually need a developer relations function very early. In the earliest stage of company formation, your first 20 odd people that you’re hiring, most of the things that you think about for developer relations can actually be achieved with the people you’re already going to be hiring. For example, I’m a big fan of engineers writing the documentation in early product development.
The founder or your CTO or sometimes your head of product can usually be really effective in your evangelism or advocacy responsibility. They’re out there selling the vision, talking about what needs to happen, listening to the early customers, understanding what they’re using the technology for, so that can usually be taken care of in that way.
Then, oftentimes, your community engagement is the same as just enabling your practitioners or developers or customers to be successful, so that can be done with your early support functions, your customer success functions, or even just with straight-up engineering feedback on public forums, commenting about how to use the product successfully.
For example, when I was at SpringSource, in the early days, every engineer had a responsibility to submit talks to conferences and answer questions on the support forums, and so DevRel was ingrained in the culture of the company. It wasn’t so much an individual responsibility for somebody.
At a certain point, you get to a place where those are side jobs for people in engineering or side jobs for people in product or side jobs for the CTO, and at a certain point, you’re going to get to this place where you need somebody whose main job will be to go do those things, and that’s the point at which where you might hire your first person that’s dedicated to developer relations.
And so, very specifically, I think it’s in that 25 to 50 person range, in terms of company size, maybe even bigger than that. I think, at SpringSource, I was roughly the 41st hire or something like that. I think about Jeff Barr at AWS. He was in the first 100 people at AWS.
You can go a long way by making it a primary responsibility for everybody in the company if the practitioner and developer is the central audience that you’re focused on.
Astasia Myers: It sounds like your guidance is to leverage the talent that you have on your team, up to the point where it’s a real pain essentially, so around 25 people plus, and then start thinking about hiring someone full-time for this role. I particularly like that because that allows engineers contributing to documentation and engaging with customers to have that customer empathy and even feel closer to their journey using the product.
Let’s say you’re at this breaking point. You have about 25 employees. What are the first developer marketing or evangelism roles to hire or build out?
Adam FitzGerald: There’s really two main possibilities. The first is, and the one that people sort of go to most often, and I think it’s related more to do with founder pain than it is to do with anything else, is you want to go get a developer advocate or an evangelist or somebody that’s going to be the face of your technology, somebody that’s going to go hit the conference circuit, do the public speaking, write the blog posts, and I think that’s largely because, for a lot of founders, it’s really hard to get those things done, as well as running the business and making the technical decisions about how products grow.
It’s entirely possible that’s a reasonable thing to do, and Jeff Barr is a great example of somebody that did exactly that on the AWS side and became the face of the technology.
Another place where you can have an awful lot of value is on the documentation side and having somebody that really understands how to phrase and how to create learning materials that help people get successful as quickly as possible.
Docs wind up becoming sort of this big anchor throughout everything you do when it comes to developer relations, and so, investing there early, usually is never a mistake. You see companies like Twilio, for example, always had phenomenal developer documentation, and that came from the very, very beginning. They had an army of evangelists, but they didn’t have anybody wound up looking like the face of the business in the same sense.
Jeff did that himself, largely. They are an example of going documentation first and doing it really well, I would say.
So those are the two areas that I would make sort of a recommendation for. I’ve seen it work really well on both sides. You don’t have to just follow the advocate /, evangelist kind of model.
Astasia Myers: Yeah. I work with two developer-oriented businesses, LaunchDarkly and Solo.io, and then, of course, I see over a hundred, probably, dev tool companies a year, and I cannot emphasize enough how much we are discovering that documentation and tutorials can make or break an early-stage company.
Just the ease of use, the clearness of the directions to get up and running can be a total game changer, so it sounds like we’re hearing the same things.
So you know you want this first hire. Some people are kind of curious about what are the right personas and qualifications are for a developer advocate, because people seem to come from a lot of different backgrounds. What do you use when assessing talent for a developer advocate role?
Adam FitzGerald: There’s basically three things. I would say, in general, the very first characteristic is, are they technically credible to the audience you’re trying to attract? And then the second thing that’s super important for an advocate is they actually need to care about not themselves, you get plenty of people that have got ego and think about themselves first. They actually need to care about the product or the technology you’re building, so, you want somebody that’s sort of passionate or excited about that piece of technology and is highly motivated by it. And then lastly, you want somebody that is humble.
There’s kind of a really weird tension, like the successful ones kind of build a colder personality about themselves.
Astasia Myers: Yes, they definitely do. I can attest to this.
Adam FitzGerald: Yeah. But what you’re looking for, from a manager or from a hiring perspective, is you want somebody that’s in it, not for their own ego, but they’re in it for the helping of other people.
I think one of my favorite evangelists or advocates ever is Josh Long, who is somebody I hired into Spring over a decade ago and is still the Spring developer advocate. He’s still the guy that talks about Spring everywhere, all over the world, and humble is exactly what he is.
He’s the guy that wrote one of the books about Spring, so he’s super technically credible, super passionate. He believes every day that people will be better using this technology if he could just convince them that was the case, and then he’s super humble. He still feels like he’s lucky to have his job even though he’s been doing it for a decade and is amazing at it. So, Josh Long is sort of like my perfect example of somebody that you’re looking for to become a developer advocate, and then Jeff Barr is kind of like the uber example on the other end of the spectrum.
You can often find those people in various different places, but the best place to look for them is inside your own community of users, and that’s exactly where we found Josh, for example.
Astasia Myers: Yeah, sounds like that really worked out, if you got him from the community and he’s still so passionate about it a decade later. It’s interesting, when you source for DevRel talent, you say from the community, so that could be mostly engineers. Are there other personas that people should be looking at for this role, and if you could possibly tease out the slight difference between this and maybe customer success?
Adam FitzGerald: Yeah, so actually, customer success is a pretty good place to go look for developer advocates as well. They usually get this sense of reward from helping people, and so, there’s an element there that can be really useful. The thing you need to double check on there is technical credibility and whether they’re willing to be visible in the way that you want for an advocate.
Sales engineering is a great place to go mine for people that have some real technical capability. There’s a lot of pressure in sales engineering in hitting quota or numbers and things like that, and some people that find that awkward or disingenuous are actually better fit for talking to the community because then they can be doing this purely to help people as opposed to advance a deal.
The people that are technically credible but slightly uncomfortable in sales engineering can be effective in advocacy. And then, occasionally, you get lucky and you find an engineer that has that combination of traits and willing to be outbound, that is super engaging and has great personality, in terms of public presentations, and you can transfer that skill there.
I will say, I’ve got a huge bias toward the technical side because I think other things about advocacy can be learned and it’’s usually faster to take somebody with the credibility and make them into an advocate, rather than take somebody that is just really friendly and turn them into somebody that’s technically credible.
Public speaking can be learned and practiced, technical writing can be learned and practiced, and customer engagement can be learned and practiced. You can learn and become technically credible, but it takes much longer, and nobody’s going to sit around waiting for you.
Astasia Myers: If you’ve kind of gone through this exercise, and maybe you’ve found a great person, but you’ve got to fit them into your org structure, and it needs to be logical so that they’re cooperating and working with their peers. Where in the reporting structure should DevRel sit, and does this change based on the stage of the company?
Adam FitzGerald: This is the question that I get asked a lot. My pat answer is it doesn’t matter. It really doesn’t matter where they sit.
Astasia Myers: It really doesn’t?
Adam FitzGerald: With the caveat that if your company has decided that developers are an incredibly important resource that you’re going to engage with in order to be successful as a company, then everybody should be interested in helping developers become successful.
I’ve run developer relations teams in engineering groups, in product groups, in marketing groups, and you can be successful in any one of those places, but from a much more pragmatic advice perspective, it’s a lot easier to say the best place to have your DevRel is underneath the leader in your organization that cares about DevRel the most, because they’re going to go help you win the arguments for the right resourcing for what you need to do to get to be successful for that audience.
If that leader happens to be the marketing leader, great, let’s do it in marketing. If it happens to be in product, do it in product. If it happens to be in engineering, do it in engineering. You can make it successful in any one of those situations, but you want to make sure you’re in a situation where you’ve got the leadership buy-in for the things that you’re trying to do.
But the bottom line is it’s got to be a company decision that this is important, because you can’t do developer relations as a tactic. You can only do it as a strategy. It has to be a through-line that you’re doing over and over time because otherwise, you’ll never have the consistency that allows you to build trust with that audience.
As long as you define the right interfaces between which groups are talking to which groups — how you’re talking to engineering and how you’re talking to product and how you’re talking to marketing — it doesn’t really matter where you sit, as long as you’ve got the right contract with them, and you’ve set up the right sort of shared goals.
Astasia Myers: That makes sense. So once you decide who the executive in the organization is that is most concerned about developer experience and users, sit DevRel with them and then the functions within that, once again, are the responsibilities of docs and education, evangelism and advocacy and community and events. But depending on where you put the DevRel team, they’re going to be collaborating with other internal teams. How do they do this? What are usual points of engagement?
Adam FitzGerald: In the early stages, when you’re a small company, less than 100 people, then it’s usually about personal interaction, so it’s like being at the right conversation, being at the right meeting, having the right relationship with your engineering leader or your product leader or whatever it is.
As your organization grows, I think it’s worth thinking about this early rather than later. It becomes much more important to think about it as not personal relationships but as a systems or an operational way of thinking.
I like to think of it as similar to APIs. So you should have an API into your DevRel organization that says, “You need x out of me. Make this request and we will deliver this many of x from this program.”
Once you think about it as a system like that, then you can be like, “OK. Let’s go ahead and take a look at the number of hours that I’ve engaged with practitioners about this product,” or “Let’s go think about the number of webinars or digital events I’ve delivered,” or “Let’s go think about the number of meetups that I’ve helped organize.”
If you think about it as building a system to run each one of those things, then your interface with the other teams is really just a way to make concrete requests into that process, and whether you use tickets or Asana boards or API calls or whatever else you’re doing, if you think about it that way, then you have a chance to move to a much more automated and efficient way in the future as your organization scales, rather than constantly depending upon personal relationships.
Astasia Myers: That makes a lot of sense. So let’s say we’ve set up our team. There’s two other aspects here that we want to cover. One is the actual execution of DevRel strategies, and two are the metrics and KPIs, which is another huge theme.
When you’re building out these DevRel strategies, is it different for open and closed source developer solutions, or is it the same strategy?
Adam FitzGerald: I personally think it’s very different. The first thing is, if you’re doing something in open source, that’s an immediate trust-builder with the developer audience. They can see the work you’re doing, they can see the code. They have the opportunity to go run your code themselves if they want, without having to talk to you about it, so the open source is an immediate trust-builder, and the people that you’re using to do open source development have to be willing to engage in public forums for the way that they interact with the community.
This is whether you’re responding to public issues or responding to pull requests or answering questions. You need a process for doing all those things, that you’re willing to do in public, and your engineers have got to be comfortable doing that kind of development in public.
Being open source is fundamentally different from being closed source. Having been at a company, VMware, where we took a closed source product like Cloud Foundry and moved it to open source, that was a really, really difficult transition for the people in that team, and there were plenty of engineers that just were not comfortable changing their development stance, operating in a public setting like that.
So it’s one of those things where I do think it’s fundamentally different in the way that you operate. In the background, you’re still thinking from a program perspective, how do I get developers to use my product, and how do I get their problems solved as quickly as possible, so you haven’t changed anything from your mission statement per se, but from the way that you actually operate, you’ve got to be a lot more comfortable having public conversations and engaging with the community in a way that’s different from the way you engage if you’re in a closed source organization.
You can be successful with both, there’s nothing wrong with being successful with both, but open source is a fundamentally different set of behaviors when you’re actually organizing and running programs.
Astasia Myers: So it does sound like it’s actually quite different, the strategy behind open source and closed source. It also is a reflection of whether the engineers you need to hire on your team are comfortable with the additional requirements in open source.
So people often say there’s like a chicken and egg problem here You want to jumpstart a community, but you don’t how, there’s only a few users. What would be your recommendations for how to kickstart a community around a dev tool?
Adam FitzGerald: There’s a couple of things here. Again, hopefully your tool really does solve a problem. If it solves a problem for people, then you want to find out who those people are. This is where the listening part really comes in. You want to find your most passionate user or customer, the person that’s found the most value in your product or technology, and then you want to elevate them, you want to lift them up, you want to put them on a platform or give them a place to go talk to other people about their success.
That might be inviting them to talk on one of your webinars or one of your livestream. It might be asking them to guest post on your blog. It might be just a mechanism for suggesting they’ll go talk at a third-party conference. Whatever it is, you want to kind of use that success from that practitioner as a way to go gain attention for the technology you’ve created.
It’s always really useful for the sort of power users or super successful users to give them a vehicle to communicate back into the organization, like having a private Slack channel for your most advanced customers is really useful. Giving them some kind of special treatment or extra swag is also kind of good.
You can form this into official programs. At HashiCorp, we have an ambassador program. At AWS, they created the Heroes program, you can have a champions program — whatever you want to call it, some program that allows these people to get recognized and identified.
That gives them sort of the endorsement that it’s OK to be talking about you, and there’s another part of this which is incredibly important to recognize, is that what other people say about your technology is potentially going to be more important than your own marketing.
If you can find somebody that’s using your product in a mission critical setting at a brand-name company, then you should be trying to find ways to get that person to help tell their story to as many people as possible.
One because they are instantly technically credible because they’re an actual user of your product. Two, they’ve got no skin in the game, so the developers might actually listen to them because they’re not marketing or developer relations, they’re actually an independent voice. And three, they’ve got some sense of authority about, this actually worked for me, this actually had real results.
The joke I used to make at AWS was Adrian Cockcroft, who was the chief cloud architect at Netflix, was the best evangelist that AWS never hired. He spent years running around the world telling people about how Netflix used AWS, and that made AWS more mission critical and reasonable for people to consider than anything that AWS did.
Now AWS eventually hired him, so we got there in the end, but before he was hired, he was possibly even more important than after he was hired.
Using this voice of the customer is super important when you’re trying to engage with developer audiences because of the credibility factor. So those are the places where I think you can help build community, and it’s a constant process of looking for those community advocates or community champions that are interested in talking about your technology, not because it’s going to give them a better job in the future, but because it’s the thing that they care about, or the thing they want to go communicate to other people, or they want to cheerlead the success of their own technology. That’s also why I love the explosion of engineering blogs across the industry right now because it gives you an insight into all these things that people are using, so look there first. Those are the people I go look for.
Astasia Myers: Yeah, I think that’s the main theme during this conversation — building trust, hiring people that are humble and that can relate to the customer to build trust and having them amplify customers and users to build trust with the product. That makes a lot of sense.
So the last two questions on strategy. First off, what have you found as being the most effective channels for reaching developers and building an active community?
Adam FitzGerald: Yeah, I mean, this one’s, I’m going to say it’s pretty simple, but the answer’s kind of really obvious, and if you watch any developer actually trying to solve a problem, the first thing they do is try to Google the answer. The first thing they do is take the stack trace, state the error message, take whatever the problem is and just Google it, find out what it shows up. And so, that means that your documentation is largely the entry point into your product experience for the vast majority of developers, and in particular, the long tail of your documentation is the entry point.
It isn’t the landing page, early navigation. It is, what did my stack trace show me, what did my error report show me, what is the problem that I’m trying to solve?
If you can create your documentation that’s centered around practitioner or developer problems, around the terms they actually search for, then that is going to be the best sort of entry point into your experience. Writing documentation that is search engine optimized is very, very important. Again, Twilio’s the quintessential example of doing that really well.
They really took a long tail approach to that, which is really clever. The other thing that I think is super important to realize is developers already have a community where they discuss and get information. You shouldn’t be trying to build any kind of walled garden that pulls people in and doesn’t let them out.
The days of the old Channel 9 MSDN approach from Microsoft just don’t work anymore. You need to meet developers where they live. That means, are they asking questions about your problem domain on StackOverflow? Are they commenting about it on Reddit? Are they discussing this in public forums that you can engage in? Meet those people there and answer their questions there, and that’s going to be much more useful for them than it will be trying to set up some kind of separate content system.
The same goes for that topic when it comes to events. Go to the events that are community and practitioner-organized. Go to GlueCon. Avoid the corporately-organized events that are designed around a company that makes money off of the attendees. Those things are probably never going to deliver the same value for you than the self-organized events for the things that people are real practitioners in.
There’s value that can be gained out of those third-party events if you know what you’re doing and you know what the audience is and how you’re going to go approach them, but in the early stages, if you’re just trying to win practitioners and get them on board with your product, they’re usually just not worth the spend, so try to get to the places where you know it’s a real community of users, and then you can get a lot more value while engaging in that channel.
Astasia Myers: Sounds like go where the experts are, go where the users are, and then, once again, harping on documentation. Keyword search terms being in documentation to help you with SEO, I really like that. That’s huge.
You did a perfect segue into the next question on strategy, any recommendations on how DevRel has changed during COVID, because in-person events are no longer happening?
Adam FitzGerald: Yeah. So when you think about sort of the big buckets for DevRel, whether that is docs and education, evangelism and advocacy, community and events, the one that’s most strongly affected by this is the events portion.
Your advocates have kind of, they’re like, “OK. We’re not going to go on planes and talk at conferences, we’re going to do it from our bedroom via digital channels.” OK, fine, there’s not actually that much change for them in terms of what the responsibility is.
Most of the large-scale practitioner events have already transitioned to a digital delivery format as well. We just ran our user conference a couple of weeks ago, HashiConf, and we got numbers that were way higher than anything we would’ve had if we’d actually ran the event in Amsterdam like we were planning.
So it is the actual operation of events that has changed dramatically, and you need to help the people that maybe see their identity as being an event organizer adapt this way of thinking about things. I’m really proud of the events team at HashiCorp because the way they’ve sort of approached it. After the fact, they realized, when they changed HashiConf from being this 1,000 person event in Amsterdam to being an event online that had 8,000 registrants, they were no longer running an event, they were running a TV show online, and they need to think about producing it like a TV show. Think about what the segments are, where you’re trying to draw people, how you bridge from one segment to another, what are the pieces that connect the sessions together, how do you make it engaging in the digital format, and they do some really clever things, like they had a digital swag bag for attendees with Zoom backgrounds and icons and stuff like that, that people could use.
They had a live DJ. One of the engineers is a DJ, and so, between sessions, they just streamed his setup and there he was, putting music up. They did other things, like have self-organized breakout rooms, allow people to go have those digital side conversations that you would have in a conference that are really, really hard to do on a digital platform.
So there’s lots of creativity that can be done there when you’re thinking about changing to a digital format. But you’ve got to remember, the people that have been running physical events are probably not as on top of these digital channels. You’ve got to give them a little bit of help there.
It’s helpful if you’ve spent any time doing Twitch streaming or YouTube live streaming or anything like that. It helps to have done some of those things and learning a little bit of OBS and those sorts of things can really make a big difference in the way you get to something successful, but that’s been the biggest transition.
Astasia Myers: Makes a lot of sense. Yep, that was a hugely successful conference for you and the team. We’ve seen the same thing with Failover Conf, which Gremlin hosted around the same time. Many more people signed up, thousands, compared to what an in-person event would be, so it’s a great transition to digital platforms.
We’re going to close out focusing on metrics. So, Adam, can you speak to the key KPIs or measurements of DevRel success at the early stages of a business, when you’re trying to achieve product market fit?
Adam FitzGerald: For the early stage, it’s hard to say that there’s a KPI. If you haven’t worked out where your product-market fit yet is, then the job of developer relations, in the greatest sense, is actually listening to that. It’s asking developers to tell me what part of your solution the product is, what problem we’re solving for you, and what’s stopping you from being more successful with it, so that I can go use that to adapt and change and retool the product in a way that makes it important.
Working out where people get stuck, where people abandon, why they aren’t using it in production, for example. So it’s mostly about conversation. One of the metrics you can use there is sort of just straight-up customer interactions. How many customers did you wind up talking to? How many people have you got real engagement from?
If you’ve got a docs-first approach, you can do productivity metrics for docs written and things like that, but really, if you haven’t achieved product-market fit, what you’re really trying to solve for is those inbound feedback pieces that developers aren’t going to tell you unless you ask them, so you’ve got to go find ways to engage with them, and that’s sort of the most critical part.
I think things get fundamentally different in terms of KPIs once you evolve beyond that early stage, once you feel like you’ve got a product that solves problems very specifically for a collection of developers or practitioners. Then you should be thinking about, how do you get people to a solution as fast as possible?
You can take a practitioner or a developer-focused approach to the pirate metrics that you’ve been using across the business overall, so what is my acquisition, how am I getting people to go try and use this product, how do I make sure they’re actually using it productively, what is their activation? How do I make sure they continue to use it, what is my retention? Are they telling other people about it, what is my referral, and are they converting into actual paid users, or is my revenue part of it?
Those are all reasonable things to task DevRel of having some kind of responsibility for, and so, usually, the DevRel team activities are affecting some part of that pipeline. So, you can measure that responsibility by uplift or change in individual parts of that.
Oftentimes, people sort of default to this idea that DevRel is about the acquisition piece, and I don’t think that’s true. There’s another huge part of it, which is the activation piece. Acquisition is, OK, yeah, you went to an event and you got 500 signups, but the activation is, did they actually do something with it? And a lot of that is conditioned on, what was the experience that you showed them that was relevant to them to help them become successful?
Was it related to problems that they really had or was it some kind of made up example of a coffee shop that doesn’t have any real business value? So make sure your examples that are driving for activation are things that really match up with the use cases that people have in the real world.
Similarly, retention can be a responsibility for developer relations, understanding things that draw people for repeated use and repeated execution of my product, some kind of natural reminder mechanism saying, “Hey, you’ve done x, y, z with the platform. Why don’t you do a, b, c with the platform next? That’s what other customers are doing.” So there’s a lot there that developer relations can really engage in, so I think it’s super important to sort of feed that into the standard way of thinking about product adoption for your tools.
Lastly, I’d say, once you get to a much more scale point of view, you need to start thinking about, am I getting efficient execution out of my DevRel team? This is really important for the business to think about as they’re trying to scale. You don’t want to be just the linear growth cost center for the business.
It’s like, oh, you want to do twice as much? It’s going to cost you twice as much in terms of people and program dollars. Certain parts kind of do operate like that, so advocacy generally operates very close to linear scale. You want to look for efficiencies there, but you’re never going to get beyond small incremental increases in linear growth that way.
The way you really want to go look is you want to go look for program elements that have the opportunity to have network effects. You can get super linearity beyond linearity scales, so you can get network effects and exponential growth, and so, this is things like community-based programs for user groups, this is referral mechanisms, this is champion programs that have self-induction, or how about content syndication programs, for example?
All those things have the opportunity to have an outsize impact for a small amount of growth, small amount of investment, and so, depending on what stage you’re in, there are different things you want to care about and measure on. But overall, you want to make sure that, at each stage, you’re thinking about measuring on the thing that makes the most difference for that stage and then keeping those things in mind.
The one part I kind of really dislike in DevRel is this kind of “metrics are hard” sort of meme in DevRel. No, metrics aren’t hard. People are just trying to work out, are you making a difference? And there’s a lot of different ways to do that, so let’s just make sure you’re in agreement with your stakeholders about what you’re being measured on, so then you’re measuring the right thing.
It doesn’t matter what the metric is. If it’s the thing that matters to your business, then you’re being measured on the right thing. Whether you’ll be able to actually change it or not, that’s up to your execution, but the definition of the metric is really a matter of saying, “Is this the thing that matters at this stage of my company for this type of journey I’m trying to take my practitioners on?”
Astasia Myers: I like that. So really, the metrics should mirror a lot of traditional business’ metrics around the lifecycle of the customer, depending on if it’s acquisition or activation, revenue, retention, or referral.
I know we’re at time, so I want to thank everyone for joining us today. I’m handing things back over to Travis now to close things out.
Travis Bryant: That’s right. Yeah, thank you, Adam, for joining us. Really great and a lot of key tidbits. Thank you both for a great discussion today, and we’ll see you next time.