Mike Stowe is a developer turned developer relations and developer marketing professional. He is currently the director of developer marketing at RingCentral and has built and managed developer relations and developer marketing programs for Constant Contact, MuleSoft and Tigera.
In this Hoss Hangout, we talk to Mike Stowe about how a company’s internal culture can impact developer experience, and the internal dynamics that can determine the success of any developer experience program. Mike offers practical tips from personal experience for companies launching, struggling with or rethinking developer relations and developer marketing programs.
- Mike talks about how important relationship-building is to developer experience. He says when you think of developers as relationships instead of sales leads, the benefits to the developer and to the company are mutual. [4:02]
- Mike says there are three common internal misconceptions about developer relations and developer marketing teams. [6:35]
- What Mike looks for in a new hire for a developer relations team (being passionate about the work is key). [8:25]
- Mike gives some tactical tips about jumpstarting a developer experience program for a startup or small company. [15:02]
- Mike says that during COVID-19, companies hosting virtual events aren’t competing against each other, they’re competing against family time and Netflix. [17:50]
- The KPIs that Mike things internal teams should pay attention to for a great developer experience. [20:36]
- Mike talks about how to get executive buy-in for underfunded or undervalued developer experience programs. [25:43]
- Mike’s parting thoughts: the importance of internal understanding between teams, integrity and being a good person. [32:55]
Matt Hawkins: We are excited to be joined by Mike Stowe for Hoss Hangouts today. Mike is the director of developer marketing at RingCentral and has previously built and managed developer relations programs at Constant Contact, MuleSoft and Tigera. So, Mike, thank you for joining, we’re excited to have you.
Mike Stowe: I'm glad to be here and thank you for having me.
MH: Absolutely. Well, let's dive right in. Something that we have talked about in the past, Mike. Is the importance of internal culture in terms of delivering a great developer experience, but oftentimes it's overlooked. So how important do you think culture is in terms of delivering a fantastic developer experience and what should a really healthy, productive culture look like?
MS: Well, I think culture is the absolute key to being successful in anything. And in a lot of ways, I mean, if you look at where businesses tend to fail or succeed, it's at the leadership level, it’s at the direction the company's taking. And it's the values that the company instills, you know, down the line. In terms of developer relations and developer marketing, you know, I think one of the most important things for us to remember is we're there to serve others.
You know, if you're an evangelist, your job is really to one serve the company in terms of bringing back information, product reviews, product requests, what messaging is working, what messaging isn't, bugs or issues, but also to serve the developers and make sure that they know about this great technology, that they're successful, that their voices are being heard, and you’re not trying to sell them something they don’t need or they’re not going to be able to use.
And again, it goes throughout the entire company of really that servant leadership of how can we serve the community? How can we serve others? And, we take that approach.
You know, you really try to create a systemic approach to that in terms of the company overall, so that everyone understands this is our role. This is what we try and do. And that everyone understands that we're focused on creating a symbiotic relationship that’s going to benefit the company, going to benefit the developers, and then hopefully that rolls over to the way that you collaborate with other teams where a team can come to you and say, hey, we know you're going to be there to help us. We know you're interested in the best interest of the company, and we're excited to work with you.
MH: Awesome. Those are some definitely some great tips and best practices. That makes a lot of sense.
So in terms of, you know, maybe for a new Dev Rel or DX team, or developer marketing, that's just starting, is it that team that should ultimately be responsible for that culture of delivering an exceptional developer experience? Or are they the beginning of that? Or how do you think about who owns that aspect of the company culture?
MS: That's a great question. Whenever you're building a brand-new program, one of the biggest challenges you have is that a lot of companies don't understand what they're really looking for, you know, in terms of a developer marketing or developer relations program. When I was at MuleSoft, you know, I would joke that you can ask 14 execs what they want and get, you know, 15 different answers.
So I think it really does have to start with you and that you have to level set expectations, but really define what that culture is going to be. And then that culture needs to feed throughout the rest of the company. You know, if your sales team, for example, looks at developers as leads that they're going to sell to and they're going to go do the hard pitch right away, then you're not creating a good culture. You're not creating a good experience. And then you're going to start getting complaints about, hey, I got this sales call or this sales guy that won't leave me alone – verses, yeah, I talked to so-and-so in sales, they’re super awesome. You’re your company. Can't use them right now, but you know, hopefully we can use it in the future.
MH: Yeah. They could miss that aspect of relationship building and that this isn't about, you know, those leads or deals this week or this month, or maybe even this quarter, it's about building up that community and those relationships for the long-term. And whether those turn into customers or not, at the end of the day, you're fostering that community.
MS: Absolutely. One of the things I love to say, it's a little bit of a tangent, so I apologize, but you know, leads are kind of like bottle rockets, you know, you get that instant gratification of poof, done, fantastic. But that's all you get out of a lead typically, unless you foster that relationship. There's a reason that, and I'm very big on this, that we call it developer relations, not developer leads. You want to build that relationship and foster that relationship. And that changes the complete context, you know, whether a developer uses RingCentral or doesn’t, I want them to know that RingCentral supports the developer community, that we're there to support them. And hopefully they'll see that we're good stewards and if they know a developer or know a company that could use a communication system like RingCentral, then they're going to recommend us. My belief is that’s far more valuable, both to the developer and to the company long-term than, hey, come buy our product. If not, we don't care about you.
MH: Yeah, I love that metaphor. I'm going to borrow that. Any other sort of practical tips, tactical things that teams should be doing, whether they're just getting to Dev Rel or developer experience, or maybe they have an established group and they're trying to rethink, you know, what their strategy is?
MS: Yeah. So, I'm going to pick on Rob Specter, who really did a lot at Twilio. He kind of created this three-core model of community, education and evangelism. And I think that's one thing that gets overlooked is we get so focused on the evangelism side and having, you know, a developer evangelist to go out in the community, that we forget how important it is to educate our developers. Not just on our own products, obviously we want them to know about that, but educate them to become, you know, really subject matter experts in their industry. Again, everything we do should be symbiotic. And then the last piece of course, being community, which is, you can do the best job in the world in terms of communicating about your product, but if they don't know you, if they don't know your company, if there's not a relationship there, then the next thing that comes along that does something similar, they go, hey, that's cooler, look at this. Versus, yeah you guys do this, but I know Mike at RingCentral, he's a stand-up guy, you know, RingCentral's never going to do anything that’s going to impact me negatively and I know that if I have problems or questions, I can give Mike a call or contact the tech support team and they’re going to handle it.
MH: Yeah. Yeah, no, I love it to kind of keep that communication, those airways open, so to speak. I'd be curious about your thoughts on common misconceptions in terms of the role of developer relations or developer experience. I’m sure there are a lot of them.
MS: When my fiancée met me, she didn't believe I had a real job. She’d give me a call when I was on the road and she’s like where are you? I'm like, well, I'm at a party, a developer party, the after party of the conference. And she's like, are you just like some frat boy that just goes around? But I think that there's a few different misconceptions. I think the first one is that developer marketing and developer relations is events. Events are certainly a key part of that. I create something called the developer hierarchy of needs, where it looks at what your developers need to be successful, and events is on that top pillar of in-person events, but it really comes down to making sure you have the right documentation, the right messaging, right onboarding process, that you have the right community that's welcoming and has ways for developers to be engaged that you have, you know, the education. And then going for things like webinars and et cetera. Um, So I think that's the second misconception.
The third misconception from businesses is that anyone can do it. There’s a lot of businesses that try to, you know, take a traditional marketing approach to developers. I think we've seen now that doesn't work very well and businesses have kind of skewed away from that. But there's a misunderstanding then of, who do I bring in? And a misunderstanding amongst, uh, new developer relations individuals – and I made these mistakes, by the way, by the handful – in terms of coming in and saying this is my role, this is what I need to do without understanding what the business needs are and how I justify the existence of my program to the business. Because at the end of the day, as generous and thoughtful as the company is, they still have to report back to shareholders or, you know, make a bottom line.
MH: Yeah. So one follow up question there. I mean, you mentioned kind of, who do you bring in? I'm curious, like, what do you look for as you're building a developer experience team and obviously, you know, there are various roles, but are there other maybe, uh, someone more senior who's going to, who might lead up some key initiatives? Like, are there any common traits that you look for or backgrounds?
MS: So when I look at someone, it really depends on the role. If I’m building a brand new program, one of the first things I do focus on is community, because I think community is such an important piece and, and making sure that the community knows that we're there for them. And by the way let me be very clear with community, it’s not our community, we’re part of the community. We’re blessed to be part of the RingCentral community, which is led by our developers, not vice versa.
MH: Important distinction.
MS: Yeah. I mean, it's like another mistake we make is we try to force people to come in versus, you know, go into where they are. Um, I look for someone who's generally a good person, you know, and this is for anything in developer relations. You want somebody who's there for the right reasons. Whether you're hiring a community manager or developer evangelist, if they're there to get their name out there, they're there for the wrong reason. I mean, as a developer evangelist, it’s great to get that face time, be the face of the company, get that recognition, but if that's your ultimate goal, you’re not going to be successful in the role.
Number two is someone who is curious, someone who wants to learn more because this space is constantly changing. Unlike, you know, I'm going to get myself in trouble here, but unlike, you know, an MBA program where you can go in and you'll get kind of the boilerplate template of this is what generally works, now go do it. In developer relations, it really depends on the company, things are constantly changing and there is no course you can go take that says here’s how you do developer relations today. So curious, wanting to learn, thinks strategically, uh, but the ultimate thing to me is passion.
You know, if it's something that you love, you're a good person, you want to do what's right, you're curious. I think those three traits right there tell me this person is going to come in, they’re going to work and they’re going to build something great.
A lot of that can be determined by what they did before. You know, you don't have to hire an experienced developer evangelist to have a very good developer evangelist. Um, but you want to look for somebody who's involved in the community. If they're doing talks, if they're, you know, sharing blogs, if they're, you know, tweeting and it doesn't mean a perfect combination of anything, but if they're already showing that passion, then what you're doing is you're paying them to do what they love. And when you do what you love, it’s not work.
MH: That’s it. Absolutely. I love the point about passion because the other thing about passion is it's infectious and it's infectious internally with other team members, other teams and stakeholders around the company who may have previously not appreciated the role of Dev Rel or DX, but also with your community.
And when you're passionate about solving their problems - and you can't fake passion either - you can fake it for like, you know, an interview or, you know, very briefly. But as you build those relationships, it's one of those things that just brings authenticity and it attracts people and it spreads like wildfire. So, man, I’m with you on all those. I think that is a fantastic list. I also certainly look for passion.
MS: Absolutely. Absolutely. By the way, if you ask my team, they'd also probably say a horrible sense of humor or a love of puns.
MH: That’s good. Number six on the list, for sure. Alright, so jumping over to community for a second, a bit of a broad question, but from your perspective, what is the role of community in delivering a great developer experience?
MS: So, if you look at any successful developer project, it's not the code that makes it a successful project. I've used a lot of libraries, a lot of frameworks where - I'm not going to name names - it's not that good, the code is not that great, but it has a strong community. And what that means is that I know I can use the software. It's going to be around for a long time. It’s going to be supported. And if I have questions, I can – if there’s not an official company behind it, I can ping other developers – if there is an official company behind it, I can still ping other developers because I’d rather post post on a forum or just, you know, message my buddy, like, Hey, what am I doing wrong? So community is really two things. It's a sense of belonging. It's a place that is theirs.
And for a developer, and this is my own biased opinion, I spent 15 years as a developer before people saw my code production and said, go do something else. Um, but no, I want to know that when I'm using a product, I can help influence that product. I can help, you know, say, this is the challenge I have, this is what I need it to do, and they're going to listen.
I have to have that sense of belonging that my opinion is valued by the company and I'll be heard. And then again, that really safe harbor of I have other people I can turn to for support. So I think those are the two most important aspects of the community. One, knowing that, you know, you're being included by the company and you're being recognized for your contributions for the company. And number two, knowing that you can turn to other people in the community for support and help. And by the way, I think that's one of the most important things is again, community and everything you do in developer relations has to be symbiotic, in that obviously we have things that we need to accomplish from a business standpoint. We have our game changer program at RingCentral, where we asked people to write blogs or share articles or help others with, you know, content or tutorials, whatever it may be, we in turn will reward the developers. So, we actually send them tangible prizes like X boxes, iPads, MacBook pros. Uh, we used to do an all-expenses paid trip on a cruise ship. Um, That used to be popular, but for some reason that one's kind of dropped off, I'm not sure. And then, also, you know, recognizing our top committee members. And so if you go to developers on the site, you can see here's the top 10 game changers that have been active in the community. But again, sense of belonging, and ability to really influence the product roadmap and know that they're really an extension of the company and vice versa.
MH: Yeah. Something else that you can't fake, right? You can't trick them into believing that they truly influenced the roadmap because very soon they will catch on that they don’t, if it’s not authentic. Curious, you know, a lot of our viewers are startups. We came out of Y Combinator ourselves. I’m curious if you have any tactical tips on jump starting a community. You maybe have a small customer base, you see the power of it, you want to embrace DX. You want to build and nurture. What do you do first?
MS: Start with your local customers. You know, you may have a small customer base, but if they're using your product, they love it, they’re already passionate. They're already ready to talk about your product. So, start with friends, family. I mean, it sounds very cliché, but as a small business or a startup, that is your initial audience that you have the most influence over.
And then don't lose sight of the power of content. You know, creating content, putting thought leadership out there. When you do that, you're actually telling the developers, you're telling your audience that I'm not asking for anything. And don't gate the content. Don't write a blog and then say no, you have to give us your contact information to read the blog because I’m not going to do it. But rather, you put that blog content out there and you're telling me I'm contributing to the community. Whether you support me or not, I'm going to support you, make this available to you. Look for ways to be involved in local events or local user groups. And that doesn't have to be expensive. That can be as simple as saying, you know what? We're going to host a user group at our office. I was at MuleSoft. We had a great space in downtown San Francisco. We welcome user groups to come in and host their groups at our office. You know, no charge. All it cost us was, you know, me spending a few extra hours late at night to learn about the technology I wanted to learn about anyways.
You can sponsor food, you know, you're looking at $200, $300, to get your name out there. But even if it’s just going there, sending your developers to speak, being involved in community projects. You're going get your name out there the right way.
And the most important thing, as you build this out, understand where your company's at. I've been at a stealth startup where we went out there and people are like, what are you doing? And we’re like you’re going to find out, it’s going to be super awesome, because honestly, I don’t know myself yet. But if you’re in that case you may not have to deal with the same things as the case of RingCentral, where we want to be part of the community, start supporting the community. But before we could start doing, you know, the real marketing efforts or the larger events, we had to understand that if we tell people about our platform before it's ready to tell them about it and they have a bad experience, that's actually harmful.
So as you're doing this, think about what stage you're at so you're conveying the right message. That can be, we just want to be part of the community and support you, we have something great that's coming, or we’ve got something out there that needs improvement and we're working on it, or we think we've done a great job and we’d love for you to check it out.
MH: Follow up question on events. You mentioned having a great space to host folks. With COVID everyone’s working from home, there's been a big shift to virtual events. Have there been any learnings on your end, in that transition, any best practices to share things to do, not to do?
MS: Oh, man. Uh, so first I'm obligated to say this, the first thing you should be doing is using RingCentral video for all of your meetings.
MH: Of course, definitely.
MS: Um, no, I think it's being cognizant that people's time is the biggest challenge right now. Virtual events are easier to do than a physical event. You know, the physical event, you have travel, you have set up, you have to make sure that everybody’s there in person, all the arrangements. With virtual events, it's kind of like, you can send it over email, saying let's do this. And the reality is when you look at your developer marketing and developer relations programs, you're not competing against other companies. Like, at RingCentral, we’re not competing against other telecom companies. We're competing against things like family, Netflix, spending time with the kids, you know, the baseball games, et cetera.
So, why should they attend your event? Make sure you have a strong value prop, make sure you recognize that. And then in terms of actually managing the event, make sure you do all the technical checks before. That's just the number one thing that people hate is somebody jumps on and wifi is bad. And it happens – I just had this happen to me where we had a speaker and their wifi dropped. But make sure that the software's set up there aren't any glitches, the audio is good and stuff before the session starts. And then try and make it as fun as possible because right now everyone's doing this same thing.
At our developer event, which was virtual, and ironically happened at the same time as two of our competitors’ virtual events, so yeah, great timing again. How do we differentiate ourselves? It was focused on, obviously, RingCentral technologies and how we support the community, but our community manager made “Where’s Ringo?” activities, where instead of Where’s Waldo, we have Ringo, our unofficial plush mascot. So you had to go find Ringo in between sessions and things like that, just to make it more fun, mix it up.
MH: Yeah, there's nothing worse than joining an event and it's exactly the same as the event you joined yesterday and the day before and the day before. Those little activities can be a lot of fun to break up the monotony. I love it. Great, great tips.
So, jumping over to empowering teams and specifically empowering teams with insights and metrics. Um, I'm really curious about your thoughts here, because there's a lot of stakeholders as we've talked about in delivering a phenomenal developer experience. What is your perspective on how you can empower those teams? What metrics and insights do you need to not only have as, as the core team leading this initiative, but really that need to be syndicated out across the company?
MS: So, this is a loaded question in a lot of ways, I’m going to try to break it down into a couple of different components. And the first thing is you have to have executive buy-in, um, that's an absolute must to be successful. And that also means that you have to have their trust and every place I've gone into, I've had to sit down and have a conversation and, you know, going back to the “14 executives, 15 different things,” it’s sitting down and saying, I understand this is what you're looking for, but what's the bottom line? Because if they're saying things like, oh, I want a hundred developers in the community or I want a thousand developers in the community, those are what I refer to as vanity metrics. They actually don’t mean anything.
And we see this oftentimes with API calls or monthly active users. What's that actually mean for the business outside of it's a cost center? So understand what their exact goal is long-term. You know, what do you want in a year? Where do you see this program going? Or what do you see this program driving for the company? And more often than not, it’s going to come down to revenue. We want, you know, developers using our API, so that increases stickiness, or they want to sell additional services or whatever it may be. Once you understand that, then you have to be very clear with them that this is what we're going to do. We're going to drive that. Now, you're not going to get everything you want in the process. You know, again, we, we can't do 15 different things. We can't have 50 different KPIs, especially KPIs that would contradict each other, but that's our end goal. That's what going to drive to. Now we're going to put together a strategy. Again, I think if you level set and say it’s not going to be exactly what you want, but it’s going to drive the end goal, a lot of executives are very open to that. Once you do that, you come up with a strategy, I think it’s important to have two different sets of metrics. You have your primary KPIs. Uh, and for myself, I like the developer journey or the stair marketing funnel for that, where you have interest, awareness, consideration, adoption, and advocacy.
And the reason I like that is because it lets me measure every step of the funnel if I'm doing my job. If I see people have interest through website traffic, for example, but nobody is creating a sandbox account, or considering using us, then I need to fix that part of the funnel. If I’m seeing a lot of people creating sandbox accounts but nobody’s actually using it in production, I have to understand why that is. So that’s why I like that funnel. So having your primary KPIs – those are really going to be the KPIs that drive your program overall – and then those can roll into things like revenue. The secondary KPIs though, and I’ll get myself in trouble, I think we have over 170 KPIs that we track at RingCentral. Now, I’ll be very clear that I don’t look at 170 KPIs every day, I don’t care about 170 KPIs. I have my six that I care about. But we have KPIs for our social team. So if we look at Twitter, those might be things like number of impressions, number of engagements, number of clicks, et cetera. When we look at blogs – number of reads, number of shares, number of comments. When we look at the platform – number of new accounts, number of sandbox apps, number of apps in production. So we really break it down, one at the high level so we can see what’s working or where we’re going in the funnel, and then secondly into the different components that if we say look, we got an issue in the adoption area, I’d go look at the adoption metrics and say ok, here’s the key metrics, where’s that blinking red light that needs to be fixed? But I cannot emphasize enough that while you have these metrics, what you do has to roll up to the company’s goals and objectives.
When I joined – and actually I’m going to pick on almost every company – almost every company I’ve joined with the exception of one – thought developer marketing was, oh yeah we have developer marketing now, yay, this is exciting. They don’t actually do anything, but we have developer marketing.
MH: Right, check box, done.
MS: Exactly, check box, we’re good to go. And without having those metrics, especially if you’re reporting to a marketing department, marketing is not just metric driven, but revenue driven, where every dollar they spend they have to bring in X more dollars. So if they look at you and say you’re just a cost center, you’re not accomplishing anything, and you’re part of marketing, then you almost become the castaway or the black sheep of marketing. And again, that’s something I’ve experienced in almost all of my programs initially, is we don’t understand why you’re here, what do you do? But by building these metrics and KPIs and saying here’s what we did with this, and the first year it’s going to be mostly vanity metrics. We have, you know, a hundred thousand developers. That’s a real number I can latch onto. But then you turn around and say, and we have $50 million dollars of revenue – and again I’m making up numbers here – so for a startup that might be, we got $5,000 our first year. That’s when they’re going to start really seeing the value and going yeah, we support this because not only are you making it successful, but you’re driving revenue or driving customer adoption.
MH: For sure. What would you say to teams that might be underfunded – their programs are – and there’s resistant executives, and the teams don’t feel like they have that buy-in? It sounds like a first step would be making sure that your KPIs aligned to bigger company goals. Any other advice that you would give them in terms of maybe how to approach those executives, what to present, how to really rally that C-suite into getting more funding so that they can produce and actually show quantitatively that this developer experience program is well worth it from a bottom line perspective?
MS: Uh, so the first thing I'd say is welcome to the club. We’re so happy to have you. RingCentral has been very supportive, I don’t want to mislead anybody on that, RingCentral’s been fantastic to work with. But no, I mean, almost any new program, almost any department or organization is going to feel like they're underfunded. They don't have the resources they need and, you know, the larger the company, the more of a challenge it oftentimes becomes, uh, because you're vying for the resources. Every company has to look at it and say, we have a finite amount of resources, a finite amount of capital, where do we invest that?
So one is understanding that, as important as developer relations and developer marketing is, I’m the biggest proponent of it, it may not be the highest priority because it may not be the thing that keeps the lights on currently. So maybe we have to invest in our sales team, we have to invest in marketing, or with demand gen. So that’s what we lose sight of sometimes. We keep thinking hey we need this money, we need this money – and my view, by the way, changed very quickly, when I went from being a developer to developer relations, there was so much learning. Developers are like I don’t want to talk to the sales guys, they’re going to try to sell me stuff and I don’t want to buy anything – I just want to write code and leave me alone and I don’t like meetings. As a marketer, I’ve had to learn to like meetings because that’s 9-5. But I’ve also realized that the sales team is the reason I get paid at the end of the day. Whether you’re a developer or in customer support, if the sales team’s not selling, you’re not getting a paycheck.
MH: For sure. You’re in big trouble.
MS: Exactly. So understanding how you can support that. Number two is understanding who holds the purse in the company. You have some companies that are product-led, but most companies are led by sales and marketing. Sales and marketing typically are the two most powerful organizations in the company. So if you report to product or you report to biz dev, which is fantastic, but it really depends on who the most invested stakeholder is for your program. You should be courting with sales, you should be courting with marketing, how can we support you, how can we enable you, let them see the value. Number three is that metric. You know, companies, most executives are pretty smart, and they like to spend money that’s going to make them money. And so if you can demonstrate, this is what we do, here’s the goal and we’re going to hit it and I can use the budget that you give me this year wisely and effectively, they’re going to give you that budget, let you test it, and they’re going to see that you’re successful and be willing to give you more money and invest more.
I think one lesson that completely surprised me and threw me off is that you have to allow for pain points to exist. And that’s hard for me, because I want to build this program and I want to be successful, and I don’t want anything to fall between the cracks here. But a lot of companies, if they see it’s successful, they say, you know, it’s funded, it’s good to go, we don’t need to double down on this, they’re meeting expectations. And that’s a lack of knowing where it could go, what the opportunity is, and who needs help. This department’s fallen through the cracks, they’re struggling, we’re going to support them. I was working 100+ hour weeks at one point, the joke became how many all-nighters did Mike pull in the office? And I’m not going to name the company, but just going back to this point and driving this home, I ended up saying look, enough is enough. You guys aren’t giving me support or help, I’ve gotta go. And I left and they hired a new individual to replace me, and the next thing I know is they had five more open roles for the team.
MH: So it took that hard lesson of losing you to realize that you were doing the job of essentially six people or more and it was really underfunded.
MS: It did, but vice versa. I mean the difference between the new person and me – and this is not a shot at them because I should have done the same thing – they walked in and said, yeah I’m not doing all this. I’m not putting in a hundred hours a week. I’ve got family, kids, you know, good luck with that. And that’s where you do have to let those pain points be known. And I’ll give RingCentral a lot of credit because we’ve grown the team fairly quickly at RingCentral compared to most programs, but you going in and saying look, I’m going to do this for a month, but after that, this thing’s going to fall off and we can’t maintain it. Then the executives will have to make a decision – is this important or not? Sometimes that also means letting programs fall. One of the hardest things that we did was we let our program go basically for two months without really being managed because the company didn’t see the value in it. They came back and said why did all these metrics fall? They said, we don’t care what you have to do, here’s the money, get it done, get that program back up and running. So sometimes they have to see the pain points and feel the pain points, which is unfortunate.
MH: Yeah, that’s a really, really excellent point. It’s those pain points of maintaining and building an excellent program, and then also to communicate and show the vision of where this could go. Hey, if we could get X amount more investment, this is where we’re ultimately taking this. It’s not just something that’s sort of on autopilot even if it is well funded.
MS: Yeah, again, the two biggest mistakes you can make from developer relations – one is not meeting your goals at all and just having a program that fails completely at launch, and the second is everything goes too smoothly. I mean, ultimately, that’s what we want, but it can hinder your growth.
MH: Yeah, there’s some healthy tension in there. Well Mike, you’ve shared some amazing advice here, some very practical tips for teams out there. Really appreciate it. Any parting thoughts, words of wisdom, anything else that you’d like to share? Also, if folks are interested, how can they find you on the web?
MS: You can find me on the web at mikestowe.com and on Twitter @mikegstowe. I need friends, so please follow me. In terms of parting advice, there’s a few things I’d throw out there. One is if you’re a developer going into developer marketing or developer relations, remember that almost everywhere you go, everyone wants what’s best for the company. They’re going to try to do what’s best for the company. So if they don’t understand the value that you bring, or what you’re saying or your mindset, take time to explain it to them, and also understand that you probably don’t understand where they’re coming from or they value they bring or their mindset. So, don’t jump to conclusions. That’s a mistake I made early on. I was like, I’m going to build this great program, and I didn’t understand how important every other piece was in that process. Number two and most importantly, be a good person. When you look at developer marketing developer relations, it’s funny, there was a report done on what’s the most important characteristic for somebody in developer marketing developer relations? And by far and it wasn’t even close, the number one answer was integrity. Be a good person. Be honest. Be upfront. You’re not a salesperson, you’re not selling snake oil. If you don’t believe in the product, push back on the product team or go find a company that you believe in. That might be easier said than done, but you’re staking your reputation to support the company and the company is relying on your reputation for their growth. So, be a good person and follow the golden rule.