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

Dr Cat Hicks is a psychological scientist and the founder of Catharsis, a human-centred research consultancy that works with engineering organisations. After self-funding her first open-access study into developer motivation, she was recruited to lead the Developer Success Lab at Pluralsight — a three-year programme that generated large-scale empirical research across hundreds of companies and more than 11,000 developers. Her book, The Psychology of Software Teams, published in July 2026, brings that evidence to bear on the question her industry keeps asking: why do smart people in smart organisations so often struggle to work well together? We talk about the hidden costs of treating developers as interchangeable units, what large-scale cycle time data reveals about individual performance, and how product managers can build the conditions for teams to actually thrive.

Key takeaways

1. The "brains and jars" model — treating developers as interchangeable, isolated computing units — does not just feel demeaning; it actively undermines the collaborative, social work that makes software teams effective, and is linked to burnout, self-censorship, and a breakdown of trust.
2. Cycle time data from 216 companies and over 11,000 developers shows that individual performance fluctuates dramatically week to week — it is not a stable personal trait — which means slow periods are usually an environmental problem, not a personal one.
3. Over-production pressure (the constant pull towards short-term delivery) has measurable cascading effects: developers stop mentoring, stop surfacing problems to managers, and stop investing in long-term code quality. It can be measured and, with committed leadership, changed within weeks.
4. AI is producing genuine identity threats, not just productivity disruption. Teams that lower the "threat temperature" — framing change as a shared technical challenge and affirming that new skills can always be learnt — unlock significantly more adaptive and curious behaviour.
5. Metacognitive scaffolding — building structured strategies for thinking about your own thinking, not just raw output — is more trainable than cognitive capacity and is almost entirely absent from how agentic coding environments are currently designed.
6. Superordinate goals (shared outcomes that transcend individual preferences) allow diverse teams, including those who prefer deep solo work, to collaborate productively without demanding that everyone care about the product in the same way.

Chapters

• (00:00) Opening 
• (01:06) Cat's background and the book 
• (04:40) Defining a software team 
• (07:02) Building the Developer Success Lab 
• (10:26) The brains and jars model 
• (13:14) What the model costs teams 
• (17:54) Why communicating value is so hard 
• (19:04) What change looks like in practice 
• (23:01) Code review anxiety and cycle time research 
• (27:55) AI's effect on developer identity 
• (31:57) Agentic coding and cognitive fatigue 
• (35:46) Threat, play, and psychological safety 
• (38:19) Working across disciplines 
• (43:04) What product managers can do 
• (48:00) Wrap-up

Referenced

• The Psychology of Software Teams by Dr Cat Hicks
• The Programmer's Brain by Felienne Hermans
• The Psychology of Computer Programming by Gerald Weinberg
• Developer Success Lab (Pluralsight)
• DORA project
• Catharsis — Dr Cat Hicks's consultancy
• Fight for the Human — Dr Cat Hicks's newsletter
• Dr Cat Hicks
• Learning Opportunities Claude skill — by Dr Cat Hicks
• Deliberate practice and chess improvement study (44,000 Chess.com players)

Our Hosts
Lily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. She’s worked on a diverse range of products – leading the product teams through discovery, prototyping, testing and delivery. Lily also founded ProductTank Bristol and runs ProductCamp in Bristol and Bath.

Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He’s the author of What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon’s music stores in the US & UK.

Transcript

Copy

SPEAKER_03 0:00

Caring 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. This 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. 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?

SPEAKER_00 1:20

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. Um 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 what's the book about?

SPEAKER_03 1:40

Yeah, 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 um, you know, I worked in how 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 like set of circumstances. And I just really was captivated by this. Like, on the one hand, these were incredibly valued people, people who were obviously did intellectual work and the companies, you know, fueled this like massive international economy that I was like 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 like how to have a good culture together. So I decided there was like something really, really interesting going on here. And 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. I did this, I'm a psychologist. And I 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. So 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.

SPEAKER_00 4:40

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 are you you talked about technicals. Are you focusing specifically on developers? Do you include other people? What do you uh define as a software team?

SPEAKER_03 5:04

Oh, okay. Yeah, great question to start with. Because the title's actually a little bit of an inside joke. Because if you look for books like this, you'll notice they'll maybe there'll be like the programmer's brain, the psychology, uh, which is um uh Felene Erman's, I want to say, and there's the psychology of computer programming by Gerald Weinberg, which is a 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. So 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 are 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. I 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.

SPEAKER_01 7:02

