Built for Devs With Tessa Kriesel

Transcript

Mandi Walls (00:09): Welcome to Page It to the Limit, a podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me at LNXCHK on Twitter.

We are now live. Welcome back to the PagerDuty live stream. We’re trying something new today. This is a live recording of Page it to the Limit podcast. If you don’t listen to our podcast, we are at pageitothelimit.com. And in all of your favorite pod catching applications, whatever you choose to use there, we syndicate everywhere. So for this episode today, we’re with Tessa. She’s got some amazing things going on, so we are excited to share what she’s doing with you. So Daniel and I are excited to talk to Tessa today on all of our live streaming places.

Mandi Walls (01:03): And for folks who listen to the podcast, this will go out next week or the week after as we get things put together. So Tessa, welcome to the show. Tell us a bit about yourself and what you do.

Tessa Kriesel (01:15): Yeah, I would love to. I almost interrupted you because I was like, I’m excited to be here. And then you were still chatting. So I almost started out with a little rude interruption. Okay. So Tessa Kriesel, about Tessa, let’s see. I love cows. I love being outside. I love swimming. No, I’m just kidding. We’re talking about tech, right? So what I am doing today, I’ve been in DevRel for probably the last, I think it’s almost been 10 years now actually. I think this year I’m hitting 10 years. I know, right? But the first way, my first teaching myself how to code situation like project was actually a video game. It was for Guitar Hero for a community. And so I feel like, I know, it was so cool. I feel like I’ve been doing DevRel my entire engineering career because it’s how I started. It’s like I wanted to build a community of other gamers

Tessa Kriesel (02:09): Or know each other. And so yeah, DevRel for an official whatever, almost 10 years, but engineering for almost nearly 20 years now. And I’ve really just been ingrained in this essence of bringing people together. I love to write code. I love to hang out with people, which I know is somewhat contradicting in the engineering world, but I am that person that just loves to be around other people. So I’m sure there’s lots more that I can tell. We started chatting about sort of bringing me on the podcast with a playbook that I recently wrote. So I know that we’ll dive into that soon. But today I have founded Built for Devs that recently launched on Product Hunt. And then in terms of kind of what Tess is doing, by the time this is a podcast, I will actually be founding GoToMarket at a AI tool called Tebstack, which is under the Mozilla umbrella.

Tessa Kriesel (03:01): And so I’m looking forward to joining Mozilla next week. I know that’s how I feel too. Very excited.

Daniel Afonso (03:07): Well, congratulations on that. That’s exciting. Yeah.

Mandi Walls (03:09): Oh wow. I didn’t realize you were doing this.

Tessa Kriesel (03:14): New stuff.

Mandi Walls (03:17): Yeah. It’s always exciting when folks get new stuff going on and it’s great to see people move to great places and do awesome things there. So tell us a bit about Built for Devs. What is that project like? What inspired you to get it started and what can people expect from it?

Tessa Kriesel (03:38): Yeah. Ooh, that’s a great question. So I got laid off from Snapchat, which was like my last DevRel role, gosh, back in like early February of 2024. So it’s been a hot minute. But when I got laid off, I was like, “You know what? I’ve been really wanting to go into kind of doing Deverell on my own because I saw the value and the work that I was doing and the frameworks and the sort of processes and techniques that I had brought into different companies.” And I was like, “Why not help more than one company instead of being at a single company?” So I founded Built for Devs and it started off as a service agency. And so originally folks were coming in. They were usually early stage dev tools, sometimes middle stage, sometimes open source, which I loved those ones. And when they came in, it was a variety of different things, but it was usually covering the developer experience in terms of where’s that drop off, right?

Tessa Kriesel (04:26): Why are developers not adopting our product? And then sometimes it was some marketing stuff, right? What’s the strategy? How do we bring together our debrief strategy? What does our go to market look like for a dev tool? And it was just sort of a variety of different things that came through the door and I really, really enjoyed it. But the one thing that I consistently did that I always had at the companies that I worked at was those connections with developers. And so I always had those developers, those users that I could be like, “Hey, how’s the product, blah, blah, blah.” Because when you’re ingrained inside of that company, you start to know the users and you start to understand what’s going on. And so you have them and you’re like, “I got access to the product users, right? I’m going to go reach out.

