What your developers aren't telling you - Cat Hicks (Psychologist)

0:00Cat Hicks: Is it a goal of yours to make more money in 2026? My name is Travis Chappell and I'm the host of the Travis Makes Money podcast. It's the only podcast on Spotify that brings you two episodes every single day on how to make more money. From side hustlers to real estate investors, brick and mortar owners to online creators, beginners to billionaires, every conversation will give you the ideas, inspiration and practical tools you need to make more money and earn your dream life today. Subscribe right now to the Travis Makes Money podcast on Spotify and I'll catch you over there.

0:32How do you rebuild after a setback? Find your next direction? Or understand someone whose life looks nothing like yours? On Let's Have This Conversation, journalist and motivational speaker Kevin McShan meets the people behind those questions. From resilience and well-being to careers, leadership, and human connection, discover personal stories and expert perspectives that could change how you see your own life. there's a lot we can learn from each other. Let's have this conversation. Search for Let's Have This Conversation wherever you listen to podcasts or click the link in the show notes.

1:21Caring really hard is beautiful, but it's also exhausting and is another route to burnout. Sometimes this weird experience where you sit in a room with leaders and you realize they're thinking about developers this way. Individual developers feel less productive. They are caught up in a lot of social problems, like they worry that they cannot make mistakes. What people are feeling when they imagine if those skills suddenly are not valued by other people anymore, that is viscerally painful. Even if you lose one of these skills, we're gonna find a way for you to learn another one. Technology always changes on us.

1:57This is part of what we deal with. We actually can face it together. Why can't we communicate value very well? Can you look at your life and tell me about good times and bad times? Because even within this space, we have variety. There are moments when things are better. Everybody is talking about cognitive scaffolding. I talk about metacognitive scaffolding, which is actually a really big area in psychology and learning science.

2:27kat thank you so much for joining us today how are you doing oh i'm doing so well i'm on a little lake retreat right now uh enjoying my book launch and hanging out on a paddleboard most days so i think i'm doing great how about you that's fantastic i i wish i was on a lake and on a paddleboard but i'm sadly working away the summer at this point but august august will be better Oh, wonderful. And you mentioned your book launch. So you just came out with a new book. Tell us about it and tell us about yourself. How did you get into this space in the first place? What do you do these days? And what's the book about?

3:02Yeah, yeah. I am a psychologist and I've been a psychologist for a long, long time. But it took me a while to discover tech and to discover software teams. And so I'll tell that story first, which is also in the book. So it's a good lead up. But, you know, I worked in the science of how people learn and the cognitive science of kind of learning and performance. And I worked in classrooms and I really, really loved that stuff. And then I got to Silicon Valley and I started leading like large scale kind of educational programs in tech. And I noticed that all of my friends who were software engineers, all of these people that I was meeting and hanging out with, it felt like they were experiencing this strange set of circumstances.

3:48And I just really was captivated by this. On the one hand, these were incredibly valued people, people who obviously did intellectual work and the companies fueled this massive international economy that I was just starting to wrap my head around. On the other hand, as a psychologist, I just heard over and over and over again these stories that were like, I'm not getting enough time to learn. I don't know how to collaborate with my teammates. We are all of these very intelligent people. We care about our work, but we can't seem to figure out how to have a good culture together. there. So I decided there was like something really, really interesting going on here.

4:29And also just that the things that I had worked on and knew, I really wanted to try to translate that to some of these software teams. And then from the other direction, I was like, well, psychology and human behavior, we haven't really spent enough time with these teams. Like we haven't actually, you know, sat next to them, listened to them and learned from what those, all of those minds, like collaborating in technical systems could teach us. So both directions, I felt like there was something incredibly valuable there. I did something that I'm not sure I would recommend anyone do, but I self-funded a research study and I put it online and I just said, here it is, open access.

5:08I did this. I'm a psychologist and there's not really like a job out there. You know, if you look on LinkedIn, there's no like psychologist for software teams job listing. And so I decided to kind of try to make one and start publishing work. And that led to all of the research that's in the book now. So I ended up leading a research lab, doing a lot of open access studies where we recruited like thousands of developers from the real world. And we studied these psychology questions. So like, what does help your motivation? And why is it hard to get time to learn, you know, and all of these questions that had like come up for me over coffee chats and like at the bar with my friends, I really took those into my heart and decided to kind of devote my life to studying them.

