Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.

Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That’s snark.cloud/logicworks

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Taylor Barnett, Staff Developer Advocate at PlanetScale. Taylor, you’re one of those people that I’m ashamed I haven’t had on the show before now. Thanks for joining me.

Taylor: You’re welcome. Yeah, I’m glad to be here.

Corey: We’ve been traveling in similar circles for a while now. And I lost track of a lot of those areas when the pandemic hit, you know, the global plague o’er the land. And during that time, it seemed like there was a lot of question that folks had about what is developer advocacy. What does DevRel become now? And now that we’re largely on the other side of it—at least business is pretending that we’re behind it—do we have an answer yet?

Taylor: I hope so. I mean, I have an answer. Not sure if other businesses have figured that out yet. But no, I mean, to me, advocacy is still just that glue between company and a community. But I think one of the things that the pandemic has really, like, pushed that, you know, when there were no in-person events, was that it questioned what activities that actually looks like.

You know, I see advocacy as a ton of different levers and you can tweak those levers to different levels. Before, it was largely a lot of in-person stuff—I will say I was doing less in-person, actually before than most; I was doing a little bit more content—then it had to become so content-focused. And I think now we’re in this awkward place where in-person events have come back and we’re still, like, figuring out, like, how do we do those? What does that look like? And we’ve actually—I think part of it is we’ve over-indexed now on content.

I think part of that is because it is visible and it is measurable, and that’s always a big topic [laugh] in developer relations is metrics. But also, I think we’ve lost track of the actual advocacy part: how do we actually advocate for users internally? It’s just disappeared a little bit because we were so content-focused during the pandemic.

Corey: I would say that’s been a recurring theme with every DevRel person that I’ve spoken to that metrics are the bane of their existence. And I want to be clear, I’m not just talking about developer advocates, I’m talking about people who manage and run developer advocacy teams, I’m talking about executives who are trying to bring the appropriate context to strategic-level discussions around these things. All of the metrics that I have been able to uncover are wrong. But it’s like the, ‘all models are wrong, but some models are useful’ type of approach, where—

Taylor: Yeah.

Corey: Every time you start putting a metric around it and measuring people based upon the outcome of that metric, it ends in disaster. My one and only interview for a DevRel job in my past was my question for them was how do you measure success? “Well, we want to see you have talks accepted at some of the big tier-one conferences.” And they list a few examples, and it’s, yeah, “I’ve spoken at for the ones you just listed in the past year, so… do I get a raise?” It’s one of those areas where there’s no right answer, but a lot of wrong ones.

Taylor: Yeah. And one of the other troubling patterns that I’ve started to see also more is that in these cloud startups, they have DevRel programs now that are fairly young, we’re talking not even a year old. Some in the recent DevRel survey results, it was about, like, 29% of programs are less than a year old. Within those programs, 43% of those people have not even been in a DevRel role for more than a year. So, not only do we have folks that haven’t done this before, the startup has not done this before.

And so, the metrics conversation is basically a shit show. People with the right experiences aren’t in these roles and so they’re not able to craft strategies and actually look at good metrics. And so, then we then over-index on the things like, “Oh, you wrote a blog post.” Great, you know, that’s, like, some kind of metric. “It got X number of page views.” Great, that’s some kind of metric.

And it often incentivizes some of the wrong things. And so, then it just incentivizes more and more of this content creation, to just get those pageviews up. And it’s scary to me because then we’re just going back to the more evangelist type of developer relations and less of the advocacy type stuff where we’re actually advocating for users internally.

Corey: I would agree. I’d say that there’s a problem where we have a, almost across the board, lack of understanding about—let’s even start at the very beginning of when DevRel is required or when it’s not. I mean, take where you work now at PlanetScale. You’re effectively managed Vitess-as-a-service. That’s a little on the technical side and is not the sort of thing that’s going to necessarily lend itself to a mass-market marketing approach.

This is not something to put on billboards outside of most highways, for example, but it does require engaging with people on a technical level. I keep joking but also serious when I refer to DevRel as meaning you work in marketing, but they’re scared to tell you.

Taylor: Yeah. No, I mean, I actually sometimes say, “Well, like, I’m secretly probably a pretty good product marketer, but I don’t want developers to know that because then I’ll lose my street cred from my actual development and engineering background.” And I have a computer science degree and, like, I’m actually, like [laugh], very, very technical. But the reality is, like, you know, somebody’s got to write the words, sometimes.