And what was the response like to you you said you kind of um reached out to lots of people to recruit everyone for your research?

SPEAKER_03 7:10

Yeah.

SPEAKER_01 7:11

Um what was the response like to that recruitment? Like how were people just curious to know what you would learn? And did they come with questions themselves of like, oh yeah, if you're doing this, can you help us solve this problem?

SPEAKER_03 7:24

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, um, I actually got reached out to by a tech company by Pluralsite, 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. And 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. Um, 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. And in the Dev Success Lab, I knew I wanted to invite developers into like how we designed 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. So 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 gonna show you why you should come join this project. I'm gonna show you what I'm gonna do with it. I'm gonna show you why I wrote the questions these ways. I'm gonna show you like the statistics that we ran. You know, I'm gonna 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. Um, but then I'm I'm happy to say, I mean, we had incredible experiences running these studies. Um, something I'm very proud of. This is a lawn answer. I'm sorry, you can tell I'm passionate about research design, but something 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 like 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.

SPEAKER_00 10:25

One of the things I really liked is you you talk about the fundamental problems. It's not just output that uh is a problem here, it is the perception of the people on these teams as well as their ability to communicate value and and to have their value recognized. But you have a wonderful sci-fi retro sci-fi term for how people are are seeing. So I'll 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 uh being recognized for the the actual value that we can contribute?

SPEAKER_03 11:02

Yeah. So when you look at the world, you spin up a mental model of what you're seeing. You 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 light 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, and I was like, this is it's getting something good, right? Like if 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 could 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. And 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. It helps you kind of understand how you keep getting stuck in things that seem like they're gonna work for the short term, but really fall apart in the long term.

SPEAKER_01 13:14

Now there's something 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 jar.

SPEAKER_03 13:33

We do it to ourselves, listen.

unknown 13:36

Yeah.

SPEAKER_01 13:37

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 of people feeling like they are more than just the person who's calculating the solution or whatever.

SPEAKER_03 13:54

So 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 gonna 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. The 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 at 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. So 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. And then you end up with these strange situations where we we rely on collaboration or we rely on a lot of important social work happening in technical communities, 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 gonna get promoted for it, or we're never gonna like you know, call it out on stage. And 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 costs of this.

SPEAKER_00 16:25

We also have the problem, you know, that a lot of the people who work in technical fields are neurodivergent in in different ways. And 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 uh 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 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 building this is uh we can predict the the val the 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 um or software. When 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. Um 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? Why are we stuck in this? Why can't we communicate value very well?

SPEAKER_03 18:03

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.

SPEAKER_00 18:13

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 the rare quality of of being a great manager, which has nothing to do with being technical or non-technical, it's just great managers are rare.

SPEAKER_03 18:39

Mm-hmm. Mm-hmm. Yeah. I 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, you know, some big cultural patterns that can feel almost impossible to push against. But at the same time, what helps me is like 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 who've been let down by leadership, I often say, Can you look at your life and 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. All 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 have never opened up to anybody about this, but then I saw your study and I realized it could help somebody else. So I'm here to do it. And um, even sitting here, it kind of brings a tear in 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. Um, metrics are something that somebody made up. And 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, whoa, 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. You know, 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. How 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 our 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? Like 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 end org I have, like, you know, for anybody listening to, like, reach out to me, I'm happy to share. It with you, it correlates with all kinds of other bad decisions for software teams.

SPEAKER_02 22:06

So 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 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.

SPEAKER_03 22:28

And you can change that. Like you can actually change that belief fairly easily as long as leaders are really trying and a team's really trying.

SPEAKER_02 22:38

And I've seen that happen on the order of like not years, but actually just weeks in an org where people say, Oh, okay, you told me I'd be safer to try to sometimes turn down some of the short-term pressure. And 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.

SPEAKER_01 23:01

You mentioned there about the anxiety of like code reviews, which actually had 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 okay. Is there anything else?

SPEAKER_03 23:16

We have a workbook for you. Yeah, you can use.

SPEAKER_01 23:19

Amazing. Amazing. Is there anything else that kind of came out of the research that really surprised you and that you really, you know, want people to be aware of?

SPEAKER_03 23:30

Yeah. You know, I'm gonna switch gears slightly um 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. Yeah. And we looked at it across 216 companies and over 11,000 um 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. So, 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, you know, identify a kind of work I'm asking people to do that just by its nature will be slower because you're on like the edge of what's known or something like that. And 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 gonna 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. And we just did not find that.

SPEAKER_01 26:12