5:55So that's what the book's about. It's about like the questions I kept getting asked, you know, as your psychologist friend in this industry. Fantastic. And so the book is The Psychology of software teams. So before we even go into the psychology part, I'm curious about your definition of a software team, because there's lots of different ways of taking this. And so you talked about technicals. Are you focusing specifically on developers? Do you include other people? What do you define as a software team? Oh, okay. Yeah. Great question to start with because the title is actually a little bit of an inside joke.

6:33Because if you look for books like this, you'll notice there'll maybe there'll be like the programmer's brain, the psychology, which is Feline Ehrman's, I want to say. And there's the psychology of computer programming by Gerald Weinberg, which is very old book. So kind of out of date now. There are other people who have worked on these topics. And these are like really interesting contributions. But something that I noticed is that just a ton of this stuff is all about individuals. So it might be like a picture of a brain on the cover or, you know, about you as a single solitary person. My kind of psychology, I'm really, really interested in environments and groups and kind of these emergent things that happen.

7:14So I chose teams. I was like, I think it has to be in the title because even if you were just a solo person striking out into like your first, you know, open source project or something, you were still looking at and engaging with work from other people. So you're actually kind of part of this big shared global team. So I think of developer as an incredibly broad camp, like it's really anybody who chooses to try to engage with this big, overlapping, interdependent, complex sets of technical systems. So that could be you were literally learning to read code for the first time. It could be even a product person who is now striking out into writing code these days much more than they would.

7:59I use the term developer, but I think you probably saw as you read the book, I have an early footnote in it that says, listen, you get to self-identify as this. I'm using it because we don't really know what word to use now. And I'm using developer a lot of the time instead of saying engineer, because I do think it's a much, much broader category. It's like, hey, you want to build? Come on in. Come on in and let's talk about what will help you build. And what was the response like to you said you kind of reached out to lots of people to recruit everyone for your research? Yeah. What was the response like to that recruitment?

8:36Like how were people just curious to know what you would learn? And did they come with themselves of like, oh, yeah, if you're doing this, can you help us solve this problem? Yeah, a huge range of responses. And, you know, when I was doing this, first I did it on my own, and I led this project, and it was very scrappy, like recruiting off my own social media, asking friends of friends. Then because I released this open access study, I actually got reached out to by a tech company by Pluralsight, and they came and talked to me and said, listen, we've seen your work. We love it. We want to know what it would take for you to set up a research lab here.

9:13And so I remember going, you know, home after that phone call and sitting in my backyard and just thinking, what would it take for me to do this? This is such a strange experiment. And so I sketched out the plan of a research lab, and that is the vehicle through which I led a bunch of this open access work. So there wasn't really a vocabulary that existed. There are obviously massive research projects that exist, like the Dora Project, if you've seen that, or there's labs like the Microsoft Research Labs, which host researchers and publish a lot of academic research. We wanted to do something a little more unusual with the Developer Success Lab, which I led for three years.

9:52And in the Dev Success Lab, I knew I wanted to invite developers into like how we design studies and why and why psychology made sense. So honestly, there was a lot of excitement. There was a lot of joy at that prospect from like our public audience. I will say there was also like confusion and some pushback and some fear and some like, are you just trying to sell my data? Like, what is this? And that is not a surprise to me because I think, you know, when you start to ask psychology questions, they're like, are very big questions that go deep to like our hearts and deep to like sticky, scary experiences.

10:32So if you are a researcher, I think you do have your job is to like go out and prove that like this is worth your time. I'm going to show you why you should come join this project. I'm going to show you what I'm going to do with it. I'm going to show you why I wrote the questions these ways. I'm going to show you the statistics that we ran. I'm going to show you our privacy policy. So we built all of that into our studies. And I do think it took a little bit of time for developers at large to just know who on earth I was. But then I'm happy to say, I mean, we had incredible experiences running these studies, Something I'm very proud of, this is a long answer, I'm sorry, you can tell I'm passionate about research design.

11:12Something that I really loved was that we had a really high percentage of women in software development. We had a really high percentage of non-white developers answer our studies. And I think a lot of that came from the fact that we were always sharing out loud about why we think it's important, why we want to look at the experiences of these specific groups. You know, this comes from science and psychology that's going to help you. It's not just like product marketing, you know, to try to sell you a product. So I think all of that built trust, but it took a time. Yeah, it took like several years.