Corey: The words are harder when they go into people then they are into computers. At least with computers—

Taylor: Exactly.

Corey: It’s pretty—it’s a bounded problem space to some extent. With people, oh no, no, there’s no consistency at all.

Taylor: Yeah. And like, words mean different things to different people, especially, like, my favorite one lately is, like, what does edge mean? Nobody actually has one [laugh] definition of that word.

Corey: Oh, I think most of them do. Edge always means, “Oh, it’s a way of describing the thing that we’ve been doing for 15 years, but now want to sell into a hype cycle.”

Taylor: Yeah, yeah. I mean, CDNs have been around for a while. You know, and that’s really—like, what PlanetScale, it is, in some ways, we’re challenging what people expect from their database. We think you can actually expect more from your database platform, and so there are things you know, to teach people about some of these newer ways of working with a database. And that requires needing to think about how we present that to users, but also hearing back from users how do we work within their applications, their stacks.

We’re MySQL. That’s, you know, a trusted standard. It’s been around for a while, so it works with many, but also, we’re in this whole new paradigm of how to use a database. These are all new ideas and they require both a two-way street of both putting things out there—so content, not bad; it’s still needed—but also things coming in and taking that, making it actionable, and talking about it internally.

Corey: When you take a look at the DevRel world, what do you think that most organizations are missing or getting wrong about it? And yes, I understand that I’m basically asking you to start beef with a whole bunch of companies out there, but that’s all right. It’s what we do here.

Taylor: Yeah, one of the things I love, [Matty 00:07:44] Stratton had this thing where I tweeted out a few months ago that we’ve over-indexed on content, and matty’s reply was that we’ve over-indexed on being able to do cool shit that isn’t connected to revenue because that somehow is dirty for DevRel to somehow be connected to revenue. I think, you know, a lot of times, there are ways that we can look at how do users actually get value from our products. Like, are they actually getting value? One way they express that is by paying for it. So therefore, we are then somehow connected to revenue.

I mean, I want to build things, I want to work on platforms that deliver value, that people actually want to pay for because they see this is makes my life easier, somehow. But to do that, and again, we’ve got to talk to our users. We’ve got to figure out where do they actually value. What are the things that are just fluff? There’s a lot of fluff out there.

Sometimes if we don’t listen to them, then we don’t have to find out that what we’re building is fluff. So, that’s probably the part that could start some beefs. But it’s the reality of lots of VC money and tooling and being able to build things super easily, it’s a bunch of different factors coming together in this time.

Corey: One of the things that I don’t pretend to understand, but I’m going to roll with it anyway, is there’s been a lot of discourse on where DevRel does not belong in an org chart. I don’t have a terrific answer at this, but I do know that most of the answers I get from practitioners in the space are deeply dissatisfying. It seems that—not to be unkind or cast aspersions where they don’t belong, but whenever I ask the question, everyone has a whole laundry list of wrong answers and very few right ones.

Taylor: I honestly will say I don’t care [laugh]. I mean, that’s the reality.

Corey: Corporate IT. Got it.

Taylor: Do I want to be on a team that makes me directly responsible for qualified leads? No. That does not necessarily say anything about the team itself. That is just a metric. That is—you know, and that team exists in a larger system that has put certain pressures on it.

Like, you know, there’s, like, things, like, it’s more about how a team looks at just doing the DevRel stuff and doing marketing in general, or how they do sales. You know, I know lots of developers hate to hate on sales—marketing, too—and I don’t necessarily think sales and marketing are a bad thing, I think is the way we incentivize those roles create bad behaviors, and so maybe we should look at how we incentivize them. And so, I don’t care what team I’m honestly on most of the time. I’ve been on a few different ones. As long as I get to do the developer advocacy work that I actually think is impactful for developers and actually making developers' lives better, I’m cool.

Corey: It’s my belief, on some level, that it’s very easy to internalize a bad expression of it. You can have phenomenally well-empowered DevRel teams working in marketing—

Taylor: Yep.

Corey: —at some companies, and in other places, it can be an absolute disaster because they start putting metrics like number of qualified leads around you. And I can’t shake the feeling that people internalize, “Well, we’ve reported marketing once and it was terrible,” without realizing the context of yeah, but in a terrible way, and an org that didn’t really understand what you do. That doesn’t necessarily mean that you should throw that whole baby out with the bathwater.