That is really interesting. And it uh what I find interesting about that as well is like there, I've seen patterns of behavior like that in other teams as well. And I wonder how much of this is constrained by it being a software team versus actually it just being a team in general. Um and because it feels like a lot of, you know, I manage multiple, multiple types of teams, marketing teams and um and creative teams as well. And, you know, there's definitely some transferable learnings there across um the research that you've done.

SPEAKER_03 26:51

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 if you don't sort of feel like you're doing the science of the obvious a little bit, it you're not doing it right because people should be able to hear what you've learned and say, oh, I recognize that. Oh, like you've named 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, 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. So 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?

SPEAKER_00 27:55

Okay, we made it this far in the interview without saying the dreaded letters AI, but I I need to actually say it now. Um, 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 what's going on? Do teams feel more confident using it, less confident? What are you seeing?

SPEAKER_03 28:23

I think few people feel more confident using it than they did six months ago. I 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, you know, 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 like 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. And on this, 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 we are our brains melting? Um, I really don't take that perspective. I actually think that people might be exhausted by AI or they might be in very poor, you know, environments for it, or some of their leaders might be making very questionable choices about it. I 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 use of AI for these teams. But I'm sorry, I'm rambling in a thousand directions. I'm not sure. It's not like it's despite how big the question is. Yeah.

SPEAKER_00 30:57

It's not like people were uh 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 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 uh worked at what working at one of the the really big companies that spends ridiculous amounts of money on on developer talent um and hiring you know some of the best people in the world, and he was telling me that his measure right now for what makes a 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. You know, they're able to just work in lots of context 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 it 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 are you seeing? 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.

SPEAKER_03 32:20

Yeah, I'm trying to find that example of good. I, you know, it's funny, everybody's 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. Like 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, you know, 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, right? 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 Claude 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 range coding instead of identity. That's right. This is like the psychologist thing is like, I'm gonna, you know, write an intervention into a skill. Um, because I know you all won't leave Claude. So like if you'll try it here. And um 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, like 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. I think there is just a huge design space that has not been built yet. Again, like come on in, builders. We need tools around agentic coding to help developers like learn and grow. And I I'm looking forward to that.

SPEAKER_01 35:46

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 uh 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 a an enjoyable experience rather than quick, you have to learn this, otherwise you're gonna 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 the space to make people feel a little bit more relaxed about everything?

SPEAKER_03 36:32

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. And 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 threat, 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, and 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. It 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 gonna find a way for you to learn another one. Technology 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.

SPEAKER_00 38:18

Ken, when product 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 know, 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. And 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 uh, you know, what do 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 uh further up the ladder in that?

SPEAKER_03 39:15

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? And 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 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. And it doesn't be mean that you have to achieve this goal by like being a UX researcher. You don't have to achieve this goal by I 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. And 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, you know, that our users get to achieve their outcome. You just perhaps you care in a different way, or I have to figure out exactly which pieces of the puzzle we're all seeing together. So 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?

SPEAKER_00 41:49

Yeah, I think the 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 superordinate goal of the team, but you need them to be able to interact with the other people from time to time, and you need enough diversity in the team so that it's not all people like that.

SPEAKER_03 42:17

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 in being like, I would like to be a good member of a solid team, work 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. There, there 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.

SPEAKER_01 43:04

It's such an interesting discussion and uh 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, the experience that 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 next to his desk, which I think I've told this story a few times on the podcast. But um, he was he was uh 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. manager who will guide you and you know will lead on lots of things but 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 um I 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?

SPEAKER_03 44:37

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? Like 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 uh this feeling of tension I 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? Can 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. You know, so providing that listening ear past the first initial moment of friction is I think by itself a beautiful thing to do. Other 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. I have seen that really happen from engineers.

SPEAKER_02 46:54

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.

SPEAKER_03 47:05

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? Where 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 a beautifully important for us to like package up expertise and share it with each other.

SPEAKER_00 47:59

Dr. Caddox 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.

SPEAKER_03 48:10

Is there anything else we should we should cover before we say goodbye today I think we did a good job on the really big picture stuff don't you yeah absolutely so check out the book for more and where can people follow you online? Yes I'm online microblogging and making ill-advised jokes um 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 um sometimes release some of my open science work there. And um of course I also lead a consultancy called Catharsis which 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 uh now that technical means something much bigger and much different so you can check all of that out.

SPEAKER_00 49:05

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.

SPEAKER_01 49:27

Lou Ron Pratt is our producer and Luke Smith is our editor.