11:47One of the things I really liked is you talk about the fundamental problems. It's not just output that is a problem here. It is the perception of the people on these teams as well as their ability to communicate value and have their value recognized. But you have a wonderful sci-fi, retro sci-fi term for how people are seen. So I'll let you jump in with that. But just why are we all kind of recognized that way? And why do we have so much trouble being recognized for the actual value that we can contribute? Yeah. Yeah. So when you look at the world, you spin up a mental model of what you're seeing.

12:29You make interpretations about that world. And those mental models, right, you can probably think of them about the mental model you have about a code base, the mental model you have of like cause and effect in some technical world you know really well. We have those models about people too and about our social worlds. And the metaphor I used in the book that I love is called the brains in jars model of software development. And this is like the evil scientist laboratory. If you can imagine like the brains in the jars and there's like the bad fluorescent lighting and what it evokes for me, I started using this metaphor and I knew it was a good one because every tech conference I went to, people just roared with laughter, you know?

13:11And I was like, this is, it's getting something good, right? Like people recognize your joke, but it's actually very, very serious at the heart of it. It's like we see software development as this activity that is like stuck inside of people's brains. Everybody's interchangeable. You're like fungible little units. You know, you can think about factory mindsets of just like you're spinning out the widgets, you know. And there's sometimes this weird experience where you sit in a room with leaders and you realize they're thinking about developers this way. Right. Or even you could sit with a highly technical person who's done a lot of things, but they're painting a picture that's so simplistic.

13:50And you say, listen, I've seen you work. I actually know that you're doing something much more complicated than this. Collaboration is a part of it. You know, mentoring juniors is a part of it. Like you going back and correcting your own mistakes is a part of it. Like you're not just this robot, you know, functioning in this isolated way. But, you know, our minds, we really like heuristics. So I think we get stuck in this kind of model because it's a little bit scary to challenge it. And the reason I think it's really, really lovely to challenge it, though, is that like it validates your real life experiences all of the time.

14:26It helps you kind of understand how you keep getting stuck in things that seem like they're going to work for the short term, but really fall apart in the long term. there was something um that you said there as well where it's not necessarily even just the perception of like outsiders looking in on software teams thinking that it's brains and jars but also like internally within the team um that perception of like oh I'm just a brain and a we do it to ourselves listen yeah I guess what's the the problem with that thinking and um if that is a problem and you fix it, like what's then the outcome of people feeling like they are more than just the person who's calculating the solution or whatever?

15:15So I think a whole family of problems comes from this. And, you know, one of the things that I worry about as a psychologist is like, you get this kind of breakdown start to happen when you're really, really stuck in this model. So think about burnout as a version of this. You know, people are not just waking up, going to work and saying, today's the day I'm going to burn myself out, you know, like, unless you're in a pretty bad place mentally, maybe. But you are often making a lot of choices, you know, to grind or to work hard or to kind of, you know, simplify what's around you, because there's some short term goal you're trying to get.

15:57The issue I think for me is our minds are really good at tricking us into thinking that what we're doing is working a lot better than it is. So when you measure this in the research, when I look at these kind of factors, like the more that you have these mindsets on a technical team, you actually start to see a lot of pretty immediate real world outcomes. So individual developers feel less productive. They are caught up in a lot of social problems, like they worry that they cannot make mistakes and they can't learn out loud. And so they don't engage in processes that actually help them upskill and help them kind of face challenge.

16:35So there's a lot of touchy feely, like emotional part of this, because it feels much, much better to be seen as a whole human. But there's actually a very cold, hard economic reason to care about this too. And that is like the processes that we actually need to get these teams to go through, kind of rely on making sure, you know, we don't trap them in these bad mental models. Another version of this that I see is when people get really, really caught on the feeling that software development is a place where people have to be cold and that like the colder you are, the smarter you are, which is a stereotype that we carry around about technical work.

17:16And then you end up with these strange situations where we rely on collaboration or we rely on a lot of important social work happening in technical community is, but then we also don't value it. So we need it. Like with one hand, we're saying, please do it. And with the other hand, we're saying, well, you're never going to get promoted for it, or we're never going to like, you know, call it out on stage. I think that just makes, kind of destroys people's like trust in their organizations and communities. So there's many angles to look at the cost of this. We also have the problem, you know, that a lot of the people who work in technical fields are neurodivergent in different ways.

17:56And also a lot of people need time to just sit and think and do. And it is not a deterministic process. It's not give me one hour and I will solve this problem. It is I need some time. Sometimes it is time spent typing away. And sometimes it is I need to go for a walk and let things settle in the back of my head and then the intuitive leap happens sometimes it's talking to other people and we don't always really value all of those aspects of things we want a very strict formula we want this to be a factory we think building software is that building this is we can predict the the value the flow of widgets through by lines of code by by story points by things like that and to be honest i don't think this is specific to engineers or software.