Tessa Kriesel (05:00): " Well, I didn’t have that as a contractor. And so I was like, “Okay, let me think about how to do this differently.” Right. And so I was like, “You know what? I have a massive developer network.” And I started doing the work to kind of surface it. I’ve got a few different CRMs I’ve used for the last almost 20 years, well, I’d say probably 15. And then a few other tools that have like socials and other things of like all these developers that I’ve met throughout my career. And I started realizing, I’m like, these people that can provide the feedback that I need are in my audience already. And so what I did is I actually implemented this process at which a developer was given a guidance sheet. It was like, “Hey, I’d like for you to go try this dev tool, try to reach production, whatever that meant for that dev tool, screen record yourself and be as commentative as possible, right?

Tessa Kriesel (05:43): Whether it’s, oh crap, like why does this exist?” Or, “Oh my gosh, this is so cool.” And so I brought those developers in and I started that process and I had no idea how successful they were going to be. They were amazing, like amazing in terms of my clients could watch the recordings and actually follow along and see their faces. Developers are so critical that they’re just like, “Ooh, you can see it on their face when something is not what they want. " And so those screen recordings were things that they could watch, right? And then when I had all the screen recordings pulled together, I would try to do five to 10 of them per client because I wanted to fully cover their ICP, right? Who’s your primary ICP and use case? Who’s maybe some of your subsidiary ICPs? And I made sure that the developers I brought in very perfectly aligned to who they were targeting.

Tessa Kriesel (06:33): So we were getting the right feedback from the right people. And so then I created a findings report with all of the results from what I found and those things were fire. And I’m very humble, so it feels hard to say how amazing my work was, but at the end of the day, my client said it, like they saw it. One of my clients ended up number one product of the day and the week because we were able to massively shift their developer experience with like four to five quick wins and it was just night and day for the developer experience. So when I did that in my service agency, I was like, “Hey, this needs to be a product because at the end of the day, chasing down 10 developers on a single product project, I don’t know if you’ve ever had to chase developers down, but we don’t like being chased. We hide.

Tessa Kriesel (07:16): And so even though they’re like, “Yes, I’d love to do it. " Sometimes I’d be like, “Hey, I really need this by the end of the week, could you come and do this? " And so it just got to be a lot of administration sort of chasing cat herding as you will, right? And so I started realizing this needs to be a product. I took some time off in 2025. I had a lot of life going on and just really needed to kind of reset. We have four kids and we’ve been going, going, going for a long time. And so it was just a good year to sort of take a breath. And then when I came into 2026, I was like, “All right, it’s on. I’m coming back. I’m coming back strong.” And the first thing I wanted to do was build the product for Built for Devs.

Tessa Kriesel (07:56): And so now today, I converted what was a service offering of bringing these developers in and truly just speaking their mind, which they love to do, by the way, who doesn’t love to just be like, “Yeah, this sucks or this is great.” And now it’s an actual product. And so a company can come and sign up. And so I’ve expanded the scope also. So a company can now come in and sign up. And the first thing that they do is they get this developer adoption score. It’s a score essentially that goes through scrapes, their website, their docs, some of the other things using some lovely new AI technology that we have these days, and is able to turn around and produce a score and also give them those red flags and those quick wins that really landed nicely in my findings report. And it’s totally free.

Tessa Kriesel (08:37): So if they sign up, they can get that developer adoption score, they’ll get that first report and that’s their first step into the product. The second part of the product is I realized that these video recordings were so fruitful and I knew that AI could catch way more than I could as a human. And so that whole pipeline is just beautiful. It takes the transcript from the developer, it takes the actual video footage, and it takes a script that is installed on the site that captures event logs. So essentially when a developer sort of rage clicks on something or when they click out of something or they focus into a field or they’re scrolling through the page, it tracks how far they go. And so that script is installed for companies, then they can actually utilize that full time as well. So inside of the video process, it’s actually identifying, hey, developer went to the homepage.

Tessa Kriesel (09:23): They might not have said it out loud, but they went to the homepage, they did this, and then maybe we hear commentary like, “I don’t understand this. Thi messaging makes no sense.” Or why would they say that, right? And then we can bring those two data points together. So then that script is continuing to work inside of that product for the company to actually have AI recommendations. And so I realized if we’ve got this video data, how rich would it be if we had continual data on where developers are dropping off and then align that to all the data points that we have. So essentially the product today gives you that adoption score. It also provides time to value tracking, which is something that no one is doing out of the box. You can get time to value when you do the work. Mandi, did you want to jump in?

