Built for Devs With Tessa Kriesel Part 2

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.

Welcome back for this second part of our two-part episode with Tessa. The conversation was just so good. We just kept going. If you haven’t listened to part one, you probably want to go back and check that out. If you’d like to listen to the whole thing or watch the live stream that we recorded, it’s on our YouTube channel and on our LinkedIn page. We’d love to hear from you what you thought of that. Otherwise, welcome back and you’ll join the conversation as it was running.

Daniel Afonso (00:56): So you touched on one point there that I think it’s an underrated skill in DevRel, which is having tough skin for these type of things because you need to … As you’re going through all of this feedback, some of it is going to be good, some of it is going to be bad, but you always have to approach these things with kindness and empathy and understand that most of these things are coming from a place of pain rather than and frustration rather than hate itself. So how do you cultivate that skill for someone that might not have it? So obviously some people are more naturally empathetic, but some might not have it. So how do you handle those situations as you’re going through this type of feedback?

Tessa Kriesel (01:43): Yeah, that’s a really good question. That’s actually a really tricky question because the way you asked it makes me want to go back to being like, “Well, as a leader, I wouldn’t put that person in front of communications.” They’d be working on content or they’d be working on SDKs or whatever because soft skills are not teachable. Yes, people can work really, really, really hard to be different people, don’t get me wrong. But being naturally empathetic is not something that you can just build. And so if you are someone who is in a position who is not naturally empathetic, that’s going to be quite hard. And I think potentially reaching out to someone on the team who is a little bit better with that, who can be empathetic, who can work through those communications, because it really does take grace. It truly takes grace of like, “Hey, they’re in a bad situation, don’t get defensive,” especially when you work at a company.

Tessa Kriesel (02:32): You start to feel this love for the product, you start to advocate for the product. You’re just like, “Hey, I’m invested in this product and it’s hard to hear the really cold, hard truth sometimes, especially depending on how much you’re really invested.” And so I think that just taking a step back and really being able to breathe and think about that, marketing is your best resource here because marketing usually has someone who is really good at communication, whether that be from a messaging standpoint or whether that be from being able to have those conversations. I don’t have any specific tactics because honestly as a leader, I sort of just shift my team around and I’m like, “Ooh, you’re naturally good at this. I’m going to have you take the lead here”, but then try to use that person to train and bring up the other parts of the team. And so I think it really just takes a good leader to help you and to mentor you through that and what does that look like and how do I give you those skills?

Tessa Kriesel (03:21): And if someone just really doesn’t have it, then they just don’t have it, right? Then they can be the person that’s like, “Let me bring that in and then let’s come up with that response process.” And that’s actually in the playbook too. I’ve got this whole section about DevRel and product and partnerships and all that and how you actually close that loop. How do you have that conversation where they provide you feedback and you actually close that loop and make sure that it’s positive? Because at the end of the day, if someone provides feedback and you’re saying nothing, then that’s not good. You need to say something, whether it be like, “Hey, that’s not the vision for our product. I’m sorry that that’s what you’re looking for. " And maybe even recommending competitors. That’s also in the playbook too, of talking about content that is kind and graceful and comparing yourself to competitors, but in a non-competitive way, right?

Tessa Kriesel (04:02): “Hey, we’re good at this, but these guys are really good at this.” And that’s okay because that’s the whole reason why there are so many different tools to begin with is that we all have different areas we focus on. And so I think being able to do all of that is key, but now I’m rambling. So I’ll wrap it up.

Mandi Walls (04:16): Now you’re fine. That’s great because we do see that. It is hard to say that’s not part of our vision to be able to say definitively no, even if it’s a great idea. We feel bad saying, “Oh, that would be awesome to add to our product, but there’s no buy-in for that internally right now.” So I would love to be able to tell you that, oh, it’s on the roadmap for Q4 or maybe for next year. But when the truth is that no, it’s not on the horizon. No, that isn’t what we have envisioned for the next phase of the product. That’s a tough one. It’s a tough conversation to have. I’ve definitely had it many, many times over the years during this job. It’s like, you’d ever know what folks want. Like we mentioned earlier, their experience is very wide and a whole lot wider than ours and they come up with some really interesting stuff and you’re just like, “Hadn’t thought about that before, but probably not going to do that. Thanks for telling us.”