18:44When I was a journalist, it was the same thing. People thought, you know, the number of stories and number of words we could write was the same thing, but it wasn't a direct predictor of quality. There's a reason that, you know, the New Yorker magazine is so much better than most other things. It's because they pay more and give people time to actually work on those stories. But part of the problem here is our CTOs and our engineering leads, they're struggling to justify the value of the teams. And they're often using these very, very strict quantitative metrics around code rather than value. So how do we change this?

19:20Why are we stuck in this? Why can't we communicate value very well? Let me throw a question back to you for a second. Have you seen a leader do this? Like actually shift the org and take a longer term perspective? Rarely. Very occasionally, but rarely. And it takes somebody who is got incredible psychological safety, a lot of experience, and has the combination of not being able to be challenged on their tech chops, but also has the managerial, the rare quality of being a great manager, which has nothing to do with being technical or non-technical. It's just great managers are rare. Mm-hmm. Yeah.

20:03I have seen it too. And I agree with you that it's rare. I think that I'm pointing out some very scary, big problems, some big cultural patterns that can feel almost impossible to push against. But at the same time, what helps me is looking back on my own life or calling back up to, you know, when I sit in a room with developers who've really been through a lot and have been let down by leadership, I often say, can you look at your life and tell me about good times and bad times? Because even within this space, we have variety. There are moments when things are better. And I try to make this point in the book, like, I know that it's scary to look at the things that are going wrong, but you also can't let yourself forget about the things that are going right.

20:52All of the time, people in tech are generous, kind. They've like engaged in my research studies for absolutely no profit, you know, of their own because they wanted to like help other people. I mean, we did a project on code review anxiety, like people who experience deep paralyzing anxiety when they have to actually engage in code review. And some of the people who showed up to our study were highly experienced, you know, people who've been in this field for a long time who told us I had never opened up to anybody about this, but then I saw your study and I realized it could help somebody else.

21:27So I'm here to do it. And even sitting here, it kind of brings a tear to my eye because it's like, you just see the courage that people have like to be better than the environments that they've been in, to believe in a different version. So some of the practical things that I try to help teams do when I work with them to see that vision of a better world for the org is like, let's take a really good hard look at your evidence. Because I bet we can all see patterns in our orgs, like where the teams that actually have that psychological safety are being very effective. Metrics are something that somebody made up.

22:07And I say that as a quantitative social scientist, like there are good ones and bad ones, and we can argue for better metrics. And I have helped teams to do that. I believe in particular right now with agentic coding, we are seeing a lot of stuff rise to the surface. That is overwhelming. That's scary. But I would also suggest, hey, that's an opportunity. Let's not waste this chance when our leaders are actually questioning how things were measured. Let's advocate for a better way of seeing things. So I've introduced measures to software orgs, like one in particular that I love is this survey measure that I wrote called overproduction pressure.

22:50How much do developers feel like if I'm going to choose between like a long-term goal that I actually think is better for our code base or a product or a system or a maintenance or whatever their topic of concern is, right? Is that goal always competing with a short-term productivity goal, which is also a valid goal, by the way. I'm never saying we don't have to care about short-term productivity. But what's really, really interesting is you drop this measure into an eng org I have, for anybody listening to, reach out to me. I'm happy to share it with you. It correlates with all kinds of other bad decisions for software teams.

23:28So the more you turn up the dial on overproduction pressure, the more developers are thinking they're self-censoring. They're not bringing problems to their manager. They're thinking, I'm not going to spend the time to go mentor a junior. There's like this cascading effects just from that initial idea that every time I feel these two things in conflict, the short-term one always has to win. And you can change that. You can actually change that belief fairly easily as long as leaders are really trying and a team's really trying. And I've seen that happen on the order of like not years, but actually just weeks in an org where people say, oh, OK, you told me I'd be safer to try to sometimes turn down some of the short term pressure.

24:12And then I did. And then my boss supported me. Like that's actually the beginning of a culture change that you can get started in kind of very practical ways. You mentioned there about the anxiety of like code reviews, which actually never occurred to me before at all. So now I feel like I need to look at my engineers in a completely different light and just check that they're all OK. Is there anything else? We have a workbook for you. Yeah, you can use. Amazing. Amazing. Is there anything else that kind of came out of the research that really surprised you and that you really want people to be aware of?