Taylor: Yeah, I mean, we’ve all had bad managers. So, we’re not going to say we’re just never going to have a manager.

Corey: Some people try that.

Taylor: Is that what you’ve done [laugh]?

Corey: Indirectly. No, I was talking about more about the holacracy companies where oh yeah, no one reports to anyone. It’s really? Because everyone makes different amounts of money, so one wonders about that.

Taylor: Yeah. But by far, we just go find better managers is what we often do, you know? And there’s the whole phrase that, like, people don’t leave companies, they leave managers. It’s very true in my experience. And we don’t just say, “All marketing teams bad, so I’m never going to join a marketing team.” We should say, “Let’s just go find one that fits better.”

Corey: I was very frustrated in my last couple of real jobs because so much of what I was doing was DevRel-like, but this was before that was an established and accepted thing in the places that I worked, so there were questions like, “Well, what is the value of you going to give a keynote at this conference?” And the honest answer was, “Yeah, I have no idea how to quantify it, but I know that if I do it, good things come out of it.” And that was a difficult battle to fight, whereas now when I decided to go work for myself, it’s, “Yeah, I’m going to go speak there. I don’t know what the ROI is. I know good things and maybe some useful things will come out of it. Maybe I’ll learn something, but this is how we experiment and learn.” And that looks an awful lot to most traditional management types. Like I’m trying to justify a trip somewhere.

Taylor: Yeah. And I think, you know, what’s been also interesting, as I noticed, some people are starting to notice a lot of more junior people wanting to get into developer relations. And we sometimes actually are wondering, some of us in developer relations, if we’ve not always shown like the negative parts of that. What happens when you go do that keynote? What does that mean for your week leading up to that keynote? What does travel look like? What is, like, running across an airport wearing a mask and carrying your luggage look like?

I think we don’t always get to see that and so it looks a little bit less glamorous when people see that. And maybe they would be slightly less interested in the role or just, like, how do you handle working with, like, five different teams across a company to try to be like that glue piece between all of them to get something done? Like, there’s a lot less glamorous parts that I’m hoping more people talk about because, like you said, it just looks like you’re trying to go get a trip somewhere. I think the other thing is, like, even if you are having a keynote, I think one of the things that some people—they think one keynote is going to just wreck a budget. The reality is for our business, it will not do that, so why can’t we, like, have a better balance of extremes?

Like, you’re not going to be giving ten of those keynotes in a year, maybe experiment doing two and see what comes out of doing two of them. But the other thing is, it’s a long-term game and so you’re not going to see something maybe the week after. It could be six months later. I had this one experience where someone actually told me—it was probably, like, a whole year after I had given a talk—that him and his teammates—this was back when people you know, went into offices—sat in an office and watched one of my old talks together. And I was just like, what, like, y’all, like, got together and did that?

Corey: Yeah, you could have invited me and I could have delivered it for you in person and answered questions, but all right.

Taylor: Yeah. It was like, what I was just like, oh my gosh, that is literally never happened to me. This was a few years ago. And then, too, I was like, that just made it worth it. If you asked a CEO, would you like to have an advocate go give a talk for a whole team at a company, they’d be like, “Yes, I want you—” especially if that’s a big company and the name is shiny and they would love to have that as a customer, they would be, like, a hundred percent, “Go give that talk.”

And so, I think many times, leadership needs to actually kind of check in on, like, is this really that much of a cost if it’s just, like, one keynote? I’ve seen battles over really feels like stupid things sometimes. But everything in moderation is kind of the way I approach it.

[midroll 00:15:17]

Corey: One problem that I tended to see and I don’t know how closely your experience mirrors my own, but it seemed, especially in the before times, right before the pandemic hit, that we were almost trapped in a downward spiral at a lot of the conferences because it felt like it was mostly becoming DevRels speaking to DevRel. And that wasn’t the most inclusive thing for folks who used to wind up going to a lot of local conferences to learn from their local community and see how other people were solving the problems that they were solving. Instead, it felt like a bunch of DevRel types getting up there, in most cases giving a talk that was heavily alluding to why you should buy their product, if not an outright sales pitch for it. And it just felt like we’re losing something. Do you think that’s something that we’ve avoided, that we’ve pressed pause on, with the pandemic and now the recession, or do you think there’s something else afoot?