Tessa Kriesel (10:03): You’re like, you looked excited.

Mandi Walls (10:05): No, part of us bringing you on was like, we wanted to talk to you about all of this great stuff as well, but recognizing that not all of our audience is DevRel and excited because I hope developers are excited too to be included in something where they get to be heard, I guess.

Tessa Kriesel (10:25): Exactly, exactly. Yeah. So then that script continues, right? If they install that, they keep that running full time. We’ve got a trigger where that actually runs for the video and so they don’t have to have it in there all the time. But if they do and they want to leave it in there, then what it does is it actually maps their entire developer journey. So they come into the dashboard, they get their time to value number, that’s their main metric. They get their primary recommendation based on all the data we have, here’s what you need to work on or improve. Then we’ve got that full journey mapping. So you see exactly all the different touch points within your product and your experience and it shows, boom, they’re dropping off here, boom, they’re dropping off here, you’re seeing success here. And so you’ll actually see whether they converted or they abandon and you’ll see where and why essentially.

Tessa Kriesel (11:04): So with all the different data points coming together, it is literally like a full view of, “Hey, here’s my dev tool, here’s why a developer loves it, here’s why a developer hates it and everything you need to make incremental improvements.” And so the reason the script and all the things came into play is because I realized if I just had the videos, there was no way for them to understand what’s this metric, right? What’s this value? How do I know that I’m improving my developer experience? And for anyone who knows me and anyone who’s going to pick up the playbook, they’re going to know that I’m very data driven. And so data is really key for me. And so yes, we can go on vibes and we can go on hunches and we can think that we improved things right, but our actual user flow is going to truly tell us that type of information.

Tessa Kriesel (11:44): And so yeah, that’s what Built for Devs does today.

Mandi Walls (11:47): Yeah, that’s awesome. We’ll link to it in the show notes for folks who want to find it. I hope everybody is … It sounds great. I’m super interested in digging into learning more about it as well. And in addition to that, you had put out a paper a couple of weeks ago as well on some of your experiences and your playbook and all of these other things. And there’s so many good nuggets in there and so many things. What we kind of wanted to dig around through is figure out for say you are DevRel and we work in a company. And so part of the places where DevRel kind of sits is you’re kind of in the middle of a web, not only talking to the users, but you’ve also got product and you have maybe sales and you have all these other, the engineering team and all these other folks here.

Mandi Walls (12:35): And for all of that, for what kinds of things do you tell say a product owner when they’re saying, “Okay, well we’ve got a DevRel team. How do we leverage those relationships? How do we leverage what DevRel knows about our customer base in order to make the product better?” What does that relationship look like? What should they be expecting back from a DevRel team?

Tessa Kriesel (12:57): Yeah, that’s a super great question because I think that’s one of the absolute most important things of DevRel is the DevRel and the product partnership. It is so important. My very first DevRel job, and I’ll get to answering your question, but I want to sort of share a story quick. My very first … Yeah, we all do, because it puts it into a framing that we can all understand. So my very first DevRel job, I was an agency and community engineer, had no clue DevRel was a thing. So we had these weird titles that really just came into, I’m a developer advocate. And we had a very outdated version of a caching mechanism in our platform, and it was a constant pain point. Developers were like, “Oh, when are you going to upgrade? When are you going to upgrade?” And we didn’t have a product relationship at all.

Tessa Kriesel (13:38): Our DevRel team was strictly marketing and strictly growth. And I was like, “Well, shoot, how do I respond to them?” I don’t have this relationship. I wasn’t in the lead role. This is my first DevRel role. I was engineering leader before that. And so I had different hunches in my mind that I’m like, wow, it’s really important we chase this down, but didn’t have that practical experience and that just understanding of how to actually implement that. And so it was actually very, very painful because I had to continually talk back to the developers and be like, “Hey, we’ve shared it with the team. I’m unsure what they’re going to do. I’m not getting anywhere either.” And what a horrible experience, right? Because that is just going to kill trust right there because the most important thing I think is when developers see that they have submitted feedback or they’ve had an engagement with the company and they see that that company listened and they changed something or improved something, whether it’s a pricing model, it’s a signup process, a security parameter, feedback on the actual product, whatever it might be, when you actually take that insight and that information and a developer can see that you did something about it, oh my gosh, that’s the level of trust that you cannot build any other way.