Tessa Kriesel (05:15): Yeah, it is too. And honestly, and that’s where that trust can get broken because you can build trust. It takes a lot of work to build trust, but it takes very little work to break trust. And so when you don’t reply to that and you don’t tell them that, then maybe they keep using the product, right? They think that it’s going to maybe come because it feels like a natural progression. And then four months later they’re like, “Well, this is never coming and now we’ve invested” and now they’re mad almost because

Tessa Kriesel (05:38): Like, Hey, I’ve got work to do because now I need to shift. “Truly, and I feel like this is all over in the playbook, but it’s all over in our conversation is like, just tell the truth because at the end of the day, they’re going to see right through everything that you’re doing and they’re going to listen and they’re going to pay attention. Developers miss nothing, like nothing.

Mandi Walls (05:59): Yeah, for sure.

Daniel Afonso (06:00): And I think speaking of developers as well, I want to bring a moods a bit up now because I feel like with this question, it went super well as well, but we were spiraling down on the bit on the pain and the struggle there. So we’ve talked about partnership with product, how that’s important as well. Now, what about if we talked about other sections? So there’s partnership with product, there’s partnership with marketing, engineer, sales. So for someone that might not be aware of what DevRel is as well, how would you come into an organization and say, “Hey, this is what DevRel is. This is what it means for engineering. This is where I’m going to be supporting in sales, this is where I’m going to be supporting in marketing.” How do you usually position DevRel for organizations that might not be aware what it is for them?

Tessa Kriesel (06:56): Yes, that’s a super great question because I think that that’s a … In my agency, in the beginning, I got to do that a lot because I got to work with, like I said, a lot of different clients and come in at various stages and everyone has a different opinion of DevRel. And it’s funny because to me, I’m like, " It’s so clear, but it’s because I work in it. And so I get it in a different way than other people get it. So to summarize DevRel in essentially, I guess one sentence, DevRel is enabling developers to find success with their product, point blank. And so that can mean a lot of things, right? And I also think that when people hear that statement, if their DevRel team is in marketing, they’re probably like, “wait, what?” Enable them to find success with the product that’s not marketing aligned and absolutely it is not.

Tessa Kriesel (07:41): And I will absolutely stand behind that. DevRel does not belong in marketing, but it lives in marketing in so many organizations because it’s like, “Oh, growth, growth, growth.” And it’s like, “No, no, no.” That’s not what it’s about. It’s about the enablement, right? And so there’s actually, I think it’s on Tessacresel.com, I believe, for a blog post. If we want to include in the show notes, I can send you the link, but I’ve got a blog post somewhere and essentially it’s talking about how Apple originated where they started using, or I should say it was Mac. Wait, was it Apple Mac? I think it was actually on computers. It was Mac. Apple, they’re the same, but it was for the actual Mac products. So they brought in engineers and the engineers were helping other engineers find success. And that’s the beauty of DevRel, right?

Tessa Kriesel (08:23): And so when you talk about that, I’m not saying that marketing doesn’t come alongside of it. It absolutely comes and it’s a beautiful little addition to DevRel, but it is about that success with the product. And so everything that we’ve been talking about, about really like, here’s the voice of the developer, here’s where the product’s at. How do we make these two beautiful and combined and married and very happy, right? But at the end of the day, it can also mean that maybe you’re coming into some engineering calls because the SDK needs some massive changes or maybe the DevRel team is responsible for the SDK because it’s a wider and a bigger product and DevRel’s taking on the actual developer product. Maybe it’s a developer plus type of a company instead of a developer first type of a company. And so at the end of the day, it’s really that like, how do they find success?

Tessa Kriesel (09:08): And I think my playbook outlines that pretty clearly, but at the end of the day, DevRel still has this outreach approach because in order for DevRel to have the opportunities to speak to developers about their problems and help them to find success with the products, sometimes we have to find those developers. And so sometimes that looks like conference presentations. And I know that some people are like, “That’s the whole reason to do the conference presentation is we’re going to bring developers in.” But I’m like, tell me that your ROI is good from that because it’s not. I know for a fact it’s not, but you’re putting yourself in front of those developers, right? And so the ones that do grab and the ones that do make sense can have those follow up conversations. You can spend time with them at the conference, you can get to know them, you can talk to developers that aren’t using the product, or you can talk to developers that are already power users of your product because you’re going to the right events in the right places.

Tessa Kriesel (09:54): And so yes, I know that outreach and marketing and growth is absolutely a part of what people think that DevRel is, but the way I look at it is it’s more of that piece of, if I’m going to enable developers to find success with the product, how do I do that? And it’s being in the spaces and the places where they are spending time. And so that’s what you do with that outreach and the events and the content and the other stuff is like, you’re still writing content to help them use that SDK, you’re still writing content to help them solve their problem, but you end up bringing in new developers by doing that. And that’s sort of like the plus side of DevRel is like, yeah, there might be some growth that comes with that too. But the three metrics that I focus on is actual retention.

Tessa Kriesel (10:34): So how many active users are there? I don’t care about new users. I could really care less because if they’re not converting, they’re worthless to me. So active users, time to value is that decreasing, right? We don’t want time to value to be longer. We don’t want it to take longer for developers to see, boom, here’s the value in the product. We want that to be lickety split, they see it and they are sucked in and they continue to adopt the product. And then the last one is the revenue influence, right? So how does all the efforts here come back to revenue and whether again, that’s that product feature that’s like, “Hey, we reduced churn, we increased adoption, that turned into blah, blah, blah.” Or whether that be, “Hey, we were at a conference and we ended up bringing in these great conversations and now Red Bull,” which was a situation that happened at Snap.

Tessa Kriesel (11:15): Now Red Bull is using our product because we had a solution to a problem that they had. So that’s what I think DevRel is. There’s so much more that can go into that. I would strongly recommend that people pick up my playbook if they like what I shared so far, but it really is about that product adoption and truly like enabling developers. And so when it comes to reporting lines, there’s nowhere that DevRel really makes the most sense. Absolutely not marketing. I do not think it makes the most sense there because of the way that their objectives and their goals are and their approach to measuring. But I think product and engineering are great places for them to exist. I also think that it’s really powerful when DevRel can report directly to a CEO if you’re in an earlier stage because CEOs and founders in that space should really be the early stages of DevRel.

Tessa Kriesel (12:01): And then that can kind of be this really cohesive situation. I personally think that we sort of have a gap in all of our executive processes inside of tech companies because like who’s ever speaking for the voice of the developer inside those board meetings and the answer is no one.

Mandi Walls (12:16): Yeah. No, that’s super interesting. It’s a raging debate. We currently report to marketing. I’ve been at PagerDuty now almost six years. We’ve moved around three-ish times. We’ve been parallel or dot linked to product at different times. We’ve been in product for a while. We reported to the CTO for a while, like currently in marketing because that’s where the budget is for all of our activities and-

Tessa Kriesel: That does help.

Mandi Walls (12:41): They get the money, so there’s that. But like DevRel, I kind of think of it as a parallel funnel, right? So marketing has a funnel, sales have a funnel, DevRel definitely has a funnel. We’ve got a lot of things that are even out in the stratosphere beyond the top of the funnel, and that’s like your conference talks. You don’t know who you’re going to see at a big conference. Like last week I was at SREcon, Daniel was at KubeCon. It’s a whole lot of serendipity who you’re going to talk to and just have that click moment where they’re like, “Oh yeah, I absolutely forgot that I was looking for something that’s exactly what you’re talking about. Let’s follow up.” And maybe it had been pushed back in their timelines or they didn’t have money for it when they first looked at it and now they’re ready to have their conversation and they just needed that reminder.

Mandi Walls (13:31): But like you said, the time to value part is something that we’ve struggled with with every product I’ve ever worked on. You get to figuring out the first itchy things that people have, the first pain points, and then you don’t necessarily go any further maybe sometimes. And you’re trying to figure out, okay, well, that’s not enough to get beyond the switching costs to go to the next product or to find something else. So how are we going to get to those folks to tell them about what’s the next thing they could be doing? How else can we be enhancing their workflow or their experiences and all? And that’s a very bottom of the funnel kind of function. So

Mandi Walls (14:10): There’s a lot of, you need to be very flexible with the kinds of things you’re thinking about and the kinds of things you’re producing so that you’re always giving some theoretical developer out there, whatever they’re looking for. And if they’ve looked at your stuff or not, the exact right thing that might help them have a better experience, get a better use case, have a better workflow with your system and the things that you’re working on. And yeah, it’s just constant iteration on all of that stuff. And I think that’s where it’s harder to be in product because they’re thinking quarters ahead and doing their sprint planning and all those kinds of things and marketing is much more coin operated most of the time with their leads and all that kind of stuff. And like, yeah.

Tessa Kriesel (14:55): Yeah, I do agree. And I think you bring up a good point because I think I should have added a caveat that there are also strong leaders across teams. So sometimes organizations and they’re like, “Oh, this is the right leader.” And it doesn’t really matter, right? Maybe it’s a marketing leader, maybe it’s a product leader, maybe it’s an engineering leader, depending on that team. So I think that makes sense. And like you sharing the budget thing too, I think that’s really clear too. I think that the whole point of it really is that DevRel has to be able to come in and advocate across those different areas and be able to

Tessa Kriesel (15:23): Work with all those different teams. And so it’s like at the end of the day, I guess you can put them where you want them. I have strong opinions about where they should go, about the team that they should spend time with in team meetings and in standups and things like that. But I do agree that marketing has the budget. And so that I will say has always been a pain point whenever I reported to different parts of the team, which Snapchat, I reported to partnerships. Totally different. It’s almost like sales-

Mandi Walls (15:45): So random, yeah.

Tessa Kriesel (15:46): I know, I know. But look at the amazingness that came out of it, right? The case studies and the stories that were told, it doesn’t matter at the end of the day where you’re sort of reporting to, but what does matter is if you can advocate with those different leaders and those different teams to find what I kind of call your champions, right? You need champions externally with developers. You need champions internally with team members so that you can impact all the different pieces that play into the developer experience really.

Mandi Walls (16:11): Yeah. Awesome. This discussion has been great. We’re way over our usual time, but that’s totally fine. We can always divide this up if we want to. Daniel, do you have any additional questions for today?

Mandi Walls (16:25): Dnaiel just looks stunned. For folks who will be listening to this later, he’s just kind of … Yeah.

Daniel Afonso (16:29): Yeah. I was stopping and thinking because I could have like 500 extra questions because as I was reading this playbook, it’s really, really good first of all. Let me tell you that. It’s so good. Everyone should definitely check it. And there’s one thing that as we’re preparing even for this live stream, like Mandi and I were even chatting briefly about this behind the scenes. And one of the questions that we’ve kind of alluded to that here as well, and I think I’m pretty sure you also mentioned this on one of the chapters is the difference when you’re doing DevRel in a startup versus when you’re doing DevRel in an enterprise, because that’s a completely different scope. So could you share a bit on how do you approach that? What are the things that people should take in mind considering this? How does it change your relationship with developers as well?

Tessa Kriesel (17:20): Yeah. Oh man, that is such a great question. You just asked a really amazing question and I’m excited. I have had the opportunity to kind of work across a variety of different ecosystems, which has been really fun. Startup, I’m thinking back on startup, startup, Twitter, obviously, so that’s more enterprise, right? Startup, then I went to Lacework, which is a pretty big security company and Lacework was looking to expand to developers that didn’t end up playing out the way that they thought, but it was definitely a different dynamic coming into a security company thinking about developers. That was a fun challenge. And then Snapchat, obviously very enterprise, but in its own vein, a little bit of a startup. So really what that is going to come down to, and I talk about this in the playbook, is knowing your ICP (Ideal Customer Profile) and then doing the Jobs to be Done workshop.

Tessa Kriesel (18:08): I don’t know. Jobs to be Done doesn’t get talked about a lot in the DevRel space and the DevRel world, but it is something that’s very known in product and in go to market of really just like, what is that job that your customer needs to do? And I think it’s so, so, so important when it comes to developers, because the reason that developers even touch a product is because they have a job that needs to be solved, that they know they can’t build it themselves. They know it’s too complex, too difficult. That’s something that they can just implement, bring in the right tool and be able to do that. And so you need to deeply understand the job to be done that your developers need when they’re coming to your product, right? And if you don’t clearly understand the job that you’re serving or the job that you’re doing, that’s a whole problem.

Tessa Kriesel (18:47): And so I talk about jobs to be done and I talk about ICPs. And I think this really falls into sort of the same bucket, right? So ICPs being your ideal customer profile. And so it’s who you’re targeting, right? And so in the playbook, I really drill into how important it is to know your ICP, continually be editing and evolving your ICP and to really be tied to that closely. Because the thing about it is like, you might be working at like … Okay, so I worked at CircleCI for a short amount of time, very early on in my career. And so when I was at CircleCI, at the end of the day, they’re a startup, right? But their customers were like enterprise customers plus startups and all kinds. Some of them are just like indie developers, right? And so that’s a whole nother ballgame of like, what’s the audience of developers that are coming in and then how do you work with each of those, right?

Tessa Kriesel (19:29): Because enterprise developers have a whole nother … I mean, the decision making process is like completely different. The budget process, the compliance, like what does security look like? I mean, like totally different buying decisions than if me, a developer, I need to implement something for Built for Devs. I’m like, da, da, da, da, founder and developer, here we go. I’m going to try it and we’re going to use it. We’re going to see what happens, right? So they’re just different audiences. And so it’s really, really, really, really, really, really. I cannot express how manys it is important to be in tune to this. And it takes the same thing that we were just talking about, understanding the different departments, right? What does the leadership team think that the product is supposed to do for developers, right? Is there a realignment that needs to be made?

Tessa Kriesel (20:14): What’s the stage that this product is at, right? Is it an early product? If it’s an early product, you and the founder are probably working hand in hand to be really scrappy and to push things forward. But for example, when I was at Snap, one of the things that I ended up doing, which by the way, I’m not really big on hackathons unless the ICP is like someone who is early stage developer first, I’d say first three years, maybe four years of their career, because after that, then they’re just like, “Ah, I’m doing my job. I don’t want to go hack on stuff.” They find projects to do and they’re spending less time in the hackathon world. However, in the enterprise space, there is a hackathon magic that happens when you come into an enterprise company and you give them a day off and they get to build whatever the heck they want.

Tessa Kriesel (20:56): That’s a whole nother ballgame. And so even just comparing that, right? Hosting a hackathon for a startup and trying to get senior developers to come, waste of time. But if you can come into a company and you can say, “Hey, let’s do a hackathon with your team. Let’s give them a day off from normal engineering tasks. Let’s give them a couple of really cool tools and a few ideas and let’s let them run.” That is the kind of hackathon that has fire and lots and lots of power with it, which by the way, I did that on Snapchat and it was just like, sales team loved me, my corporate team loved me. And it wasn’t me, right? It was like the ability to just come in, give them the day to experiment. And I was just there enabling them to find success while listening for all kinds of feedback and other insights I can bring back to the team.

Tessa Kriesel (21:39): But it really matters when you think about that in terms of who’s that end audience, what product are you in? Because even if you’re in a startup, you still might be serving enterprise. Or if you’re an enterprise, you might be serving like startup developers or like indie or early developers, right? And so understanding that ICP, what that job is that your product is serving and who needs that job and at what stage and level that they’re at. And that’s actually the thing about Built for Devs that I think makes it probably as powerful as it is, is like ICP match to like 25 different criteria. It’s down to like what frameworks do you use? What CI tools do you use? What databases do you prefer? Is it backend? Are you in a different focus? It really is like very finely tuned because at the end of the day, and I will suggest it if you don’t know who your ICP is, our app will suggest what your ICP might be.