24:52Yeah. You know, I'm going to switch gears slightly because we did a very large scale quantitative project that I want more people to know about. And we took a big, hard look at cycle times on software teams. So, you know, a lot of orgs will look at kind of the rate and the velocity of cycle time if you use that kind of tracking in your software environment, you know, say, you know, ticket start to ticket close, that kind of measure. and we looked at it across 216 companies and over 11 ,000 developers I want to say and one of the biggest points from this study was that software work is what we already said highly highly variable and there's such a deep deep belief out there when I go talk to my friends who are engineers there's this deep belief that some people are just a lot faster than other people and some people are like those 10x you know developers and I don't dispute that some people have remarkable skills you know and are maybe at the far end of a distribution in terms of what they know about a programming language or something like that but when you look at the data at scale an individual developer like just follow one person over time which is what we had the chance to do at a huge scale in this study that some weeks that person looks really slow some weeks that person looks really fast and organizations also look very different from each other.

26:17So what that taught me is that if we actually want to fix things in our environment, if we are experiencing like scary moments where work is not advancing, a lot of the answer does not live within the individual. It lives within like the friction of the environment, right? or the nature of the problem that they're having to solve. And so I advise leaders to look for ways to improve their visibility of that. Things like, can I understand and intervene faster if people are working on the wrong thing? Can I identify a kind of work I'm asking people to do that just by its nature will be slower because you're on the edge of what's known or something like that?

27:00And can I stop burning so much organizational gas and resources on like trying to sort people into like fast and slow people because it's not very predictive over time. It's really a lot of misleading metrics. So that's something that really surprised me, actually, because I did kind of expect based on everybody's beliefs about this, that we were going to see more stable sets of developers. Like some easily, we could easily predict some fast people and some slow people over the course of a year. We just did not find that. That is really interesting. And what I find interesting about that as well is like there, I've seen patterns of behavior like that in other teams as well.

27:45And I wonder how much of this is constrained by it being a software team versus actually it just being a team in general. and because it feels like a lot of you know I manage multiple multiple types of teams marketing teams and and creative teams as well and you know there's definitely some transferable learnings there across the research that you've done. I'm glad to hear it yeah I think that it's interesting I think a lot of the things in like my book and my work a lot of types of knowledge workers could resonate with. And I always think about psychology as like, if you don't sort of feel like you're doing the science of the obvious a little bit, you're not doing it right.

28:30Because people should be able to hear what you've learned and say, oh, I recognize that. Oh, like you've this thing in my life. You know, I see some like specific ways that it works out in software because of, you know, the things people are surrounded by or the history of the field. And so, So, you know, my studies dive into that a little bit, like saying, hey, how does anxiety show up in a code review specifically? Like what, you know, are the factors that come in for people? But you're still a human being. You know, the basic logic of how your mind is trying to work with the world, I think, is shared, you know, across all these kinds of teams.

29:08So I love to kind of dive into the specific and then also go to the big and just say, like, what can this teach us about what's shared for all of us? Okay, we made it this far in the interview without saying the dreaded letters AI, but I need to actually say it now. In your experience working with teams as they're starting to work with these tools over the last couple of years, what effect are you seeing? Is it an accelerator? Is it a competitor? Is it an enabler? What's going on? Do teams feel more confident using it, less confident? What have you seen? I think people feel more confident using it than they did six months ago.

29:49I think people feel less confident about the social world around AI. And my very first study about AI was in 2023, so pretty early, 2023, 2024. And we were talking to developers who did not at that point even quite know if it would ever be able to write code. You know, it's very different from the 2026 situation. At the same time, what we decided to study, what I thought was going to matter, has turned out to be, I think, the thing that matters, which is if you have a learning perspective about yourself, if you have a way to understand doing software separate from just always being the one who manually writes the code, you might identify a lot of ways to use this tool.

30:36And on the flip side, there are some very, very real visceral challenges to people's identities that are happening, you know, with this shift. And I'm also living it, you know, I mean, AI can write all of the code that I've ever written, you know, for my computational work. And that's really, really strange. And I'm grappling with that. A few things that I see in my work is that, you know, it's really interesting that a lot of people are actually using AI. There's a lot of fear about skill loss and skill decay, right? And like, are our brains melting? I really don't take that perspective. I actually think that people might be exhausted by AI or they might be in very poor environments for it or some of their leaders might be making very questionable choices about it.