Tessa Kriesel (14:46): For example, when I was at Twitter, we rolled out the version two of the API and that’s actually why I joined the team. I joined the team because they wanted someone to take over community and to really rebuild trust with developers. So I joke that I was starting with a negative checkbook essentially because developers are so mad at Twitter that it was like me having to work in the red before I was even in the positive, right? And so this was so important. So we ended up actually implementing a feedback process where if a developer submitted feedback and it made it into the product, they got a shout out in the change log because it was so incredibly important to distill how much we truly cared about developers. So that product and that DevRel relationship is so important. So to answer your question, should I have the experience I have now in that first DevRel developer advocate type of role, I would’ve gone to the product leader and been like, “Hey, listen, I get it.

Tessa Kriesel (15:34): Y’all are busy, you’re tapped, you’re already maxed out. " But the thing about this is if we’re working with developers, their feedback has to be able to come into the roadmap. So we need to leave space for that. It’s not DevRel’s job to dictate the product decisions. It’s not our job to dictate how the product operates, but it is our job to bring that voice and to truly advocate for it, like really advocate for it. And I think the one thing that people will find some value in the playbook, and I actually just posted this on LinkedIn because I knew we were going to have this conversation, was like the way that when you understand how those product features come together and you’re working directly with that product leader or that team, oh my gosh, it’s like this beautiful little best friend situation because they love that you’re bringing that in.

Tessa Kriesel (16:14): And I love that they’re improving the developer experience. And so you’re able to turn around and say, “Hey, because of this new product feature, we reduced churn and increased conversion because we rolled something out that was so valuable.” And so then that’s where the executives are like, “What? What did she just say?” They reduced churn and increased adoption. That’s the money shot, right? And so for me, I think that the partnership with product and DevRel is the absolute most important thing with data backing up your findings and your information and all of your feedback decisions as sort of that secondary.

Mandi Walls (16:49): Yeah. This is like your product folks are like, “They’re going to try and run surveys. They’re going to do all these other things.” I’m like, “We’re already talking to all these people over here, just talk to us.”

Tessa Kriesel (17:01): I mean, unless the surveys are so well written and they’re expected, right? A developer expects it because it’s something that’s in your norm and they’re like, “Oh, okay, this seems normal.” But I’m like, “I’m sorry. I can love a product and I’m still going to be like, I’m not doing that survey.” Ask me to come into a live, do a screen recording and I get to complain about everything that sucks and tell you about everything that’s great. Yes, please. I will do that over a survey, even if it takes me five times as long. Yeah.

Daniel Afonso (17:27): Yeah. One particular story that I really liked from the playbook was the one that you had on the camera kit, SDK. With

Tessa Kriesel (17:36): Office hours?

Daniel Afonso (17:37): Yeah. If you could take us through that, because I think that’s also a very good one when you’re talking about relationship with product and what sometimes the company expects a product to be versus when DevRel steps in and the reality that it surfaces out of it.

Tessa Kriesel (17:52): Yes, exactly. So to tell that story, it’s also in the playbook for anyone who wants to go find that. But to tell sort of that story here live and be able to chat about this is that I came into Snap and the app that we were focused on was camera kit. So it was an AR SDK, so taking the Snapchat camera technology, bringing that into mobile and web apps. And so when I joined the team, the first thing that stuck out to me. So I always do an audit. The first week I’m like deep, I’m deep in the product, I’m being a developer, I’m using it, I’m working in it, I’m talking to people, I’m understanding and doing all those things right. And so one of the first things that came up was I was like, literally like the normal consumer team that answers like Snapchat tickets when your account’s logged out or your account gets taken over or whatever, were the same group of people that were answering developer support tickets.

Tessa Kriesel (18:37): And so I was like, “Ooh, this has to change.” Now they were doing a very amazing job. So to credit them, they were doing a great job, but at the end of the day, developers can tell, they can totally tell if someone is technical and not technical. And so that became my first mission. And so with what Daniel was saying in that story, as a part of that mission, it became like a part of my strategy. And so a part of my strategy was like, “We need to improve the developer experience.” And that meant a few different things I’m going to talk about next. And then that also strategy also included, okay, what else does it look like in terms of what are the other objectives that I have? And so I’ll come to that after. But essentially realizing that that was the case, I knew that somehow I needed to start creating power users.