Tessa Kriesel (22:26): But when you know that information, you’re getting the right feedback, the right information from the right developers that allows you to target then the correct developers through your marketing, through your messaging, through your approach, through sort of everything. And so it matters and it matters a ton. So I’m really glad that you brought that up.

Mandi Walls (22:42): I have so many horror stories of like developer mismatch or like just not … Developers, the external users talking past the internal engineering team would be like, especially about anything enterprise, if you are at a small engineering shop and you do have enterprise customers, they’re going to come to you with stuff like, “How does this work behind my proxy?” And your engineers are going to be like, “I have no idea. I’ve never worked anywhere that’s required me to have a proxy.” Or they’ll come and they’ll give you the four letter word of RBAC and your engineers will be like, “We don’t want to do RBAC.” Of course you don’t want to, but you probably need to because it’s necessary. So buck up kiddo, let’s do some RBAC. But it’s always a surprise for those internal engineering teams because if they’ve never worked at an enterprise company, and a lot of them don’t, folks who are really comfortable at a small company maybe have never worked at a very large enterprise and they don’t have that, they’ve never been in that environment and so they don’t know what they’re missing out on there, so to

Mandi Walls (23:46): Speak. So the requirements documents look totally different for those two kinds of places. And it’s nice to be in there and be able to bridge that with the engineering teams when that comes in from the customers. It’s super interesting.

Tessa Kriesel (24:01): Yeah, exactly. I think the one example I could share, especially coming from maybe more of a founder space, is when I was building Built for Devs and when I was actually starting my agency, I was trying to do the spray and pray approach, as I call it early on.

Tessa Kriesel (24:16): I was like, “It’s okay if I get enterprise clients.” I had one enterprise client lead and originally I was like, “Maybe I’ll stick to startups.” And they came in and I was like, “Ooh, they have a little bit more money. Okay, let’s talk.” And then just started realizing that when you go against the grain, like when you go against your original plan or against the grain, it is always painful. And so when I built the product, I was like, no, no, it is not built for enterprises. It’s really not built for late stage either. Built for Devs is truly built for that early stage, that founder that is like, “What is broken? Why are developers not adopting?” Because it’s priced that way, it’s like triggered that way, right? It’s the way that I built it, it’s the way that it’s approached, because that’s the audience I want, right?

Tessa Kriesel (24:56): At the end of the day, I was like, “I want to hang out with other developers.” And I was like, “Ah, technical founders.” So really in my business, I was like, “My ICP is very tight because that’s how I roll.” But one of them is a pivot founder. It’s very tight, right? It’s a founder that’s looking at a pivot because they’re not finding success and they’re like, “Where do I need to go? " And some people are like, “Oh my gosh, you’re limiting your audience.” But it’s like, no, I’m not. I am doing the perfect job for my audience, exactly what they need because I so deeply understand them and have spent time understanding them that I know that this is the job that they need to do. And so that’s just an example of how that comes into play with DevRel. I was really, truly understanding where’s it just a perfect fit?

Tessa Kriesel (25:33): Don’t try to fight them, spray and pray. It’s so painful. Find that tight little audience that is perfectly catered to your product and then expand, right? And then that’s how you scale. And I think I actually talked about that in the playbook too, about what you need to do before you think about scaling, really getting all those different details narrowed down, finding success in your framework and your approach, and then starting to scale beyond that kind of first audience that you start with.

Mandi Walls (25:56): Awesome. Yeah. This has been great. Absolutely fantastic.

Tessa Kriesel (26:00): This is my first one for like, I don’t know, I think I’ve done a podcast or a live stream for like a year. So I’m like, yay, so nice to kind of come back and chat with lovely people.