Taylor: I think that’s still happening today, especially with, like, engineers wanting sometimes to travel less, you know, some people still have personal and family reasons for not traveling, so even less of them are wanting to speak. I don’t think I saw, like, a huge swath of engineers, like, really excited to speak once conferences started in person again. They thought, “Oh, my gosh, I have to go talk to people in person again?” And so, it’s still happening. I’ve seen it from an organizer’s perspective.

I used to organize the API specifications conference. There’s tons of DevRel submissions in there, so you know, we really tried to spend time reaching out to companies that were member companies of the OpenAPI Initiative and get them to actually have member engineers from their teams come speak. I think DevRel has a role to internally advocate for engineers who are doing the day-to-day work, go speak at conferences. You know, I think many times engineers feel like, “Oh, what I have to talk about is not very interesting.” And I have to tell them, it is very interesting, and I would love to have you speak, and I’m here to help you, and you know, need help writing a CFP? I’m there. You need help putting together slides, practicing talks? I’m there.

And I think DevRel can be kind of like these coaches for folks to go speak at conferences because the reality is attendees want to hear from them. They want to hear engineers from especially major companies or companies just doing really interesting engineering challenges speaking. And I think DevRel has a part in helping that happen. I’ve personally backed away from speaking the last six months, partially because I’m kind of not seeing as much value for myself doing it before I was doing a lot more, so I’m using that effort to try to advocate internally to help people CFPs. Last week, I helped a bunch of people KubeCon submissions, and then next week, I have other conferences I would love to—I have engineers that I’ve kind of picked out that I would love to have speak. And yeah, I’m glad to play a part in trying to improve that. And I think other advocates should, too.

Corey: Where do you think that we’re going as an industry? Because it became pretty clear for a couple of years that so much of what we were doing and how we were discussing it, it felt like there was a brief moment in time that we could really transform what we were doing and start to have a broader awareness that DevRel was more than giving talks on stage at conferences. And it feels like we squandered that opportunity and it mostly turned into, oh, now we’re going to give the same talks, we’re just going to do it to webcams, either pre-recorded—which was the better approach—or we’re going to do it live, even though there’s no interactive component to it, just introduce a whole bunch of different failure modes. I was disappointed. I liked some of the early stuff I saw coming out, like Desert Island DevOps, where they did it inside of Animal Crossing. Like I wanted to see more stuff like that, but it just seems like we didn’t.

Taylor: Yeah, I mean, the reality is, I think a lot of the online events have disappeared a lot in the last three or four months. And we’re also seeing events trying to be hybrid. To me, a hybrid event is, like, throwing two events. Do you have an organizing team that can actually handle two concurrent events? It’s hard.

And API Specifications Conference, we did two years in person. Pretty niche conference. It’s like the API nerds of the API nerds. And so, we still had pretty engaged attendees because there weren’t any other sources of this, but then when everyone was starting to do the same content, attendees started checking out. They got tired of sitting in front of their monitors and watching talks.

You know, we’re seeing things coming back in person. I think it’s going to be very interesting for the Spring because the Fall for me, it was probably one of my busiest conference seasons in terms of us just also sponsoring things. And I’m unsure of the return on investment today. We will see over time how that return on investment comes out, but I think it’s going to change the way we look at the Spring, it’s going to change the way we look at next Fall, and I think other companies are having the same conversations, too. And so, it’s going to be like, okay, what do we do instead if we don’t focus on conferences? I don’t know. For me, that’s focusing on the actual advocacy part, the user feedback, talking to users, building a product that people find value in. But for other teams, their team might not be in the place to do that. They might be expected to still produce this content in different ways, in-person, written, online.

Corey: So, one of the burning questions that I think is not asked or addressed particularly well in the space has been, how do you get users to trust you? And to be clear, I am not saying you personally. It’s like, “Well, given your history of flagrant lying and misleading people and scam after scam after scam, that is honestly impressive—” No, no, no, none of that. It’s how do you—the indefinite you—build user trust?