31:26I see all of that. But I also see that when I sit down with developers, even the ones who are very struggling with AI and unsure about it, a lot of them tell me about use cases that are actually about learning and skill building, even though they wouldn't necessarily call it that. But as a learning scientist, I hear that. So they'll say, I'm trying to, I'm using it to dive into like the old parts of our code base and try to understand pieces I never quite understood. Or I'm trying to use it to like understand enough about this other language that I never quite learned before. So that gives me like a lot of hope that we are going to figure out our engineering brains on, you know, this, this use of AI for these teams.

32:11But I'm sorry, I'm rambling in a thousand directions. It's not like it's fine of how big the question is. Yeah. It's not like people were doing bespoke software handwriting every line before. We were cutting and pasting stuff from Stack Overflow for years and using previously existing things and adapting and doing stuff with it. So it's not as so using this as a tool. I totally understand. But I've got a friend who's worked at one of the really big companies that spends ridiculous amounts of money on developer talent and hiring some of the best people in the world. And he was telling me that his measure right now for what makes an exceptional engineer is somebody who is able to work with teams of agents and able to switch their context continuously and maintain their own head.

33:06You know, they're able to just work in lots of contexts all the time. But then I used to work with Simon Willison a bunch of years ago, and he's written about the cognitive tax that comes from that and how exhausted people feel by, you know, 11 in the morning because you're not doing any of the easy stuff. You're just making hard decisions and you're making them fast. And you have to get oriented and make these hard decisions. What do you see? Are you seeing this contributing to burnout? Are you seeing this turning teams into individuals? Or I'm just curious what you're seeing from all this and if there's an example of good.

33:41Yeah, I'm trying to find that example of good. You know, it's funny. Everybody is talking about cognitive scaffolding. I talk about metacognitive scaffolding, which is actually a really big area in psychology and learning science. I don't think we've brought it in here enough. And the reason I like metacognition, so this is kind of like you're thinking about your own thinking. A good example of this is like, you can have kind of your raw memory capacity, how quickly you can consume things, how quickly things come into you. But on top of that, you also learn strategies for thinking. And what's really exciting about metacognitive strategies is that they are malleable.

34:22Like we can actually train people towards better ones. If you've ever heard of the concept of deliberate practice, like doing deliberate practice, which a really great fun paper just came out with 40 ,000 chess players looking at this. I'll send you the link to this. And looking at how much they improved their skills so much more rapidly and efficiently if they were doing deliberate practice, which is much more structured, giving you feedback at the right time. That's a metacognitive strategy. It doesn't require you to magically have like a different memory or different, you know, whatever capacity you have.

34:57Right. But it just helps you use your time better. So I'm interested in are we using developers time very well? And I think right now we're in early days with AI. I think it's a little bit ridiculous and exhausting to be like clicking approve, approve, approve on the agent all the time. I actually do think we're starting to see teams recognize that cost and that fatigue and start to build larger cycles because I think we do need to preserve deep focus, reflection, you know, kind of not treat developers, again, like just these little robots kind of in service of the agents. where I see sophisticated teams doing this you know it's interesting I actually wrote a clod skill called learning opportunities that I wrote almost as a like out of um I don't want to say rage but kind of out of like hey I think we could actually learn even while we're doing agentic coding so I wrote this skill that has coding instead of I've got you that's right this is like the psychologist thing is like I'm gonna you know write an intervention into a skill because I know you all won't leave Claude.

36:09So like if you'll try it here. And what was really fun about this is that several thousand people started using it. And I have just learned so much about developers' agentic coding because I built something, even just a small thing to help them actually learn. And what it does is like, after you push out a bunch of, you know, agent generated code, it will identify opportunities in that code that are relevant to your code base and quiz you on them. And so you have to actually tell the agent how you think things work, and then it kind of helps you. So that is a metacognition exercise. That's like you trying to improve your mental model.

36:52I think there is just a huge design space that has not been built yet. Again, come on in, builders. We need tools around agentic coding to help developers learn and grow, And I'm looking forward to that. It's interesting hearing you talk about sort of that intentional practice. I was having a lot of thoughts about this a couple of years ago for product managers and this idea of kind of bringing play back into work as well and like making it fun and, you know, trying to make it more of an enjoyable experience rather than quick. You have to learn this. Otherwise, you're going to fall behind and like more of a, you know, people trying to inject a bit of fear to um to get people motivated do you like what did did anything come out of your research in terms of like how to introduce that feeling of playing with at work and like bringing that more into into the space to make people feel a little bit more relaxed about everything yeah deeply you know you named something that is actually deeply valuable to me I I love to study thriving, what I call thriving environments.

38:04And then I also love to study threat, like, hey, what's happening to us when we feel very threatened? AI is very threatening for a lot of people. And in my early study on it, I called it AI skill threats, what people are feeling when they imagine that there's going to be a future of software development, where these hard-won skills that they love and treasure that have gotten them so much in life, if those skills suddenly are not valued by other people anymore, you know, do not earn them a place in technical work anymore. That is viscerally painful. But the problem with threat doesn't mean it's not a real problem.

38:42It just means, you know, it puts us in a state where we can't always problem solve very well, because we're desperately trying to avoid the tiger attacking us. One of the beautiful things about connecting to other values about being technical, like loving to learn, you know, being resilient, being adaptive to new technologies, it takes you out of threat state. And that's basically what we found in our AI work, that the people who are in teams that are constantly offering them safe off ramps from threat saying, listen, even if you lose one of these skills, we're going to find a way for you to learn another one.

39:21Technology always changes on us. This is part of what we deal with. We actually can face it together. These are messages that lower the threat temperature. And you just have, it's amazing what people will do with that. You know, they'll just take it and run. So that's kind of what I found about fear in software development. Kat, when products people get together and talk about the developers that we work with, and I know you hate being reductionist about this, but generally the conversations I've had say you place our developers into one of two categories. They're either people who want to be told what to do very specifically and just get on with the coding and be left alone, or people who want to get involved in solving the problem and understand the bigger problem.

40:07And I think that's sometimes too reductive, but I've definitely met people that fall into both of those camps. So I'm curious as to your perspective on that and whether you can take people on the journey from being, you know, what we call code monkeys sometimes and just the people who want to be told what to do and get them more involved? Is there something that we as product people can do to help move people further up the ladder in that? Hmm. I was just thinking for a second because this is a, I'm kind of, this is an interesting question. You know, when you're in a group with people, when you're trying to do something together, people have different goals, right?

40:51And the answer can't be everyone has to come over to my version of the goal. Like I love interviewing people. I'm a psychologist. I know plenty of engineers who are like, please leave me alone. You know, and I value that actually. Like I have benefited in my life from the tools built by many people who would like to not sit down in the same meetings that I would like to sit down in, you know? And so I have to have a model of the world that allows for that, that's big enough for that. But I think what I do want to ask for from people I collaborate with is that you care about my side of it, or you have a larger goal.

41:34And it doesn't mean that you have to achieve this goal by like being a UX researcher. You don't have to achieve this goal by, I tell people this sometimes when I say that software development is social, that doesn't mean you like going to parties. It just means you're collaborating with other minds in the world. And maybe some of you are doing this at home. I mean, Lord knows I chose to become a PhD researcher. So I'm not like out at every party. And there's this concept in psych that I love that we call having superordinate goals, which are like the larger things that we can find that we all want to achieve together that are like, help us see past the smaller conflicts that we might have.

42:15And that's, that's what I try to help teams see. So, you know, I think you will sometimes identify lines where you realize I actually can't get this project done with someone who doesn't agree on this particular superordinate goal. But there might be smaller pieces of it where you're like, all right, I shouldn't take the fact that you don't speak exactly my language or do exactly my activities. I shouldn't take that to mean you don't care that our users get to achieve their outcome. Perhaps you care in a different way or I have to figure out exactly which pieces of the puzzle we're all seeing together.

42:54So I think the superordinate goal is necessary, but we're allowed to have like our individual goals and it might still work right on your team if someone's goal is to like work in a certain language and that's what really excites them you can still use that and collaborate with that right yeah i think that the the real secret for me is it takes all kinds to make up a team and sometimes you do need a specialist and somebody who is just really focused on the language or the architecture or a bit that isn't necessarily the the superordinate goal of the team, but you need them to be able to interact with the other people from time to time.

43:32And you need enough diversity in the team so that it's not all people like that. Yeah. I think there's many routes getting motivated about a goal. Like you can, you know, I think it's a fallacy sometimes we have in tech that everybody has to care really, really hard. I mean, caring really hard is beautiful, but it's also exhausting and is another route to burnout. So to be honest, there's no shame and being like, I would like to be a good member of a solid team, working on a product. Maybe somebody else cares about this product more deeply than I do, but I'm not against it. And I love to achieve other goals in my workplace, like showing up and mentoring juniors or something like that.

44:12There is room for individual people to achieve their goals and not have to like fuel their whole career, I think, on just raw emotion, you know, for the same stuff. So we have to have that perspective too it's such an interesting discussion and uh and one that i one that i love and i'm thoroughly enjoying but um and i've got so many things that i could talk about this experience i've had i literally had one of my engineers print off a picture of a monkey at one point that said i'm a coding monkey and stick it which i think i've told this story a few times on the podcast but um he was he was a unwilling coding monkey so you know he wanted he wanted to participate and much more broadly um just having a hard time with his team so anyway we sorted it out it was all fine in the end but I think when the message worked it definitely worked yeah um I think one of the things for me with this is like giving everyone context as well and um I used to say with my teams, like everyone here is a product manager, like you have a product manager who will guide you and, you know, will lead on lots of things.

45:25But actually, I want everyone thinking like a product person and having that context and, you know, being driven by that, that bigger goal, which is I used to find that quite helpful. Speaking of product managers. So mainly our audience is is product people, product managers and product leaders. what can they do to make the lives of the software teams better easier um more positive and uh yeah how how can we make how can we make these things stick i think that that's such a broad question because people are in so many different situations but some patterns that i see just yield results and good things in unexpected ways like over and over again one thing is, you know, if you feel that there is some breakdown of communication, one of these goal breakdowns, right?

46:19Like being the person who is really curious in that moment and who is able to model that, which I do think a lot of product people have developed those skill sets or feel like, you know, they understand that, right? Because you have this closer connection to users sometimes this, you know, experience. That is a beautiful gift to bring to your engineering colleagues to say, hey, I noticed this feeling of tension. I noticed this moment of, you know, us trying to scope this handoff or something like that. Can you just like, tell me a little more? You know, can you just like, can we look into that?

46:56Can we? And I think that something I realized when I started working with these folks as a researcher was so many people on software teams have felt very excluded from a lot of conversations in our workplaces have just felt like people don't listen to them. And because people don't listen to them, they don't get the chance to understand how to speak in these cross-functional conversations. And because they don't get that experience, then it kind of compounds and they feel worse about it. So providing that listening ear past the first initial moment of friction is I think by itself a beautiful thing to do.

47:34Other things I think to do, you know, that are interesting are like, ask people to teach you, you know, and offer teaching in return. And I love to try to swap like as a learning scientist, everywhere that I've ever worked, we've had kind of like started little learning clubs or little book clubs, we might be kind of like intolerably enthusiastic about learning, but I really believe it's kind of remarkable how you can have someone that you have not always seen eye to eye with, and then you ask them to teach you something that they know or that they're good at, and they'll just like a completely different side of them will come out.

48:12I have seen that really happen from engineers. You know, I sent one of my good friends a picture of my house that we had bought, and he identified like five different things to fix in this picture that I sent him. And so I think finding those like moments of connection in problem solving is really interesting. The other piece I would say is like, listen, it is a really changing world on technology. We have had this world of siloed specialization. I do think that we need to think about all of us doing technical work much more broadly and to think about, you know, if people are starting to do all of this agentic work in your workplace, where do you have specialist skills that you could hand over to your engineers?

49:00Where are your engineers perhaps packaging up specialized skills that you could really benefit from? And I really hope that these two sides out there in the world don't treat everything as like oppositional right now, because I actually think it's a beautifully important moment for us to like package up expertise and share it with each other. Dr. Katix, this has been absolutely fantastic. So the book is The Psychology of Software Teams. We've barely scratched the surface. I'm really enjoying reading it. Is there anything else we should cover before we say goodbye today? I think we did a good job on the really big picture stuff, don't you?

49:41Yeah. Yeah, absolutely. Check out the book for more. I'm working people follow you online. Yes, I'm online microblogging and making ill-advised jokes on Blue Sky and Mastodon under the handle Grimalkina. I write a newsletter called Fight for the Human, where I also talk about research I think is interesting for teams, sometimes release some of my open science work there. And, of course, I also lead a consultancy called Catharsis, in which I work with engineering orgs that want to take a human-centered approach to designing for their software teams. Or more broadly, hey, your technical teams, now that technical means something much bigger and much different.

50:24So you can check all of that out. Fantastic. Thank you so much. We really enjoyed talking to you. Thank you. Thanks, Kat. The product experience hosts are me, Lily Smith, host by night and chief product officer by day. And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work. Luron Pratt is our producer and Luke Smith is our editor.