Mandi Walls (26:09): Yeah. And I mean, it’s like, I like doing these because we learn stuff from everybody who we have on. We just don’t know what everybody’s experiences are going to be. And sometimes we ask people and they’re like, “Oh, I don’t know if I could talk about myself.” I’m like, “You can talk about yourself for at least half an hour. I know you can do it. I believe.” Or at

Tessa Kriesel (26:27): Least your work, you know?

Mandi Walls (26:29): Yeah, exactly. So yeah, when we come across folks who are really enthusiastic about the things that they do and really have a large variety of interesting experiences, for better or for worse, tech is always changing. So there’s always something interesting and new to talk about with people and that’s why we keep doing this. So it’s perfect.

Tessa Kriesel (26:50): Yeah.

Mandi Walls (26:51): Yeah.

Tessa Kriesel (26:51): I feel like it’s moving so fast now that you could have a daily livestream and it’d be totally different three days later than the other one was.

Tessa Kriesel (26:58): Just wild how fast it’s changing.

Mandi Walls (26:59): Yeah. I’m taking a class right now and the first half an hour of the class is like, what’s going on in the news in AI right now? And it’s crazy trying to keep up because I don’t watch it in real time. I watch it recorded and like 48 hours later, it’s completely different or we found out that there was more to that story than we knew. It’s just like everything right now is so insane. So yeah, none of us are sleeping, I think is really what the story is. Everybody is just constantly scrolling and learning stuff. So yeah.

Tessa Kriesel (27:29): I feel that so much. So I text myself things that I find on my phone if I want to read it when I’m on my computer and maybe that’s like a really dumb workaround, but it works for me. So I just text myself. So in my personal text to myself, I think I had like, I don’t know, a good solid, like long scroll, probably at least five times of like, “Ooh, the new way to do Claude,” because I’m like building a whole bunch of apps right now for different things because … Yeah, anyways, and it’s just like, wow, I can’t even keep up. And then the next one’s like, “Oh, there’s a new way.” And I’m like, “You know what? I’m going to have to just live my life and if I’m outdated, so be it. When I need the skill, I’ll have to just look it up.”

Mandi Walls (28:03): Yeah, we’re all learning this stuff anyway, right? None of the things that we’re doing right now existed even 18 months ago. So nobody has decades with it. So it’s all new to everybody. It’ll be fine. It’ll be fine.

Tessa Kriesel (28:16): It’s so much fun though. The one thing I think before we wrap up quick, the one thing I think is really fun about it is even just I would say probably nine to 12 months ago, actually it was almost exactly nine to 12 months ago because it was April that I realized of last year that I had to take some time off because I was just like, “Oh, I’m getting burnt out.” But I realized that I was like, “This has to be a product. I can’t do this anymore. I can’t chase this down like this. It’s just too grueling to try to do it.” And I tried to figure out if you could analyze video. And at that time it was like someone at MIT had built an early stage library and I was like, “Oh gosh, I don’t have the technical skills to dive into this yet.” And then now boom, started thinking about it in January, Codex has the one that just processes videos and now I’m like, boom, here we go.

Tessa Kriesel (28:56): So I completely agree that it’s like things are changing so fast that even a product decision that you make in a planning stage is like, if you’re building that product two months later, you probably should replan because everything is just evolving. Absolutely.

Mandi Walls (29:09): We’ll definitely be here learning more stuff for the future for sure.

Tessa Kriesel (29:14): Our brains will be fried for a lot longer and yes it does, Chris. It moves so fast.

Mandi Walls (29:17): It does. Absolutely. All right. Well, thanks for joining us. Everybody out there, thanks for listening in. Thanks for joining us. This was super fun. So we’ll be trying this again with future guests on our show. Thanks to Tessa for amazing conversation. This has been great and these streams will be on our LinkedIn and our YouTube and for folks who are listening later on Page it, thank you very much for subscribing to our show. We’ll be back in a couple of weeks with something new. In the meantime, we’ll wish everybody an uneventful day and hope

Mandi Walls (29:50): That you’re out there learning and growing and doing something that you love. 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 pageitothelimit using the number two. Thank you so much for joining us and remember, uneventful days are beautiful days.