Tessa Kriesel (19:15): I needed to start creating users. I needed to start creating this availability where it wasn’t just our small, tiny little scrappy team, because even though we were at Snapchat, we were basically like our own little startup, very similar to the Twitter API and how that worked actually. Little tiny startups instead of big, massive companies, right? You’re very isolated, you don’t have the same tools, you don’t have the same team, you don’t have the same budget, all the things, right? And so I’m like, okay, how do we fix this without also hurting their feelings because they were doing a really great job and that team was really awesome. And so the first thing we did was launched Office Hours. And so Office Hours allowed all of us to work as a team together. So product was there, product marketing was there, DevRel was there, and then partner engineering.

Tessa Kriesel (19:54): So partner engineering was actually our kind of engineering team for our SDK. And so engineering essentially was there. And so we would have one person from each team make sure that they were present and really it was like, come in, ask your questions, whatever. We would sometimes do a demonstration if we did something new, but in the beginning it was really just like, “Hey, come and meet the camera kit team. Just come and talk to us. We’re here to help you. " Really putting it front and center with anyone who got access to the beta because the product was in a beta state at this point, which is a pretty important detail for me to add. And so as we did that right, there was continual developers that kept joining. And I know that everyone in DevRel sees this. You start to see some of these people that are like, “Oh, I like the product.

Tessa Kriesel (20:32): I’m liking the team. All right.” And they’re in your sort of sphere more closely than some of the other developers. And we started noticing that and we’re like, “Okay, great.” So we just kept building on that because what my strategy and my intent was, was to remove the support that was coming into that support team, start with Office Hours, create my little power users. Then we launched a community forum and we seeded those power users in there. And so before we could even get into the community forum after it launched to answer some of the questions, it was like we had power users answering them for them. And we were in beta. We weren’t even a fully accessed product. And so after that whole process doing amazing office hours that turned into just … I love them. I can really not say too many good things about office hours because you get to meet so many people.

Tessa Kriesel (21:17): And then they meet the team and then that, right? When we talked about feedback and how that feedback builds trust, office hours are another thing that massively builds trust because they get to know you on a personal level. Then like I said, when we launched the community forum, boom, we were off to the races. And so when all that came to play and we went back to the data, we actually deflected 85% of support tickets. And so the only support tickets that were coming in were literally like, “Hey, I don’t have access.” Or they had to get approval before they could hit production because we were in beta. And so most of the tickets were actually just getting approval to go live. So yeah, I think I covered everything in that story, but essentially that’s just so important to really care about that voice of the developer and building that up because that voice of the developer turns into these little armies of advocates that you can then seed into different places.

Tessa Kriesel (22:04): And it isn’t … Sometimes when I say that, I’m like, “Oh, it sounds like I abused these people. " But it wasn’t that, right? They wanted to be there. They loved the product, they loved helping others. And I think that’s really the developer like MO. We love what we do, we love technology so much that if we’ve got a product we love, we’re willing to be in that sphere and invest in other people because it’s our nature.

Daniel Afonso (22:25): And then to follow up on this, I think one thing, if I remember it correctly, this also helped influence the strategy that you were going with because there was something around gaming versus education as well. Yes. How did this community and these bits also … Because at the end of the day, and I don’t want to spoil the rest of the story, but this also ended up influencing the strategy that the team was going to take with the product at all, right?

Tessa Kriesel (22:56): Yes, it is. Okay. I forgot about that. Thank you for bringing that up. So the other bit that played into that right is that when you’re spending time with developers and you’re listening and you’re in the community and you’re engaging with them and you’re in beta, right? So you’re trying to talk to every single user you can possibly talk to because you want to understand where are we lacking, where are we great and how do we address that? And so one of the big questions is like, it was hard for me actually, because if anyone reads a playbook, they’ll see that the playbook is based on revenue influence. And I think that that is one of the most important things for DevRel. But at Snap, there was no revenue. That was not their goal. Their goal was to build an AR ecosystem and contribute to that.

Tessa Kriesel (23:28): And so my normal tactics of tying everything back to revenue was just not possible because nothing was being paid for at this state anyways. And so as we were working through it, I was just like, how do we get the data that we need to truly understand who our ICP is? What is our primary use case? What are we doing in the augmented reality ecosystem? Who is building an AR and what are they building? Because it was so early. And so what I ended up doing, coming back to being a little scrappy startup, we didn’t have the tools that every other part of the company had, right? We didn’t have Salesforce. We had sort of like a different side of a version of Salesforce that was for the other side of the company, for the snapshot app and consumers and for the ads and things like that, but not for what we were doing, but we did have a provision to Airtable.

Tessa Kriesel (24:11): And so I love Airtable. One of my favorite things, so I picked up Airtable and I was like, “Ooh, I’m going to make a custom CRM.” So I essentially took a spreadsheet that we had that was like all these, Mandi, you’re like laughing. I have so much energy for the nerdiest things. I love data and I love data when it’s all clean and beautiful. So anyway, so in Airtable, I brought our old outdated partnership spreadsheet, which was never up to date. Let’s face it. We have meetings and don’t put them in spreadsheets because it’s just not automated. So I started bringing all that data in and started creating this beautiful spreadsheet. And in that, started bringing all the feedback in. Because what I like to do is I love to have a CRM. And I know that some people are like, “Don’t put your developers in CRMs, marketing will email them.” But it’s like, that’s a whole nother conversation, but they need to be in a CRM because what I like to have for developers is I want to see the full picture of what they’ve done, right?

Tessa Kriesel (24:58): When did they come into the homepage? When did they first find us? Did we meet them at an event? Is a conference the first touchpoint we had with them? Is it a piece of content? Where is it that this developer came into our sphere, right? And then where have they been since then? Because there’s a whole slew of things that come into that, right? But it’s also like tracking the developer journey, tracking what they need, tracking what they’ve tried already. If they do come in and ask a question, I don’t want to be the person that comes back and is like, “Did you try this? " What is very clear in my data, they did try that. And so I had built out this custom CRM and brought all the goodies into it and we started doing reporting and we started bringing all the feedback from power users into our weekly executive meeting that we had across the whole team and reporting on things, reporting back to, like I said, executives, to product, engineering, et cetera.

Tessa Kriesel (25:41): And as we were doing that and bringing all the data together, we actually found what our use case was without even realizing it because we had data so spread everywhere, but we realized that education was actually the use case that we found the most developers in. And then sure enough, product marketing chased down a couple of the education use cases, boom. We had ourselves some of the most beautiful case studies. I actually remember being a part of something that we did where we were doing videos and different presentations to put content out. And I was actually a part of one of the case studies where we talked about it. We talked about what the developer built and how impactful it was for education. And on top of that sort of layer to just imply, we know that AR was the A acronym that did not make it in this today’s technology.

Tessa Kriesel (26:22): And I’m hoping that that changes because the one thing that was beautiful about AR was that that education thing was so incredible. Kids would retain information so much faster when they were experiencing the learning process. And it actually ended up being, there’s a few different situations and I don’t know all the details, but there’s an app for children with cerebral palsy and it of course cannot heal or cure anything, but it gave them the sort of like movement and ability to like … What’s a good way to enjoy explain it? I think really just like that positivity, right? They were able to absorb something and learn something and retain something because they were experiencing something versus sitting in front of a camera, reading something, et cetera. And so it just made my heart so happy because I was like, yay, look, education that’s beautiful, this practical, this amazing use case came out of all this data.

Tessa Kriesel (27:12): And so instead of the executives chasing down, oh, we think it’s like mirrors, right? Everyone wants to do a photo booth and all those different kinds of things, which is what we kind of called mirrors. And we thought that was maybe one of the use cases, but it was like, no, that wasn’t it at all. It was taking real life things that we needed and applying technology that just improved it and made it better. And that ended up shifting and changing our entire strategic approach for the augmented reality sector. So that was amazing.

Mandi Walls (27:39): Yeah. I love that story because you don’t know what developers are going to do with your product when you put it out there, especially if you’re building a tool, right? And like, okay, I can use a screwdriver to put together IKEA furniture. I can use a screwdriver for a million other things. So if you’re building a tool, if it’s flexible enough, developers are super creative and they are going to go out there and do something you had never even thought about because it’s not part of your experience. So all of those folks out there are just adding their experiences to what your original engineering experiences were and just expanding the possibilities off of that product, which kind of leads me to my next question, which is about like, if you are a developer who wants to be enthusiastic about a product and you’re not finding … Maybe there isn’t a DevRel team at that place yet, or maybe they’re just getting started.

