Screaming in the Cloud - Building Trust in the World of DevRel with Taylor Barnett

Episode Date: January 3, 2023

About TaylorTaylor Barnett is a Staff Developer Advocate at PlanetScale. She is passionate about building great developer experiences emphasizing empathy within product, documentation, and other developer-facing projects. For the past decade, Taylor has worked at various data and API-focused startups in software development and developer relations. In her free time, as a firm believer in "touching grass," she's either gardening, taking long walks, climbing rocks with friends, trying to find the funkiest sour beers, or hanging out with her corgi, Yoda, and spouse in Austin, Texas.Links Referenced:PlanetScale: https://planetscale.com/Twitter: https://twitter.com/taylor_atxPersonal website: https://taylorbar.net

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. If you asked me to rank which cloud provider is the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud.

Their developer experience is unparalleled 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 slash startup. It'll give you up to a hundred grand a year for each of the first two years in Google Cloud credits for companies that range from bootstraps 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. This episode is sponsored in part 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 two 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 slash logicworks. That's snark.cloud slash logicworks. And my thanks to them for sponsoring this ridiculous podcast. 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. You're welcome. Yeah, I'm glad to be here. 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 or 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 businesses pretending that we're behind it. Do we have an answer yet? 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 the 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 it. 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 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. I would say that 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 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 how you have talks, except some of the big tier one conferences, and they list a few examples. And it's, yeah, I've spoken at four of 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. Yeah.

And one of the other troubling patterns that I'm starting 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 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 page views 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. 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 for tests 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. Yeah, no, I mean, I actually sometimes say, well, like I'm secretly probably 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 very, very technical. But the reality is like, you know, somebody's got to write the words sometimes. The words are harder when they're going to people than they are to computers. At least with computers, it's pretty, it's a bounded problem space to some extent. With people,

oh no, no, there's no consistency at all. 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 definition of that word. Oh, I think most of them do. It all means, 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. Yeah. Yeah.

I mean, CDNs have been around for a while. You know, and that's really like with 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? Or 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. 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. Yeah. One of the things I love, Maddie Stratton had this thing where I tweeted out a few months ago that we've over-indexed on content. And Maddie'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 makes my life easier somehow. But to do that, I'm 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. 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. I honestly will say I don't care. I mean, that's really... Corporate IT, got it. Do I want to be on a team that makes me directly responsible for qualified leads? No, that is not necessarily say anything about the team itself. That is just a metric that is, you know, and, 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 do. And I don't necessarily think sales and marketing are a bad thing. I think it's the way we incentivize those roles create bad behaviors. And so maybe we should look at how 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. 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 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 reported a marketing once and it was terrible without realizing the context of, yeah, but in a terrible way in 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. 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. Some people try that. Is that what you've done? Indirectly. No, I was talking about more about the holacracy companies. Oh yeah, no one reports to anyone. It's really? Because everyone makes different amounts of money.

Someone wonders about that. Yeah. But by far, we just go find better managers is what we often do. You know, 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 team's bad, so I'm never going to join a marketing team. We should say, let's just go find one that fits better. 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. Yeah. And I think, you know, what's been also interesting is I've 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 will 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 that 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 a 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 10 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. 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?

You could have invited me and I could have just delivered it for you in person and answered questions, but all right. Yeah. It was like, one, I was just like, oh my gosh, that has literally never happened to me. This was a few years ago. And then two, 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 100% 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. 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 DevRel 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 were 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? 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. Tons of DevRel submissions in there. So 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 with 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. Where do you think that we are 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. I wanted to see more stuff like that, but it just seems like we didn't. 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 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 these 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. That's 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. 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? 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 that is 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 questions. How do you then make that actionable internally? 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're 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 and, 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 love 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 listen 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 I think all companies could benefit just from listening more and doing something about it. I wish that 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 the 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. 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 at larger companies. If you were siloed away in a marketing org, nothing bad about marketing, to be clear. But internally, you are seen as marketing. Engineers, developers see you as marketing. When you come with product feedback, they're kind of like, that's not your box. Go back to your box. Go back to your silo. And I think the reality is we can't look at advocacy like that.

I have users tell me things that they would never tell a 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 positive. They actually took out the time to do it and they trusted that it was worth their time. I've done something right there with their willing to do that at that point. And 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 I think it's really something that startups, they think they see DevRel advocacy content forms and not enough of the part that actually helps them make money. 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? So for now, I'm on Twitter as Taylor underscore 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. And we will, of course, include links to that in the show notes. Thank you so much for your time. I appreciate it. 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. I sure hope you're right. I hope I'm right, too, for the happiness of my job.

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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS.

We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble