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

WEBVTT
00:00:00.080 --> 00:00:05.839
Caring really hard is beautiful, but it's also exhausting and is another route to burnout.
00:00:06.080 --> 00:00:12.160
Sometimes this weird experience where you sit in a room with leaders and you realize they're thinking about developers this way.
00:00:12.320 --> 00:00:15.199
Individual developers feel less productive.
00:00:15.439 --> 00:00:27.679
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.
00:00:27.920 --> 00:00:30.399
That is viscerally painful.
00:00:30.640 --> 00:00:34.479
Even if you lose one of these skills, we're gonna find a way for you to learn another one.
00:00:34.719 --> 00:00:36.159
Technology always changes on us.
00:00:36.240 --> 00:00:38.079
This is part of what we deal with.
00:00:38.240 --> 00:00:40.399
We actually can face it together.
00:00:40.719 --> 00:00:42.799
Why can't we communicate value very well?
00:00:43.039 --> 00:00:47.039
Can you look at your life and tell me about good times and bad times?
00:00:47.200 --> 00:00:50.320
Because even within this space, we have variety.
00:00:50.399 --> 00:00:52.159
There are moments when things are better.
00:00:52.399 --> 00:00:54.399
Everybody is talking about cognitive scaffolding.
00:00:54.479 --> 00:01:01.920
I talk about metacognitive scaffolding, which is actually a really big area in psychology and learning science.
00:01:09.599 --> 00:01:10.879
Oh, I'm doing so well.
00:01:11.040 --> 00:01:17.599
I'm on a little lake retreat right now, uh, enjoying my book launch and hanging out on a paddleboard most days.
00:01:17.680 --> 00:01:18.879
So I think I'm doing great.
00:01:18.959 --> 00:01:19.359
How about you?
00:01:20.079 --> 00:01:20.719
Fantastic.
00:01:20.799 --> 00:01:26.400
I I wish I was on a lake and on a paddleboard, but I'm sadly working away the summer at this point.
00:01:26.480 --> 00:01:28.239
But August, August will be better.
00:01:28.319 --> 00:01:29.519
Um wonderful.
00:01:29.840 --> 00:01:31.280
And you mentioned your book launch.
00:01:31.359 --> 00:01:33.200
So you just came out with a new book.
00:01:33.359 --> 00:01:35.680
Tell us about it and tell us about yourself.
00:01:35.840 --> 00:01:37.680
How did you get into this space in the first place?
00:01:37.840 --> 00:01:40.319
What do you do these days and what's what's the book about?
00:01:40.799 --> 00:01:41.840
Yeah, yeah.
00:01:42.159 --> 00:01:45.680
I am a psychologist and I've been a psychologist for a long, long time.
00:01:45.840 --> 00:01:49.519
But it took me a while to discover tech and to discover software teams.
00:01:49.599 --> 00:01:52.719
And so I'll tell that story first, which is also in the book.
00:01:52.799 --> 00:01:54.319
So it's a good lead up.
00:01:54.799 --> 00:02:02.640
But um, you know, I worked in how the science of how people learn and the cognitive science of kind of learning and performance.
00:02:02.719 --> 00:02:06.560
And I worked in classrooms and I really, really loved that stuff.
00:02:06.719 --> 00:02:14.080
And then I got to Silicon Valley and I started leading like large-scale kind of educational programs in tech.
00:02:14.159 --> 00:02:26.960
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.
00:02:27.199 --> 00:02:29.759
And I just really was captivated by this.
00:02:29.919 --> 00:02:42.479
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.
00:02:42.719 --> 00:02:51.759
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.
00:02:52.080 --> 00:02:55.280
I don't know how to collaborate with my teammates.
00:02:55.599 --> 00:02:57.919
We are all of these very intelligent people.
00:02:58.080 --> 00:03:02.479
We care about our work, but we can't seem to figure out like how to have a good culture together.
00:03:02.800 --> 00:03:07.439
So I decided there was like something really, really interesting going on here.
00:03:07.599 --> 00:03:15.039
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.
00:03:15.199 --> 00:03:22.719
And then from the other direction, I was like, well, psychology and human behavior, we haven't really spent enough time with these teams.
00:03:22.800 --> 00:03:32.639
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.
00:03:32.800 --> 00:03:36.319
So both directions, I felt like there was something incredibly valuable there.
00:03:36.560 --> 00:03:46.560
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.
00:03:46.719 --> 00:03:48.319
I did this, I'm a psychologist.
00:03:48.400 --> 00:03:51.280
And I there's not really like a job out there.
00:03:51.520 --> 00:03:56.400
You know, if you look on LinkedIn, there's no like psychologist for software teams job listing.
00:03:56.639 --> 00:04:01.120
And so I decided to kind of try to make one and start publishing work.
00:04:01.280 --> 00:04:05.280
And that led to all of the research that's in the book now.
00:04:05.439 --> 00:04:16.399
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.
00:04:16.560 --> 00:04:21.759
So, like, what does help your motivation and why is it hard to get time to learn?
00:04:21.839 --> 00:04:33.360
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.
00:04:33.519 --> 00:04:34.800
So that's what the book's about.
00:04:34.879 --> 00:04:40.160
It's about like the questions I kept getting asked, you know, as your psychologist friend in this industry.
00:04:40.480 --> 00:04:41.199
Fantastic.
00:04:41.360 --> 00:04:44.399
And so the book is the psychology of software teams.
00:04:44.800 --> 00:04:54.399
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.
00:04:54.560 --> 00:04:57.040
And so are you you talked about technicals.
00:04:57.279 --> 00:04:59.680
Are you focusing specifically on developers?
00:04:59.839 --> 00:05:01.040
Do you include other people?
00:05:01.199 --> 00:05:04.399
What do you uh define as a software team?
00:05:04.879 --> 00:05:05.759
Oh, okay.
00:05:05.920 --> 00:05:07.839
Yeah, great question to start with.
00:05:08.079 --> 00:05:12.079
Because the title's actually a little bit of an inside joke.
00:05:12.240 --> 00:05:29.680
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.
00:05:29.920 --> 00:05:34.399
There are other people who have worked on these topics, and these are like really interesting contributions.
00:05:34.639 --> 00:05:39.839
But something that I noticed is that just a ton of this stuff is all about individuals.
00:05:40.079 --> 00:05:45.759
So it might be like a picture of a brain on the cover, or you know, about you as a single solitary person.
00:05:46.079 --> 00:05:53.759
My kind of psychology, I'm really, really interested in environments and groups and kind of these emergent things that happen.
00:05:54.079 --> 00:05:55.759
So I chose teams.
00:05:55.920 --> 00:06:09.600
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.
00:06:09.759 --> 00:06:13.759
So you're actually kind of part of this big shared global team.
00:06:14.079 --> 00:06:18.240
So I think of developer as an incredibly broad camp.
00:06:18.319 --> 00:06:27.600
Like it's really anybody who chooses to try to engage with this big overlapping, interdependent, complex sets of technical systems.
00:06:27.680 --> 00:06:31.680
So that could be you were literally learning to read code for the first time.
00:06:31.920 --> 00:06:38.240
It could be even a product person who is now striking out into writing code these days much more than they would.
00:06:38.399 --> 00:06:46.720
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.
00:06:46.879 --> 00:06:50.079
I'm using it because we don't really know what word to use now.
00:06:50.319 --> 00:06:56.160
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.
00:06:56.240 --> 00:06:58.800
It's like, hey, you want to build, come on in.
00:06:58.959 --> 00:07:02.079
Come on in and let's talk about what will help you build.
00:07:02.560 --> 00:07:10.319
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?
00:07:10.560 --> 00:07:11.040
Yeah.
00:07:11.199 --> 00:07:14.319
Um what was the response like to that recruitment?
00:07:14.480 --> 00:07:18.000
Like how were people just curious to know what you would learn?
00:07:18.079 --> 00:07:24.319
And did they come with questions themselves of like, oh yeah, if you're doing this, can you help us solve this problem?
00:07:24.720 --> 00:07:26.959
Yeah, a huge range of responses.
00:07:27.199 --> 00:07:36.800
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.
00:07:37.040 --> 00:07:48.079
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.
00:07:48.240 --> 00:07:52.560
We want to know what it would take for you to set up a research lab here.
00:07:52.720 --> 00:08:02.319
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?
00:08:02.480 --> 00:08:04.240
This is such a strange experiment.
00:08:04.399 --> 00:08:11.360
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.
00:08:11.439 --> 00:08:14.959
So there wasn't really a vocabulary that existed.
00:08:15.040 --> 00:08:25.279
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.
00:08:25.519 --> 00:08:31.439
We wanted to do something a little more unusual with the Developer Success Lab, which I led for three years.
00:08:31.600 --> 00:08:41.600
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.
00:08:41.840 --> 00:08:45.039
So honestly, there was a lot of excitement.
00:08:45.120 --> 00:08:49.039
There was a lot of joy at that prospect from like our public audience.
00:08:49.200 --> 00:08:56.080
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?
00:08:56.240 --> 00:08:57.679
Like, what is this?
00:08:58.080 --> 00:09:11.039
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.
00:09:11.279 --> 00:09:17.440
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.
00:09:17.679 --> 00:09:20.480
I'm gonna show you why you should come join this project.
00:09:20.559 --> 00:09:22.000
I'm gonna show you what I'm gonna do with it.
00:09:22.080 --> 00:09:24.240
I'm gonna show you why I wrote the questions these ways.
00:09:24.320 --> 00:09:27.360
I'm gonna show you like the statistics that we ran.
00:09:27.519 --> 00:09:30.080
You know, I'm gonna show you our privacy policy.
00:09:30.240 --> 00:09:39.919
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.
00:09:40.080 --> 00:09:45.279
Um, but then I'm I'm happy to say, I mean, we had incredible experiences running these studies.
00:09:45.440 --> 00:09:47.120
Um, something I'm very proud of.
00:09:47.360 --> 00:09:48.320
This is a lawn answer.
00:09:48.399 --> 00:09:58.159
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.
00:09:58.240 --> 00:10:01.840
We had a really high percentage of non-white developers answer our studies.
00:10:02.000 --> 00:10:11.759
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.
00:10:11.919 --> 00:10:16.000
You know, this comes from science and psychology that's going to help you.
00:10:16.080 --> 00:10:19.360
It's not just like product marketing, you know, to try to sell you a product.
00:10:19.600 --> 00:10:23.440
So I think all of that built trust, but it took a time.
00:10:23.519 --> 00:10:25.360
Yeah, it took like several years.
00:10:25.840 --> 00:10:31.600
One of the things I really liked is you you talk about the fundamental problems.
00:10:31.679 --> 00:10:44.480
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.
00:10:44.639 --> 00:10:50.480
But you have a wonderful sci-fi retro sci-fi term for how people are are seeing.
00:10:50.559 --> 00:10:52.080
So I'll I'll let you jump in with that.
00:10:52.159 --> 00:10:55.120
But just why are we all kind of recognized that way?
00:10:55.200 --> 00:11:01.600
And why do we have so much trouble uh being recognized for the the actual value that we can contribute?
00:11:02.080 --> 00:11:02.720
Yeah.
00:11:02.960 --> 00:11:07.600
So when you look at the world, you spin up a mental model of what you're seeing.
00:11:07.679 --> 00:11:09.679
You make interpretations about that world.
00:11:09.759 --> 00:11:19.919
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.
00:11:20.159 --> 00:11:24.559
We have those models about people too, and about our social worlds.
00:11:24.799 --> 00:11:31.759
And the metaphor I used in the book that I love is called the brains in jars model of software development.
00:11:32.000 --> 00:11:36.559
And this is like the evil scientist light laboratory.
00:11:36.720 --> 00:11:41.519
If you can imagine like the brains in the jars, and there's like the bad fluorescent lighting.
00:11:41.759 --> 00:11:52.720
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?
00:11:52.799 --> 00:11:54.720
Like if people recognize your joke.
00:11:54.960 --> 00:11:57.600
But it's actually very, very serious at the heart of it.
00:11:57.679 --> 00:12:04.159
It's like we see software development as this activity that is like stuck inside of people's brains.
00:12:04.399 --> 00:12:05.759
Everybody's interchangeable.
00:12:05.840 --> 00:12:14.159
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.
00:12:14.480 --> 00:12:22.639
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?
00:12:22.879 --> 00:12:28.960
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.
00:12:29.039 --> 00:12:31.039
And you say, listen, I've seen you work.
00:12:31.120 --> 00:12:34.000
I actually know that you're doing something much more complicated than this.
00:12:34.240 --> 00:12:42.559
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.
00:12:42.639 --> 00:12:47.120
Like you're not just this robot, you know, functioning in this isolated way.
00:12:47.759 --> 00:12:51.200
But, you know, our minds, we really like heuristics.
00:12:51.360 --> 00:12:56.799
So I think we get stuck in this kind of model because it's a little bit scary to challenge it.
00:12:56.960 --> 00:13:04.720
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.
00:13:04.799 --> 00:13:13.279
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.
00:13:14.320 --> 00:13:33.519
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.
00:13:33.840 --> 00:13:35.679
We do it to ourselves, listen.
00:13:36.559 --> 00:13:37.200
Yeah.
00:13:37.600 --> 00:13:40.879
I guess what's the the problem with that thinking?
00:13:41.039 --> 00:13:54.159
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.
00:13:54.480 --> 00:13:57.519
So I think a whole family of problems comes from this.
00:13:57.840 --> 00:14:08.559
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.
00:14:08.720 --> 00:14:12.559
So think about burnout as a version of this.
00:14:12.720 --> 00:14:22.879
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.
00:14:23.200 --> 00:14:35.600
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.
00:14:35.919 --> 00:14:42.799
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.
00:14:42.960 --> 00:14:55.039
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.
00:14:55.200 --> 00:14:58.559
So individual developers feel less productive.
00:14:58.799 --> 00:15:06.960
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.
00:15:07.039 --> 00:15:13.519
And so they don't engage in processes that actually help them upskill and help them kind of face challenge.
00:15:13.679 --> 00:15:20.399
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.
00:15:20.559 --> 00:15:25.279
But there's actually a very cold, hard economic reason to care about this too.
00:15:25.519 --> 00:15:37.039
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.
00:15:37.279 --> 00:15:54.639
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.
00:15:54.799 --> 00:16:07.200
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.
00:16:07.279 --> 00:16:09.759
So we need it, like with one hand we're saying, please do it.
00:16:09.840 --> 00:16:16.320
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.
00:16:16.559 --> 00:16:21.519
And I think that just makes kind of destroys people's like trust in their organizations and communities.
00:16:21.600 --> 00:16:24.879
So there's many angles to look at the costs of this.
00:16:25.679 --> 00:16:35.039
We also have the problem, you know, that a lot of the people who work in technical fields are neurodivergent in in different ways.
00:16:35.360 --> 00:16:39.200
And also a lot of people need time to just sit and think and do.
00:16:39.279 --> 00:16:45.279
And it is not a deterministic process, it's not give me one hour and I will solve this problem.
00:16:45.440 --> 00:16:46.879
It is I need some time.
00:16:47.039 --> 00:16:57.120
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.
00:16:57.360 --> 00:17:04.079
Sometimes it's talking to other people, and we don't always really value all of those aspects of things.
00:17:04.240 --> 00:17:07.519
We want a very strict formula, we want this to be a factory.
00:17:07.599 --> 00:17:17.759
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.
00:17:17.920 --> 00:17:22.799
And to be honest, I don't think this is specific to engineers um or software.
00:17:22.880 --> 00:17:24.799
When I was a journalist, it was the same thing.
00:17:25.039 --> 00:17:31.759
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.
00:17:31.839 --> 00:17:36.640
There's a reason that, you know, the New Yorker magazine is so much better than most other things.
00:17:36.799 --> 00:17:40.640
It's because they pay more and give people time to actually work on those stories.
00:17:40.799 --> 00:17:56.799
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.
00:17:56.960 --> 00:17:58.480
So, how do we change this?
00:17:58.559 --> 00:17:59.839
Why are we stuck in this?
00:17:59.920 --> 00:18:02.160
Why can't we communicate value very well?
00:18:03.440 --> 00:18:05.599
Let me throw a question back to you for a second.
00:18:05.759 --> 00:18:07.839
Have you seen a leader do this?
00:18:08.079 --> 00:18:13.279
Like actually shift the org and take a longer-term perspective.
00:18:13.920 --> 00:18:14.720
Rarely.
00:18:15.519 --> 00:18:16.880
Very occasionally, but rarely.
00:18:17.039 --> 00:18:39.519
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.
00:18:39.839 --> 00:18:40.319
Mm-hmm.
00:18:40.400 --> 00:18:40.799
Mm-hmm.
00:18:40.960 --> 00:18:41.599
Yeah.
00:18:42.559 --> 00:18:46.880
I have seen it too, and I agree with you that it's rare.
00:18:47.200 --> 00:18:57.039
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.
00:18:57.359 --> 00:19:14.480
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?
00:19:14.799 --> 00:19:17.839
Because even within this space, we have variety.
00:19:18.000 --> 00:19:19.920
There are moments when things are better.
00:19:20.079 --> 00:19:30.640
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.
00:19:30.880 --> 00:19:35.519
All of the time, people in tech are generous, kind.
00:19:36.079 --> 00:19:42.160
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.
00:19:42.319 --> 00:19:51.200
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.
00:19:51.359 --> 00:20:06.400
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.
00:20:06.559 --> 00:20:08.079
So I'm here to do it.
00:20:08.240 --> 00:20:20.799
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.
00:20:21.119 --> 00:20:34.240
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.
00:20:34.559 --> 00:20:42.559
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.
00:20:42.880 --> 00:20:46.240
Um, metrics are something that somebody made up.
00:20:46.480 --> 00:20:53.200
And I say that as a quantitative social scientist, like there are good ones and bad ones, and we can argue for better metrics.
00:20:53.279 --> 00:20:55.519
And I have helped teams to do that.
00:20:55.680 --> 00:21:05.599
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.
00:21:05.680 --> 00:21:09.119
But I would also suggest, hey, that's an opportunity.
00:21:09.279 --> 00:21:19.519
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.
00:21:19.759 --> 00:21:28.720
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.
00:21:28.960 --> 00:21:40.720
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?
00:21:41.119 --> 00:21:48.160
Is that goal always competing with a short-term productivity goal, which is also a valid goal, by the way?
00:21:48.240 --> 00:21:52.000
Like I'm never saying we don't have to care about short-term productivity.
00:21:52.160 --> 00:21:59.759
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.
00:22:00.240 --> 00:22:06.640
It with you, it correlates with all kinds of other bad decisions for software teams.
00:22:06.880 --> 00:22:15.759
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.
00:22:15.920 --> 00:22:19.279
They're thinking, I'm not going to spend the time to go mentor junior.
00:22:19.359 --> 00:22:28.079
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.
00:22:28.319 --> 00:22:29.599
And you can change that.
00:22:29.759 --> 00:22:38.240
Like you can actually change that belief fairly easily as long as leaders are really trying and a team's really trying.
00:22:38.319 --> 00:22:50.799
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.
00:22:50.960 --> 00:22:53.599
And then I did, and then my boss supported me.
00:22:53.759 --> 00:23:00.160
Like that's actually the beginning of a culture change that you can get started in kind of very practical ways.
00:23:01.039 --> 00:23:07.599
You mentioned there about the anxiety of like code reviews, which actually had never occurred to me before at all.
00:23:07.759 --> 00:23:15.200
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.
00:23:15.440 --> 00:23:16.240
Is there anything else?
00:23:16.640 --> 00:23:17.759
We have a workbook for you.
00:23:17.839 --> 00:23:19.039
Yeah, you can use.
00:23:19.599 --> 00:23:20.160
Amazing.
00:23:20.400 --> 00:23:21.039
Amazing.
00:23:21.279 --> 00:23:30.000
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?
00:23:30.480 --> 00:23:31.119
Yeah.
00:23:31.599 --> 00:23:39.279
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.
00:23:39.599 --> 00:23:44.400
And we took a big hard look at cycle times on software teams.
00:23:44.480 --> 00:23:57.200
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.
00:23:57.440 --> 00:23:57.680
Yeah.
00:23:58.000 --> 00:24:06.400
And we looked at it across 216 companies and over 11,000 um developers, I want to say.
00:24:06.720 --> 00:24:14.640
And one of the biggest points from this study was that software work is what we already said, highly, highly variable.
00:24:14.799 --> 00:24:17.200
And there's such a deep, deep belief out there.
00:24:17.279 --> 00:24:22.799
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.
00:24:23.119 --> 00:24:26.319
And some people are like those 10x, you know, developers.
00:24:26.559 --> 00:24:35.759
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.
00:24:36.000 --> 00:24:51.359
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.
00:24:51.839 --> 00:24:55.920
And organizations also look very different from each other.
00:24:56.160 --> 00:25:09.680
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.
00:25:09.920 --> 00:25:13.599
It lives within like the friction of the environment, right?
00:25:13.839 --> 00:25:17.039
Or the nature of the problem that they're having to solve.
00:25:17.279 --> 00:25:22.559
And so I advise leaders to look for ways to improve their visibility of that.
00:25:22.799 --> 00:25:28.799
Things like, can I understand and intervene faster if people are working on the wrong thing?
00:25:29.119 --> 00:25:38.960
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.
00:25:39.279 --> 00:25:49.599
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.
00:25:49.839 --> 00:25:52.160
It's really a lot of misleading metrics.
00:25:52.400 --> 00:26:09.200
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.
00:26:09.279 --> 00:26:11.599
And we just did not find that.
00:26:12.480 --> 00:26:13.599
That is really interesting.
00:26:13.680 --> 00:26:23.359
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.
00:26:23.839 --> 00:26:32.000
And I wonder how much of this is constrained by it being a software team versus actually it just being a team in general.
00:26:32.319 --> 00:26:42.559
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.
00:26:42.880 --> 00:26:51.279
And, you know, there's definitely some transferable learnings there across um the research that you've done.
00:26:51.839 --> 00:26:52.799
I'm glad to hear it.
00:26:52.880 --> 00:26:54.559
Yeah, I think that it's interesting.
00:26:54.640 --> 00:27:01.359
I think a lot of the things in like my book and my work, a lot of types of knowledge workers could resonate with.
00:27:01.440 --> 00:27:13.359
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.
00:27:13.519 --> 00:27:16.400
Oh, like you've named this thing in my life.
00:27:16.559 --> 00:27:25.680
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.
00:27:25.839 --> 00:27:34.079
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?
00:27:34.240 --> 00:27:37.200
Like what, you know, are the factors that come in for people?
00:27:37.440 --> 00:27:46.400
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.
00:27:46.480 --> 00:27:54.880
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?
00:27:55.440 --> 00:28:03.039
Okay, we made it this far in the interview without saying the dreaded letters AI, but I I need to actually say it now.
00:28:03.279 --> 00:28:11.119
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?
00:28:11.279 --> 00:28:12.640
Is it an accelerator?
00:28:12.799 --> 00:28:13.759
Is it a competitor?
00:28:13.920 --> 00:28:15.200
Is it an enabler?
00:28:15.359 --> 00:28:16.720
What's what's going on?
00:28:17.519 --> 00:28:20.799
Do teams feel more confident using it, less confident?
00:28:21.680 --> 00:28:22.880
What are you seeing?
00:28:23.519 --> 00:28:28.319
I think few people feel more confident using it than they did six months ago.
00:28:28.480 --> 00:28:33.200
I think people feel less confident about the social world around AI.
00:28:33.680 --> 00:28:40.880
And my very first study about AI was in 2023, so pretty early, 2023, 2024.
00:28:41.279 --> 00:28:48.240
And we were talking to developers who did not at that point even quite know if it would ever be able to write code.
00:28:48.400 --> 00:28:50.960
You know, it's very different from the 2026 situation.
00:28:51.279 --> 00:29:14.559
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.
00:29:14.720 --> 00:29:23.680
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.
00:29:23.920 --> 00:29:26.400
And I'm also living it, you know.
00:29:26.480 --> 00:29:31.759
I mean, AI can write all of the code that I've ever written, you know, for my computational work.
00:29:31.839 --> 00:29:33.279
And that's really, really strange.
00:29:33.359 --> 00:29:35.039
And I'm grappling with that.
00:29:35.599 --> 00:29:44.400
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.
00:29:45.039 --> 00:29:47.839
There's a lot of fear about skill loss and skill decay, right?
00:29:47.920 --> 00:29:50.000
And like, are we are our brains melting?
00:29:50.240 --> 00:29:52.480
Um, I really don't take that perspective.
00:29:52.640 --> 00:30:04.720
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.
00:30:04.799 --> 00:30:21.680
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.
00:30:21.759 --> 00:30:24.000
But as a learning scientist, I hear that.
00:30:24.240 --> 00:30:33.119
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.
00:30:33.279 --> 00:30:39.440
Or I'm trying to use it to like understand enough about this other language that I never quite learned before.
00:30:39.599 --> 00:30:50.400
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.
00:30:50.640 --> 00:30:53.200
But I'm sorry, I'm rambling in a thousand directions.
00:30:53.279 --> 00:30:53.680
I'm not sure.
00:30:53.920 --> 00:30:56.079
It's not like it's despite how big the question is.
00:30:56.160 --> 00:30:56.480
Yeah.
00:30:57.200 --> 00:31:03.599
It's not like people were uh doing bespoke software handwriting every line before.
00:31:03.680 --> 00:31:11.680
We were cutting and pasting stuff from Stack Overflow for years and using previously existing things and adapting and and doing stuff with it.
00:31:11.839 --> 00:31:16.240
So it's not as so using this as a tool, I totally understand.
00:31:16.400 --> 00:31:44.720
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.
00:31:44.799 --> 00:31:48.000
You know, they're able to just work in lots of context all the time.
00:31:48.240 --> 00:32:06.720
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.
00:32:06.960 --> 00:32:07.839
What are you seeing?
00:32:08.000 --> 00:32:09.759
Are you seeing this contributing to burnout?
00:32:09.839 --> 00:32:13.599
Are you seeing this turning teams into individuals?
00:32:13.680 --> 00:32:19.359
Or I'm just curious what you're seeing from all this and if there's an example of good.
00:32:20.079 --> 00:32:22.960
Yeah, I'm trying to find that example of good.
00:32:23.200 --> 00:32:26.880
I, you know, it's funny, everybody's talking about cognitive scaffolding.
00:32:27.039 --> 00:32:34.400
I talk about metacognitive scaffolding, which is actually a really big area in psychology and learning science.
00:32:34.640 --> 00:32:36.960
I don't think we've brought it in here enough.
00:32:37.279 --> 00:32:42.720
And the reason I like metacognition, so this is kind of like you're thinking about your own thinking.
00:32:42.880 --> 00:32:52.400
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.
00:32:52.640 --> 00:32:56.720
But on top of that, you also learn strategies for thinking.
00:32:56.880 --> 00:33:00.799
And what's really exciting about metacognitive strategies is that they are malleable.
00:33:00.880 --> 00:33:04.319
Like we can actually train people towards better ones.
00:33:04.559 --> 00:33:14.400
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.
00:33:14.480 --> 00:33:28.000
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.
00:33:28.240 --> 00:33:30.240
That's a metacognitive strategy.
00:33:30.400 --> 00:33:36.079
It doesn't require you to magically have like a different memory or different, you know, whatever capacity you have, right?
00:33:36.240 --> 00:33:38.960
But it just helps you use your time better.
00:33:39.200 --> 00:33:43.279
So I'm interested in are we using developers' time very well?
00:33:43.519 --> 00:33:47.119
And I think right now we're in early days with AI.
00:33:47.279 --> 00:33:54.559
I think it's a little bit ridiculous and exhausting to be like clicking approve, approve, approve on the agent all the time.
00:33:54.799 --> 00:34:16.159
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.
00:34:16.400 --> 00:34:20.880
Where I see sophisticated teams doing this, you know, it's interesting.
00:34:21.039 --> 00:34:35.039
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.
00:34:35.119 --> 00:34:38.880
So I wrote this skill that range coding instead of identity.
00:34:39.280 --> 00:34:39.840
That's right.
00:34:40.000 --> 00:34:45.840
This is like the psychologist thing is like, I'm gonna, you know, write an intervention into a skill.
00:34:45.920 --> 00:34:48.079
Um, because I know you all won't leave Claude.
00:34:48.159 --> 00:34:49.920
So like if you'll try it here.
00:34:50.400 --> 00:34:57.599
And um what was really fun about this is that several thousand people started using it.
00:34:57.920 --> 00:35:07.039
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.
00:35:07.199 --> 00:35:18.639
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.
00:35:18.800 --> 00:35:23.920
And so you have to actually tell the agent how you think things work, and then it kind of helps you.
00:35:24.159 --> 00:35:27.440
So that is a metacognition exercise.
00:35:27.599 --> 00:35:31.039
That's like you trying to improve your mental model.
00:35:31.280 --> 00:35:35.920
I think there is just a huge design space that has not been built yet.
00:35:36.079 --> 00:35:38.400
Again, like come on in, builders.
00:35:38.639 --> 00:35:43.039
We need tools around agentic coding to help developers like learn and grow.
00:35:43.119 --> 00:35:45.440
And I I'm looking forward to that.
00:35:46.159 --> 00:35:49.920
It's interesting hearing you talk about sort of that intentional practice.
00:35:50.079 --> 00:36:16.239
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.
00:36:16.559 --> 00:36:32.480
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?
00:36:32.800 --> 00:36:34.079
Yeah, deeply.
00:36:34.239 --> 00:36:38.639
You know, you named something that is actually deeply valuable to me.
00:36:38.800 --> 00:36:43.119
I I love to study thriving, what I call thriving environments.
00:36:43.199 --> 00:36:45.199
And then I also love to study threat.
00:36:45.280 --> 00:36:48.559
Like, hey, what's happening to us when we feel very threatened?
00:36:48.800 --> 00:36:51.280
AI is very threatening for a lot of people.
00:36:51.519 --> 00:37:16.639
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.
00:37:16.880 --> 00:37:20.639
But the problem with threat doesn't mean it's not a real problem.
00:37:20.719 --> 00:37:30.960
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.
00:37:31.199 --> 00:37:44.400
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.
00:37:44.480 --> 00:37:59.519
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.
00:37:59.679 --> 00:38:01.360
Technology always changes on us.
00:38:01.440 --> 00:38:03.280
This is part of what we deal with.
00:38:03.440 --> 00:38:05.679
We actually can face it together.
00:38:05.920 --> 00:38:09.039
These are messages that lower the threat temperature.
00:38:09.199 --> 00:38:12.000
And you just have it's amazing what people will do with that.
00:38:12.079 --> 00:38:13.760
You know, they'll just take it and run.
00:38:13.920 --> 00:38:18.079
So that's kind of what I found about fear in software development.
00:38:18.800 --> 00:38:34.559
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.
00:38:34.719 --> 00:38:46.400
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.
00:38:46.639 --> 00:38:53.199
And I think that's sometimes too reductive, but I've definitely met people that fall into both of those camps.
00:38:53.440 --> 00:39:07.920
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.
00:39:08.000 --> 00:39:15.119
Is there something that we as product people can do to help move people uh further up the ladder in that?
00:39:15.679 --> 00:39:16.320
Hmm.
00:39:16.960 --> 00:39:22.800
I was just thinking for a second because this is a I'm kind of this is an interesting question.
00:39:23.039 --> 00:39:30.000
You know, when you're in a group with people, when you're trying to do something together, people have different goals, right?
00:39:30.159 --> 00:39:34.960
And the answer can't be everyone has to come over to my version of the goal.
00:39:35.039 --> 00:39:46.480
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.
00:39:46.639 --> 00:39:56.400
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?
00:39:56.559 --> 00:40:03.039
And so I have to have a model of the world that allows for that, that's big enough for that.
00:40:03.280 --> 00:40:13.360
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.
00:40:13.519 --> 00:40:18.559
And it doesn't be mean that you have to achieve this goal by like being a UX researcher.
00:40:18.639 --> 00:40:26.400
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.
00:40:26.719 --> 00:40:30.400
It just means you're collaborating with other minds in the world.
00:40:30.559 --> 00:40:32.880
And maybe some of you are doing this at home.
00:40:33.039 --> 00:40:39.039
I mean, Lord knows I chose to become a PhD researcher, so I'm not like out at every party.
00:40:39.920 --> 00:40:54.159
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.
00:40:54.320 --> 00:40:58.400
And that's that's what I try to help teams see.
00:40:58.639 --> 00:41:10.559
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.
00:41:10.719 --> 00:41:20.400
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.
00:41:20.480 --> 00:41:25.760
I shouldn't take that to mean you don't care, you know, that our users get to achieve their outcome.
00:41:25.920 --> 00:41:32.800
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.
00:41:32.960 --> 00:41:39.840
So I think the superordinate goal is necessary, but we're allowed to have like our individual goals and it might still work, right?
00:41:39.920 --> 00:41:40.480
On your team.
00:41:40.639 --> 00:41:48.800
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?
00:41:49.280 --> 00:41:54.239
Yeah, I think the the the real secret for me is it takes all kinds to make up a team.
00:41:54.320 --> 00:42:16.880
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.
00:42:17.440 --> 00:42:17.840
Yeah.
00:42:18.079 --> 00:42:20.719
I think there's many routes getting motivated about a goal.
00:42:20.800 --> 00:42:27.119
Like you can, you know, I think it's a fallacy sometimes we have in tech that everybody has to care really, really hard.
00:42:27.280 --> 00:42:33.840
I mean, caring really hard is beautiful, but it's also exhausting and is another route to burnout.
00:42:33.920 --> 00:42:40.079
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.
00:42:40.239 --> 00:42:44.239
Maybe somebody else cares about this product more deeply than I do, but I'm not against it.
00:42:44.320 --> 00:42:50.719
And I love to achieve other goals in my workplace, like showing up and mentoring juniors or something like that.
00:42:50.880 --> 00:43:01.599
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.
00:43:01.760 --> 00:43:04.079
So we have to have that perspective too.
00:43:04.480 --> 00:43:10.400
It's such an interesting discussion and uh one that I one that I love and I'm thoroughly enjoying.
00:43:10.480 --> 00:43:15.039
But um, and I've got so many things that I could talk about, the experience that I've had.
00:43:15.199 --> 00:43:26.960
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.
00:43:27.119 --> 00:43:32.559
But um, he was he was uh unwilling coding monkey.
00:43:32.719 --> 00:43:38.079
So, you know, he wanted he wanted to participate and much more broadly.
00:43:38.239 --> 00:43:41.119
Um just having a hard time with his team.
00:43:41.199 --> 00:43:43.920
So anyway, we sorted it out, it was all fine in the end.
00:43:44.000 --> 00:43:49.039
But I think when the message worked, it definitely worked, yeah.
00:43:49.280 --> 00:43:54.079
Um, I think one of the things for me with this is like giving everyone context as well.
00:43:54.239 --> 00:43:59.840
And um I used to say with my teams like everyone here is a product manager, like you have a product manager.
00:44:00.320 --> 00:44:15.519
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.
00:44:15.840 --> 00:44:23.199
Speaking of product managers so mainly our audience is is product people, product managers and product leaders.
00:44:23.519 --> 00:44:36.960
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?
00:44:37.760 --> 00:44:50.559
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.
00:44:50.880 --> 00:44:57.840
One thing is you know if you feel that there is some breakdown of communication, one of these goal breakdowns, right?
00:44:58.000 --> 00:45:10.639
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?
00:45:10.719 --> 00:45:29.679
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.
00:45:30.000 --> 00:45:34.639
Can you just like tell me a little more you know can you just like can we look into that?
00:45:34.800 --> 00:45:51.199
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.
00:45:51.440 --> 00:46:02.559
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.
00:46:02.639 --> 00:46:12.320
You know, so providing that listening ear past the first initial moment of friction is I think by itself a beautiful thing to do.
00:46:12.559 --> 00:46:20.719
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.
00:46:21.199 --> 00:46:31.599
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.
00:46:31.679 --> 00:46:51.039
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.
00:46:51.199 --> 00:46:53.920
I have seen that really happen from engineers.
00:46:54.159 --> 00:47:04.960
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.
00:47:05.440 --> 00:47:10.880
And so I think finding those like moments of connection in problem solving is really interesting.
00:47:11.760 --> 00:47:17.280
The other piece I would say is like listen it is a really changing world on technology.
00:47:17.519 --> 00:47:39.039
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?
00:47:39.199 --> 00:47:45.280
Where are your engineers perhaps packaging up specialized skills that you could really benefit from?
00:47:45.360 --> 00:47:59.119
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.
00:47:59.679 --> 00:47:59.920
Dr.
00:48:00.079 --> 00:48:02.880
Caddox this has been absolutely fantastic.
00:48:03.039 --> 00:48:09.760
So the book is the psychology of software teams we've barely scratched the surface I'm really enjoying reading it.
00:48:10.400 --> 00:48:25.440
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?
00:48:26.239 --> 00:48:44.800
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.
00:48:45.039 --> 00:49:04.880
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.
00:49:05.199 --> 00:49:27.599
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.
00:49:27.920 --> 00:49:31.920
Lou Ron Pratt is our producer and Luke Smith is our editor.