If you've worried about the coming revolution in automation that is supposed to take all of our jobs away, today's episode might be just for you. And also if you are a junior developer and you're trying to figure out a way to grow into your senior role, your future senior role, how to set yourself up for success today's episode for you as well. Interestingly, today's episode isn't with a senior engineer, it's not with a manager, it's with someone who thinks more about product. Today's guest is Jessica Hall. She is the co-author of the product mindset book that is coming out in under a month. We'll talk more about the book during the episode. My name is Jonathan Cutrell, you're listening to Developer Tea and my goal on this show is to help driven developers find clarity, perspective and purpose in their careers. Let's get straight into the interview with Jessica Hall. Jessica, welcome to the show. Thank you for having me. So we were talking before about whether you want to be called Jessica or Jess, I might end up using those interchangeably, but instead of letting me speak for you, I'd love for you to kind of introduce yourself and explain the things that you're most interested in right now in your career. Oh gosh, that's such a big question. I came up through the world of technology first as an engineer, designer, UX designer, product manager, and now I help a lot of companies decide what to build, how to build, how to structure their organizations. I work at a place called Three Pillar Global and we just wrote a book called the product mindset, and that's all about helping companies, engineers, UX designers, product managers succeed in the digital economy. So what I'm trying to do now is help people expand the value that they're creating, help people who are looking at things like a highly competitive global talent market and the increase of automation and say, how can I be different? How can I distinguish myself? How can I broaden that value proposition to continue to grow my career? And how do I get support within my leadership team in order to do that? And that's kind of the area that I've been focused on for, let's say the last two years as we've been doing the research and writing for the book. That's such an interesting area to discuss. And I'll go ahead and point out that I and many other developers, I've been concerned about my job becoming obsolete at some point in the future. What I do is a developer, we're always abstracting these concepts, right? So it's very possible that everything that I do today is going to be very different in a short as a couple of years. So I'd love to know what has some of that research taught you about protecting yourself from becoming obsolete? And I'm going to add a qualifier here because I think there's kind of a bad way to do this, which is obvious where you create the strangle hold by making yourself the bottleneck or withholding information. And that's something that I'm going to kind of rule out. That's not something that I want to do. So what is kind of the right way, the good way to avoid becoming obsolete in a job like developers have? Yeah, I think a couple of years ago what a successful developer look like is someone who was regularly delivering code that was secure, performance compliant, reliable, deployable, scalable. If you were delivering quality code with some consistent velocity, you were doing pretty well. And now we're seeing a lot of changes in the market. It is a global market. All over the world, there are engineers and schools turning out new engineers. We're seeing things like low code, no code environments where a lot more is being distributed towards people with less technical skills. The rise of automation, DevOps, containers, automated testing, that's kind of changing things where a lot of teams used to have a lot of manual testers. So you don't see as many manual testers as much. You don't have as many of those one systems engineer who, if they left the company, would go to a halt. They just gave them lots of spot bonuses. They didn't have continuous integration or continuous deployment. Now those things are possible. You've seen a lot more. How much of this has hyperbole, how much is this real? I'm not quite sure. I definitely know this. That the top performers, the most sought after talent, they're bringing more to the table than I could just write code consistently with high quality. They're great at collaboration. They're working with QA, DevOps, UX, product, marketing. They're elevating the productivity and the impact of those people around them. They're helping business leaders and their organization make decisions about what technology do you use. How do we sequence things? How can we scale? When do we decide to acquire technical debt? How do we pay that down? There's certainly some top performers out there who are distinguishing themselves by helping people make technology decisions with a business contact, with a customer contact. I think those are the things, if you look at some of the research around automation, those are going to be harder to replace. Because CINCD, that's spot-up deployment. I used to get, have to be woken up at 3 a.m. one weekend a month for user acceptance testing. That hasn't happened for a long time. QA automation is spot-up testing. Now we're speeding up development. You know what? The people part never got any faster. That's true. Sure, as HACTS doesn't seem to have gotten any easier. But people who can help make decisions, trade-offs, alternatives, understand how to go from one place to another, I think those people will always be in demand. Those people will offer a greater value and a multiplier that is going to be really, really hard to replace by automation. Yeah, I think that makes sense. I think that as we see these abstractions kind of wrap what used to be, a lot of what a developer might do on the day-to-day basis, an abstraction kind of wraps around it, it still makes sense that a developer, like myself or the people listening to the show, they might need to know how those abstractions interact and how to compare the different abstractions. In the same way that as we've seen abstractions change the, for example, the languages that we use instead of using a lower-level language, we might be able to use a more expressive high-level language. So those different abstractions still have trade-offs and those evaluations, like you're saying, makes total sense to me that it's all about the context of that automation or of that decision. It's not just about plugging in the system and pressing go. There's more to the puzzle than that. Yeah, and business leaders are trying to keep up in a world where customers have more choice than ever. There's constantly changing demands from customers, from technology, outside forces like GDPR and the California Privacy Act. So there's this always this world where things are going to have to get decided, well, who's going to decide? Who's going to decide whether we use this technology or that technology when we make a replacement? How do we do this? How do we integrate these things together? What's the smart trade-offs? Somebody's going to have to help make that decision and business leaders, they can't do it. They just want to know how much is it going to cost and when I'm out of get that. Somebody has to help navigate that. I think the people in that, those roles, the people with that expertise, with that ability to understand the needs, interpret, help people navigate are going to be specifically high value. We did some research with Forrester. We surveyed about 154 product leaders. 84% said the work that they do is integral to groin revenue. So the work that we do, as someone who came up like I did in UX or product, I might be writing stories or I might be making a copper or wire framework. You might be writing code, but all of us have a key role to play in generating new revenue for the businesses that they work at. What we're seeing is in a lot of cases, people don't even think about that. I was working with an engineering team and they were creating a new product line. It was interesting about this new product line was that it was going to open up new markets. There was a whole category of people that they couldn't sell to because the way they deployed and implemented their solution wasn't going to work for them. This new team was set up, entirely separate from all the other teams, to build this. I did some math and I'm like, guys, my guess is you burned over a million and a half dollars. Like easy calculation, you've been working on this for nine or ten months. This is a team about eight people. It's got products, it's got this other things. Okay. I'm going to guess this is at least a million and a half dollars. So how much revenue do you think you're going to do in the first year? It was like crickets. Sure. I got this. Do you guys, do we understand what we're trying to do here? To understand the kind of sacrifice the rest of the business is making to make this possible. And are we contributing to that? Do we think about, well, you know, if we architect it this way or if we use this kind of tool or we use this kind of approach, we could probably ship something smaller faster and then we could start doing more experiments with customers and doing beta as a proof of concept and be able to onboard some new customers earlier or get some new revenue in the door or learn about something that was risky. If we approached it differently, if we took the mindset that this was a new product line, I could open up a new market, what was the best way to get after it? That's the difference in mindset. I think you see from a high value kind of future proof engineer, then someone says, okay, we'll give me the requirements and I'm going to write some bang in code. I'm not even thinking about those other things. That's product job. That's UX's job and they get it wrong. That's their fault. I'm just going to go over here and do this stuff. Well, I'm sorry, but that's not good enough anymore. That's replaceable. That makes total sense because great code is something that we can study. What makes it actually good, this is something we've talked about a lot on this show. What makes code actually good? Well, there's multiple dimensions for that. You can kind of judge it at the code level itself. You can judge it from that subjective experience level as a secondary developer that's coming in with your knowledge set. You can judge it from the team level. It's this maintainable by this team. Perhaps the most profound way to judge this is this doing the thing in the world that you wanted it to do. This is the way that the market will judge it. This is the way that you are going to earn or lose a job. What you're saying makes total sense. There's this burning question that this brings up, though. That is for all of the people who are listening to this that are in school or maybe they're thinking about becoming a developer and they know that this big technical hurdle is in front of them of learning how to code, learning how to implement these systems. This job that you're describing sounds a lot like what I've heard people describe for senior developers or even staff level engineers. How can we encourage the junior engineers that are coming onto a team to be thinking in this influential way rather than thinking about the job in terms of, okay, I'm getting a card off of my Asana or Jira board or whatever. I'm doing whatever the card says, how can a junior engineer start thinking more in this product mindset? I absolutely love that question. I think it's a great one. You're joined a new team or you've joined a new company. What does that company do? Who is our customer? How do they make money? What are we trying to achieve? Having some fundamentals of what the organization is trying to do, spending some time, talk to your product manager, talk to your UX designer, try and get a sense of who the customer is and what we're trying, getting those kinds of that kind of background, that kind of information. So we have that, you pick up that card and you're like, okay, I can see what this is doing contributes to everything else around me. And so the work, hey, that gives you a work more meaning and purpose, right? You're not just banging out a ticket. You're contributing to the value and saying, you know what, I'm not quite sure how this connects or, you know, I think maybe I could probably implement it this way. And then you could just ping someone on the team and say, how about this? I was kind of thinking about it this way or maybe we could sequence this way. We had a team working with a big client, a big insurance organization. And the way this insurance organization measures everyone and how they affects their raises and their bonuses and things, that's about how much self service they can try. So it means that if you can keep somebody off the phone from calling a support representative, we want you to do that. And that's the goal. And so the team actually spent some time and everybody on the team brainstorming ways to improve performance. And so they found that by tweaking one of their algorithms, they could speed up the way to return some results to customers by like 10%. And in this game, 10% actually counts for a lot. I mean, that could mean the chance of, you know, it could improve the amount of conversion that they would get. And so everybody on the team said it came up with some ideas to say, you know, if I did this, you know, we could get it a little bit faster. Or, you know, we could make it easier for this customer. Or, you know, so be, you know, suggesting ideas, thinking about the impact, asking a lot of questions and making sure you understand how you contribute to the team. And those types of things are great for junior engineers to do, occasionally listening on some user research, whether that's a recording or some of it live. So you have a notion of who is this person. I love getting engineers to listen to user research. And I just say you're going to do it all the time because you've got stuff to do and everybody's got a ton of meetings, too many. But occasionally hearing human beings' voice and knowing that what you do is make their life easier. And understanding them is great, we were doing something with a big media company, huge one. And one of the folks on the team was doing user research and an engineer was next to her to like scribbling in a notebook, writing things down very furiously. And she gets to see, and she's like, what's going on? He's like, we've been arguing about how to implement this feature for months. And I finally understand what they need. And I know exactly what I need to build. But if I just know this a couple months ago, if I just ask a question or thought a little bit more about what I was trying to keep, I could have saved weeks of debate. So one little extra question, one little interpretation, one willingness to be able to step out and say, hey, I was thinking about this. And hopefully you're at an organization that supports and encourages this behavior. I sure hope that's what I mean. I know that's not everywhere. But those types of things are that little bit of investigation, that little bit of extra understanding, that little bit of extra initiative is such a great thing for a junior developer to come in. And right from the get go, start adding more. Yeah. You mentioned something that I think is so important for managers who are listening to this. And certainly for product owners and anybody who's in any kind of leadership position, the more that you can empower those junior engineers because we're talking to the junior engineer moment ago. And you said, I hope you're in an organization that supports us. The people who are empowering the younger engineers should be doing so in this direction, in the direction of saying, hey, you know what? I want you to understand thoroughly the whole kind of product chain from the user and their requests and their needs all the way to whatever that piece of code is that you're writing. And you may not be the one that's going to perform that research. You may not know all of the, you know, statistical models that are used to decide between one feature or another. But if you have some exposure as a, as a, whether you're a junior engineer or any level engineer, it's important for leadership to support these efforts. Because what most junior engineers are not likely to do on their own is to stop the work that they're doing and say, hey, you know what? Is this even the right thing to do? That's a really dangerous and scary thing as a junior engineer. That would be a really dangerous and scary thing to do because who are you? You haven't really proven yourself. And there's a lot of kind of social pressure for you to kind of, you know, do the thing that you know is going to impress the most people in the company, right? But that's most likely not the thing that is, that is going to prove long term successful for your career, necessarily. And certainly not long term successful for that product. So that's kind of a call to leadership to support those efforts. Absolutely. You, you frame that so beautifully. What I've learned of eight years and working with global teams is that people under invest in context. So is that true everywhere? You're under nothing. So true. Like, people do not, they don't take the time to say, I love my friend, Sip, he did this in every meeting that we went to when we were building this, the first mobile app with a company we worked at. Every time we sat down with someone, he would spend a good five to seven minutes explaining the whole context, what we were doing, where we're trying to do what we're trying to get done today. Here's the lay of the land. Here's the objective. I'm like dying inside because I super ADD. But he was so right because that extra context that he put into every big, important interaction just framing up. Here's what we're trying to do. Here's why it matters. Here's what we need for you. Here's how you're going to help us contribute to this thing that is important for our company's future. Like, just did that before every major meeting we had and everyone was like, okay, everything got easier. Yeah. Yeah. I would, my desire was to jump right in and get started. That context, that foundation about here's what we're trying to do. Here's why it matters. And a lot of people don't do that. I've run into many product leaders that I've coached in the last year and they just, they don't understand why their teams don't know what's going on. Yeah. They just like, they're kind of, they don't, you know, because I'll walk around. The thing I do to test this role simple, what are the three most important goals for the next three months? And I'll ask like 20 people. How many times do you get different answers? I get the only answer I get the same as I don't know. Yep. Yep. Yep. So, and you, you find a lot that, that people have said things once and they put it in a PowerPoint deck or it's not simple, it's not clear, it's not going to hammered in. This is what we're trying to do. This is why it matters. This is how we, what, this is how you fit in. And so, I think people really under invest in that. And then they, then when somebody tries to take an interpretive leap and step out of the balance of the card, they get smacked on the hand because they didn't interpret it in the right way. And so, then they want, you know, and because they got smacked, they now receive. They do, you know, they have all the anxiety you've discussed. And now, now they're like, they stepped out of line and they got smacked for it. So I'm, I don't know, I don't know, I don't know, I'm not going to step out of line again. And then that's the, that's the leader who calls me later and says, well, why do people not feel empowered? That's exactly why you tell them. Yeah. Um, but you didn't spend the time to say, here's the mountain we're climbing, here's why we're climbing, here's what success looks like. Here's how I need you to contribute. You can figure stuff out of your own. And as long as we have some way of measuring that we're going the right direction, it's okay when you get it right. You'll get it right. You know, you'll figure it out and then we'll get there together. People just don't invest in that. And if you don't, if you're on a team and you don't understand, you're not quite sure what we're doing. You got to ask them. Don't just put it on product or UX to be responsible for, or, or sales or marketing. Ask questions. Um, try to be important. And you know, you may hit the wall at a certain point. You may be like, you know what? Just shut up into your job and my sense is that's probably not a place you want to be long term. Yeah. It's probably just not. Yeah. You're probably going to hit a wall pretty fast or maybe they don't stay in business. Or they get acquired or something else happens. That was, that was, you know, one of the pieces of advice. And you mentioned before we started recording that this was one of the episodes that you would listen to at this show. One of the pieces of advice that I gave myself is, you know, don't, uh, don't stay loyal to something that goes against your values. That's essentially what it was, what it was saying. And that's true. If you're stuck in a company where you can't think this way where you're not allowed to access this, this higher level vision or you're not allowed to even ask questions about it without feeling, and maybe it's not a written rule that you're not allowed to. But rather, it's not normalized. It's not something that, uh, culturally is acceptable. And you know that because when you tried, when you tried to do it or, uh, when someone else tried to do it, they obviously got shot down in some way. You know, this is a major failure of leadership, uh, because this should be normalized. This should be something that, and when I say should, I mean, if you want to succeed as a company and be a long-term company, then it's likely that this is a way that you should operate, not just because, you know, people like to be empowered and connected, but because this is necessary to, to maintain competitive, uh, nests. I'm sorry, this is necessary to stay competitive, like you said in a global market. And so if you're, you're just, you know, pushing people into their boxes and whenever somebody pipes up and says, Hey, you know, what about this big idea? If they feel a sense that, you know, they've stepped out of line or somehow this is inaccessible to them, there's probably something wrong there, right? Would you agree with that? Mm-hmm. Yeah, a couple things are going to happen. One is people are just going to retreat. They're just going to do what they're told. And you watch these organizations and you're like, how did something happen in these big scandals? It's because they retreated. Or, um, they're going to leave. Or, uh, there's going to be drama. They're going to go rock. Or I'll come in, right? Maybe you'll all three. Or all three. I mean, I've certainly seen it, um, many times. We have a chapter in the book about culture, uh, and we talk a lot about what is the kind of culture that's enabled. And the culture is exactly the one you scribe. The culture that is open, um, that is accessible. That values questions, that values, asking, um, pushing things forward. Um, one of the things I tell clients sometimes, and it's a little like salty language. I'll just warn you in advance. It's like, okay, I know it is. Sometimes you just need something and it maybe isn't the best idea, but you just got to get it done. Like your, your boss is all over. Your board is all over. You just kind of make this thing. If you got to make it go away, like, that's okay. I understand that that's necessary. I'm going to give you two of those here. And I call it the J F D I, which is just happening to me. It's like, oh, is it the J F D I? Yeah. Okay. I'm not going to talk about anymore. We're just going to knock it out because we've accepted it like sometimes you just got to do what you got to do. But every other time, no, let's have a conversation about it. Let's, let's be willing to debate it. Let's, let's be willing to, you know, entertain it and, and have, you know, push things for it. And if you look at the work that Google has done, they've done a lot of really expansive research on what makes for a good team and what makes for a good manager, talking about things like psychological safety. Which doesn't mean that everybody is nice and fuzzy. It means that you feel safe saying, yeah, that was dumb. Right. Right. Or I think we should do something else or this is it working. And so environments where those things are healthy and safe and open and welcomed, our environments where I think engineers are going to be able to succeed. And all the people around it, because it feels one of my colleagues told me once he's like, we don't need agile so much as ways to work together because the complexity of the modern development team is so far beyond just engineers now. We've got QA out of engineers, we've got data engineers, got data scientists, we've got DevOps, we've got, you know, product marketing, we've got product management, we've got user experience, we've got information, we've got all these people, we all have to figure out how to work together. And the best way to do that is in an open collaborative workplace with a very clear, like, that's the mountain gang we're all going together. Yeah. I mean, that's, that's what all of the research in this area shows, right? And the best is if you can have a shared, a shared goal, then your particular flavor of working and whatever ceremonies you have, if you, if you can have a shared goal and if you develop clarity around that, but you also have a sense of, like you said, psychological safety, you know, if you have someone who cares about your well-being at work, these things seem like common sense, but unfortunately a lot of the time, what we end up seeing in companies that don't, you know, actively manage these various points that we're talking about, we see companies that, you know, elevate only one of these things, right? They'll elevate psychological safety, but you don't have the clarity that you need or you don't have a shared goal. And so everybody feels, you know, like they can work with their, with the people around them decently well, but nobody knows what they're doing or why they're doing it, right? So it's safe, but it's not really progressing anywhere. Yeah, I definitely, I think you've expressed it where I, my, one of my favorite clients of all time, totally collaborative, highly invested in, in context, really traveled the world, spent a lot of time, were super open about what they were trying to do. The problem was that they just moved too slow and they took, you know, years to develop their new product, which would open up a new market. Well, other people beat them to market. So you can be a great working environment that everybody loves. It's still not being made any month. Yeah, right. And just completely fail. And so, you know, it's a balance of all these things. And it, you know, there are times where certain, they're going to have to trade certain things off. It's never, it's never easy. It's messy. It's hard. But I think if you take the attitude we're all in this together, then you're more likely to come out on the other side and be successful. I think on one hand, you could say to go back to our theme of automation, this is a scary time to be an engineer and a time where maybe obfuscation and entrenchment and putting your head in the sand is the right play. Yeah. And what I think is it's the absolute wrong play. Yeah. Automation is coming to a lot of people, but it does, you know, open up a lot of possibility that maybe you're not even thinking about. Whenever there's change in organization and gosh, isn't there change in organizations like all the time, I try to say to myself, what is now available that wasn't yesterday? How are the pieces on the board change in a way that maybe I can chase a new opportunity or learn something new or take on a new challenge? Maybe I can hire a different kind of person in a different kind of place and learn to take out a new project or develop the skill that I know I'm lacking in. If you take the mindset as changes opportunity, like when something is different and maybe that something opens up a possibility. So if you can just like gulp and handle that fear for a second and say like, now what is available to me today? What is an available to worldwide? I can spend less time doing this like task that I don't like. What could I feel that time with? What could I increase my impact? How could I increase my value? How could I do something different today that I'm not doing because I have to spend my time on this? If you kind of shift your focus that way, then I think you can get to a potentially better place. I know it's scary. I know you don't want to do it. I don't want to do it. I have two children. The automation thinks cares about living crap out of me. But then I take it deep breath and say, okay, something is now available to me that wasn't yesterday. What is it? And do I want to chase that? Is that worth making a bet on? I'm going to say many things that technology is drastically changing in our everyday lives. Fintech might be at the top of that list. And Barclays is helping lead that change. Barclays has an award-winning group of developers and the passion, resources, and tools necessary to actually do something innovative in this space. And they're hiring. Go and find your next position at home.barclays slash developers. That's home.barrcl. A-Y-S slash developers. At Barclays, developers are always developing. This is, we can't really predict the future very well. And so when people are asked what's going to make them happy, they often say something that they think will make them happy. And then they're asked, once they have that thing, if it made them happy, it turns out it doesn't. From much of the things that we expect that it would. And large reason for this is because the way that we predict or the way that we imagine an alternative reality, in this case, a future where automation has replaced a lot of our current tasks, is incomplete. So we aren't thinking about what will we replace that work with? We don't really think about that. Instead we think about purely just the loss. We have this massive loss of version. So we're really concerned about, oh no, all the skills that I've spent my career honing are suddenly obsolete. And now I've lost this major thing. But what you're saying is exactly right. This is how we should be thinking about the future. Specifically, what have I gained? Not just what have I lost, but what have I gained? What is new on the table? What's available now that previously wasn't? And one of those things, perhaps the most important one, is time. Why do you have a wide open field to replace the thing that you were doing with perhaps something more valuable? Yeah, I think that loss of version is a powerful, powerful thing. And I love all the research on those aspects of, you know, I read something recently, I'm sorry, I can't recall where. But it said, when you imagine your future past a certain point, it's a different person. It's not you, it's like somebody else. And so the idea of like one year, five year plans, you're imagining a company that doesn't even exist. So you tend not to, because it's not you, you aren't thinking about some of these long-term changes in your life. But if you go back from a couple years I worked at the museum, well, there's no more types that are in the world. There's no more telephone operators. There's no more very few printing presses for certain things. But people are doing something else. Like other things have emerged. And but you do have to, you know, the hard part is you have to kind of lean into the change. It brings the change, take some risks, continue to learn. You did a podcast about, you know, the advice you would have given to 10 years ago that you wouldn't have learned, listen to, sorry. And you said, you know, spend a lot of time learning a lesson, you know, learn a language really deeply because so many things are more applicable when you truly have more mastery of it. That's a great example of like things are different. I went to journal school and I work in technology. But yet so much of what I learned in journalism school asking questions, digging for the story, trying to figure out what the most important parts are, being able to communicate to people in a crisp, clear, short way. And I, you know, doing research, you know, I use all those skills today that I spent time building 90s. But I just use them in a way that I would have never thought about in the past. So it's not as bad as you think, hey, you know, who the heck knows how it's all going to play out. But, you know, I would come back to take that mindset, that kind of growth mindset of, I'm going to learn, I'm going to impact my company, I'm going to continue to provide value and value at an ever broader, higher level. And if that's the tack you take as an engineer, it can take you many, many places. And you know, it can take you up to the CTO level. It can take you up to being a CEO or, you know, a leader, a thought leader. I mean, there's so many possibilities. And I don't even know what the next set are. But there's definitely a lot out there. Yeah. Well, the cool thing about what you're saying, and I think this is true for developers, a lot of the skills that we think we are learning, a lot of the things that we think are, you know, going to last us a lifetime. When I said to learn a language deeply, it's not because you're learning the language. That's the thing that's kind of the trick, right? We think we're learning the language. And when we learn math, we think we're learning, you know, algebra, so that we can get an A on the test, right? But actually, we're learning this whole other skill set that is entirely transferable. It's not just one kind of blanket skill set so that when automation arrives suddenly, you have to toss that thing out the door. Instead, if you look at all of your learning processes as this integrated thing, right? All of the learning that you do can apply in multiple ways. The brain doesn't really know how to package up your math knowledge and remove it from your language knowledge, right? To your brain, it's all the same stuff. And so if you can imagine that the learning that you have spent so much of your career investing in is not, you know, just this bucket that can easily be thrown out. But instead, it's deeply integrated into all that circuitry in your brain. Now it becomes more valuable. And in fact, actually becomes incredibly valuable when change occurs because now you have this deep set of knowledge to draw on. You have all these models in your mind that perhaps the next person, the next worker that didn't have all that experience, they may not have the same information that you have in your head. Yeah. I would also say, gosh, I wish every hiring manager who's listening to that podcast would consider what you just said because a lot of them get focused on, do you know this technology at this skill? Can you check this box? Do you have this subject, subject matter? Do you have this assistance? Like, whoa, whoa, whoa, time out. That person, they can, there's nothing that they need to know that they can't learn quickly by spending some time on the internet. But I've definitely seen, I don't know if this happens to engineers as much as I've absolutely seen its product in UX to say, like, oh, they've never worked on a healthcare product. So you probably can't do this. Like, no. That, that, all of that experience, that knowledge you're bringing in practices from different industries, that's where innovation lives. You have a broad set of skills. So when the next time a technology stack needs to change, you can adapt more easily. I think sometimes hiring, you know, talent or HR teams or managers are looking to check tick off boxes when they're hiring as opposed to looking for people who can learn, if you can think and who can solve problems because they'll solve whatever they need to solve. One of the best hires I ever made as a product leader, she had been a stay at home mom for seven years. Like, you went back and looked at it and like, this person's a badass. Like, they did these amazing pranks. They took seven years off to raise kids. That's a, that is a product exercise in and of itself. That's for sure. Oh my lord. Yes, as a working mother too. Yeah. I can logistics anything. But one of the best hires I ever made because all of the things that are really important, she never lost them. Okay, needed to get up to speed and some technology stuff and some process stuff and some other stuff, but yeah, she had that done like three weeks. It's like driving a new car, right? You have so much these fundamental concepts in your mind. And I would say, you know, there are a lot of companies that actually already understand this, especially, I've noticed this for developers. The companies that have elected an esoteric language to use for their stack, like Elixir or something, right? So this is not a common language and for that reason, what they've done is they've hired a lot of people who didn't know it. And so what they've realized in that process is, wait a second, these people are getting up to speed fast enough to be productive. Maybe we don't have to restrict to, you know, just people who have experience in the stack, but instead we look for thinking skills rather than doing skills. And that has been such an interesting factor in the way that these companies hire because they end up hiring people who tend to have skills in a broad array of languages rather than, you know, only focusing in on that one esoteric language. That is so interesting because most of the time when they're choosing stuff, I know a lot of people who when they choose stacks, they're like, okay, where's the talent? Yeah. So I go with Java because I know I can find Java and, you know, I may pick something a little bit more exotic and the rest of the stack, but I got to have a couple, like, I definitely know people who will pick stacks based on, you know, looking at their talent supply. But the idea of intentionally choosing something that's a little more off the range, that's just blows my mind. I think it's fantastic. Yeah. Well, and it's not necessarily, it's not necessarily because they want to recruit that way. You know, they may have someone that does have experience with it and they know that it gives them a competitive advantage in a particular area. But rather, they've learned that recruiting, they kind of can break through rules because they've had to because the languages have as much of a talent pool. Well, now they have to start considering talents separated from the language and look at aptitude as a different way of seeing the same outcome. Yeah. I think people are way too attached to languages. Languages come and go every, you know, three to four years, your people are re-architecting and making changes. A lot of people are committing their organizations to a path without knowing how hard it's going to be to change. As opposed to saying, this is where we're solving for today with tomorrow in mind. We think we know that things might shift and change over time because everybody has had to re-architect and in many cases, multiple times. Yeah. Yeah. Absolutely. Change is the only thing that we can rely on. That's kind of the fundamental concept of this episode, right? It's, you know, we're really seeing our jobs in light of the, maybe a more advanced way of thinking, an integrated approach to our work rather than, you know, trying to turn everyone into a component that we can plug in. Instead, we have components in our machines. And so the human, the brain is so good at integrating concepts. So let's take advantage of that. Thank you so much for listening to today's episode of Developer Tea. If you enjoyed this first part of my interview with Jessica Hall, make sure you subscribe and whatever podcasting app you use so you don't miss out on the next part on Monday. Thank you again to today's sponsor, Barkley's, Barkley's developers are always developing. Go check out the openings they have available in New Jersey as well as all over the UK. Head over to home.barkley's that's home.barclais to check out the open jobs today. Thank you so much for listening. My name is Jonathan Cutrell and until next time, enjoy your tea. Thank you.