Taylor: Yeah, I think this is something we’ve seen, lots of companies of all sizes really struggle with. You know, the obvious thing I think many times companies think of is like, oh, if I’m open and transparent and have great docs, users will trust me. You know, I think that’s part of it. I think the other thing that many often forget is that you need to listen to them, you need to take their feedback that they give you when you ask questions—and there’s a whole, like, asking questions; I’m learning myself, like, how to ask better questions—how do you then make that actionable internally?

You know, you have to understand who makes product decisions. Who do I need to talk to about this feature versus this other feature, and there’s all these internal dynamics that you’re then wading into. So, you have to get good at that. And then when you finally actually get some kind of change, whether that be some small paper cut of a thing related to a feature, or a big feature that you release, you actually go back to the user and you tell them, “Hey, look, we did this.” And what blows my mind is I do this, I take notes on who told me what feedback, and when that issue gets closed out, I go back to them and they’re just shocked that I replied. They are shocked that I actually followed up. And to me, it’s like such a basic thing, just following up. Doesn’t seem, like, that hard.

But it actually is hard but also useful. And you know, I think we’ve seen this so many times. We see—this is one example that I think about a lot, and I think you’re familiar with this one too, Corey, the Aurora Serverless Data API in V1, people loved that. Then they came out with V2. There was no data API.

And if you search that people are upset everywhere. And AWS keeps on telling them, “Nope, it’s not going to happen.” And it’s like, it’s such an easy win if they actually listened to the user base. But there’s countless examples of this, you know? There’s things that we do at PlanetScale that we could improve on, you know, that users are telling us.

There’s only so much time in the day, but I think part of an advocate’s job to wade through this feedback and figure out where can we bring the biggest value and the most impact. And, you know, I think all companies could benefit just from listening more and doing something about it.

Corey: I wish that were a message that would get in front of the right people to make them a little bit more receptive. It feels like that’s a message that is bandied around—to be direct—in DevRel circles an awful lot, but it doesn’t seem to gain traction outside of that.

Taylor: This kind of goes back to what we were talking about earlier with what team you’re on. Sometimes that makes a huge difference, especially in larger companies. If you were siloed away in a marketing org—nothing bad about marketing, to be clear, but internally, you’re seen as marketing—engineers, developers, see you as marketing. When you come with product feedback, they’re kind of, “That’s not your box. Go back to your box. Go back to your silo.”

And you know, I think the reality is, we can’t look at advocacy like that. I have users tell me things that they would never tell salesperson, they would never tell someone on our leadership team, they might tell someone in support. They tell me things. They send me emails that are multiple paragraphs long, giving positive and negative feedback. Many times it’s positive, but I’m just shocked they’ll even write that much, you know, positive. Like, they actually took out the time to do it.

And they trusted that it was worth their time. I’ve done something right there if they’re willing to do that at that point. And I, you know, I make sure I respond to every single one of those emails. I had someone ask me like, “Oh, do you want us to forward you all of them?” And I’m like, “Yes. Every single one. No matter what it says, I’m going to reply to this email.”

Because then if I lose that trust, it’s everything for me as an advocate. It’s how I can help them, you know, see the value in the product, and help them with adoption, and bring them along to eventually paying, potentially—dirty word, revenue—but otherwise, I wouldn’t have a job. So, you know, I think it’s really something that startups, they think they see DevRel advocacy as content farms and not enough of the part that actually helps them make money.

Corey: I really want to thank you for being so generous with your time. If people want to learn more, where’s the best place for them to find you?

Taylor: So, for now, I’m on Twitter as @taylor_atx. But if anything happens with that, as we know right now, you can also find me at taylorbar.net is my website. I’ll always try to keep links of where I am on there. Trying to write more. We’ll see if I accomplish that over the holidays. But yeah, that’s the two places you can find me.

Corey: And we will, of course, include links to that in the [show notes 00:26:27]. Thank you so much for your time. I appreciate it.

Taylor: Yeah, thanks, Corey, for letting me rant, ramble, kind of have all these thoughts about advocacy. I’m hoping we can have a good 2023 in the world of DevRel and advocacy and make progress on some of these things.

Corey: I sure hope you’re right.

Taylor: [laugh]. I hope I’m right, too, for the happiness of my job [laugh].

Corey: Taylor Barnett, Staff Developer Advocate at PlanetScale. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment channeling a late Christmas spirit to tell us what the true meaning of DevRel was all along. Which will be wrong. Because it includes metrics.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.