Mandi Walls (28:35): How do you ask for what you want? How do you ask for more from your favorite tool if they’re not giving you this great experience that you’d really like to have out of it?

Tessa Kriesel (28:49): That’s a super good question. Actually, really good question because at the end of the day, and I don’t know about you two, but I feel like you’ll agree, but being in DevRel, I feel like now I notice every little flaw of products or every little pain point, I’m like, because I’m so used to screening for them, and then I’m so used to wanting to improve the developer experience that I can’t unsee a bad product feature, sort of a bad experience or approach. And I struggle with that myself. I will reach out directly to people. I’ll do the stalking thing, right? I’ll be like, “LinkedIn, who’s the founder? Who do I know that works there?” I’ll do all that or I’ll at the company, but I think at the end of the day, sometimes that kind of stuff still doesn’t come across. I remember when I was at Twitter in the beginning, they were so overwhelmed by the negativity that inside of the Twitter developer account, so very meta, but Twitter’s account for Twitter developers, they were just like, “Oh, we don’t want to do anything with DMs.

Tessa Kriesel (29:43): We don’t want to deal with the DMs. It’s just too much.” And I was like, “What? No, that’s like, no, we have to do that. " And of course there’s a lot of work, the amount of, I think, just engagement and messaging and really, truly community efforts, Was very, very, very heavy in the beginning because I was like, “No, we have to address it. " And I started going through all the DMs that they had that they never replied to. Started opening up the DMs, started taking over that channel because that’s the thing, is that if there isn’t a space for developers to do it, they’re going to start doing it in a place where you don’t want them to do it. They’re going to be at you publicly on social accounts because they’re like, “Your product sucks.” I’ve been complaining about cloud lately because it was not great. I try not to do it because I try to give everyone grace, but it’s like at the end of the day, they’re going to find an outlet. So you should give them the outlet instead.

Mandi Walls (30:30): Yeah. Oh, it’s so much better to have it on your own forms and have it show up on Reddit or Hacker News or some other place where it’s a mess for sure.

Tessa Kriesel (30:39): Well, you can’t delete it. You can’t control it. And not that you should delete it. The best approach is to reply really with kindness and grace and just take it head on, not ignore it. Best advice I could give in that regard. But at the end of the day, if you absolutely had to and things get crazy, be able to take something down that really is just not inside of your community guidelines or what have you. And if they’re out doing it in the public, you have zero control.

Mandi Walls (31:03): We got nothing there. Absolutely.

Tessa Kriesel (31:06): Yep. Yep. I just realized there’s chat and there’s some people chatting. So hello chat.

Mandi Walls (31:09): Yep. Thanks. Chris, also appreciates Airtable. I totally understand. Definitely dig Airtable there.

Tessa Kriesel (31:17): Hi Arvind. I’m Jason. Oh, amazing. That’s

Mandi Walls (31:21): Awesome.This has been super cool to do this live. We don’t usually do this live.

Tessa Kriesel (31:26): I think it’s been cool too. Especially since I’m sitting by the pool. Ha ha. We haven’t said that yet.

Daniel Afonso (31:32): Making everyone jealous.

Tessa Kriesel (31:35): Oh, got to take advantage of my pool days while I have them. I think it’s going to be 90 today in Texas.

Mandi Walls (31:40): Oh my God.

Tessa Kriesel (31:41): Wow.

Mandi Walls (31:43): All right. Thanks for joining us for part one of this two-part episode. If you can’t wait and you want to hear the rest of the conversation, you can find it on our LinkedIn page or on our YouTube channel. Otherwise, the next part will be in your feed in a couple of weeks. Thanks for joining us. We’ll wish you an uneventful day. Stay tuned for the next episode. That does it for another installment of Pager to the Limit. We’d like to thank our sponsor, PagerDuty, for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at pageitothelimit.com and you can reach us on Twitter at Page It to the Limit using the number two. Thank you so much for joining us and remember, uneventful days are beautiful days.