Ep. #14, Brains in Jars with Dr. Cat Hicks

Adam Zimman: We're excited to be back here for another episode of The Third Loop. And today we have a wonderful friend of the show, a guest here with us, Cat Hicks. Cat, why don't you go ahead and introduce yourself?

Dr. Cat Hicks: Yes, I'm Cat. I am a psychologist for people doing technical problem solving. And that's a lot of people these days.

And I'm so excited to be here. I've known the folks in this room for a while. We've had many big exchanges of ideas.

Quick background on me: I'm a social scientist by training. I have a PhD in quantitative experimental psychology. And I got really, really interested in software teams and how we build technology and technical systems more generally. So I started studying it, started releasing open science for this world. And one thing led to another.

I lead a research consultancy now called Catharsis that has two big arms to it. So one is helping engineering organizations develop science-backed strategies, especially in this AI era. And the second arm is continuing my love for open science. So putting out research that I hope helps teams understand what they're going through, what they're experiencing, what the core cognitive architecture of our minds are doing when we are interacting with and trying to solve problems in technology. So I'm really passionate about all of that, really interested in it, and excited to chat.

Adam: And also, let's make sure that we mention you recently published a book.

Cat: Of course. It's so new that I forget to do this. I am also the author of a book. It's called The Psychology of Software Teams. I have been reliably informed by some of my friends that it could have just been called The Psychology of Teams. But it draws from my many years of research with software teams and other technical workers. And I go through the core, big, greatest hits around what are concepts from psychology and evidence from psychology that help us thrive and learn and grow and come together and have teams that actually collaborate instead of have enormous conflict and breakdowns.

So all that good stuff, very trivial, not hard at all, small questions.

Adam: Yeah, everyone knows that anytime you're building anything, the easy part is the human aspect.

Cat: That's right. One of my friends who is also a psychologist had a blog for a long time he called The Hardest Science, because people often call psychology a soft science. And his pitch was that, come on, this is the hardest science, actually. Yeah, it's hard to understand people.

Kim Harrison: So in your book, you talk about Brains in Jars.

Cat: Yeah.

Kim: Can you tell us what that is and why it's important?

Cat: Yes, the infamous Brains in Jars imagery, which I'm delighted to say has propagated through the industry now. So we have little stickers of these brains in jars. So this image came to me because I was trying really hard to explain to some of the tech folks who hear and engage with my work, why is it that you feel so dehumanized so often inside of your workplace, inside of these environments. And I came up with this imagery because I thought about how we have this simplistic mental model that pops up sometimes when we're thinking about developers, we're thinking about people doing technical work. And it's that you are isolated.

You're nothing but your brain, your brain has no emotions, it's just pure cognition, it's pure intellect, let's get rid of all the squishy, soft, human stuff.

And that's how we should understand our technical teams, really, at the end of the day.

All of the other things are nice to have. And also, there's some features to this. If you think of a row of brains in jars in an evil scientist's laboratory, all of those brains are completely interchangeable. If you accidentally break one, it doesn't matter. You can replace it with another one. They're all the same. And so this felt appropriate to me. We have felt sometimes treated this way in our workplaces. And a large part of my book is first unpacking why.

How did we get to this place where we have such a radically simplistic view of the humans in software and tech? And then what do we do as an alternative? What can undo that simplistic mental model? So that's the Brains in Jars model. I tell people, look at it, notice if you feel like you're inside of a Brains in Jars organization or your organization is that way in the way that it's starting to talk about people doing technical work. It's a really good indicator.

Adam: It just makes me think of the scene from Young Frankenstein, goes and knocks over the "Abby Normal" brain and takes that. Anyways.

Cat: I think we need a little more camp imagery sometimes to help us process our workplace experiences.

But there's some features that you can look for in the Brains in Jars organization. And so I call out three major ones in the book. It's so interesting. Our human minds are capable of activating these mental models even when we know that really the real world's a lot more complex. We have these moments where we get these very simplistic stereotypes activated.

So I wanted to explain this to people and say, why is it that you feel like, my leader used to be an engineer? They should understand how hard and complex this is. And yet it seems like they've gotten to this place and they're saying these things in a leadership room that are so unaware of all of the human cost of what we're doing.

And one of the reasons, I think, is because our minds use these powerful heuristics to make us forget about certain parts of the complexity. So I try to describe some of those because I think that once you know about them, you can actually recognize them, unpack them, and choose an alternative.

So the beliefs that I like to unpack under the Brains in Jars organization are things like the feeling that our problem solving actually has nothing to do with each other, that it's totally isolated. This is extremely not true. In the science of how people problem solve, we take and exchange information with other people constantly, and the social coherence and coalition and being treated well by other people, all of that stuff makes you think better. It's not just, oh, it's nice. It really does impact what you think about, how much energy you have for your work and all of these things.

So I wanted to package that up in the book and share that with people to show it's not just that the Brains in Jars organization feels bad to be inside of, it also ultimately does less good work, produces worse outcomes for its customers, its users, and its employees.

James Governor: So can I jump in there a little bit? Now, Cat, I know that you're not an AI hater, but I think that some organizations are quite aspirational about being a Brains in Jars organization. And they see the agents, "agents are my brains in jars."

Cat: Yeah.

James: So how does that work in terms of your research? Because if Brains in Jars is an aspiration as opposed to a concern, am I right to be seeing the AI-pilled people as brains-in-jars lovers?

Cat: Can you describe those organizations to me a little more? Tell me, what are those organizations doing? What are the choices they're making? I can also imagine, but I just want to hear what you're thinking about.

James: I think some of it is the idea of replacement. So your description is about creativity, high-performing teams, working together to solve problems. I think Brains in Jars organizations are thinking, collaborate less with humans, more with agents. Certainly outsourcing large corpus of knowledge, not feeling that that's something you get from another human or need from another human.

Some of those sorts of dynamics where it's really about human replacement rather than augmentation.

And yeah, to those organizations, for them, it's brains in jars maxing.

Cat: Yeah. In fact, we would like to have synthetic brains in jars.

James: It's "my brains in jars spawned a bunch more brains in jars. And that was amazing."

Cat: So here's what I'm paying attention to right now. There is the split between the outcomes that the organizations taking that sort of approach are getting versus the outcomes of organizations that are keeping centered on augmentation.

So yes, I'm not an AI hater. I'm actually really interested in the power of large computational models of the mind. I always have been.

I actually did my PhD on UC San Diego campus, which is one of the places where a lot of foundational work that led to AI came from. And it came often from people who are really interested in the structures of our minds and the structures of society. So it's really interesting to me because I actually see AI as something that deeply reflects the power of our social cognition. AI is possible not because of these isolated, simplistic minds that are working completely separately. It's possible because we are a species that collects information and shares it in the way that we do.

So I actually think that the brains in jars stereotypes in software orgs hold them back from really successfully using AI and from understanding the ways that it can go wrong.

So you see all this research coming out of the lab, and the research is really messy. If you follow me online, you know I critique how well we study this or how badly we study this. But over and over again, we are seeing the people who are treating this technology as augmentation and looking for new skill building rather than total offloading. And the teams that are looking for moments of comprehension building, moments of finding the loops of mental model building, that whole area is more necessary than ever.

I actually think it is starting to be this bigger split than it's ever been before between organizations that are capable of metabolizing this. And then I've seen these clients who come into me over the last year who are saying, wow, we spent the money. We have the AI tool. We assigned it all the tickets. Why is it a mess?

And it's a mess because the human processes are not engaged in the right way and the human knowledge work that has to be created for the agentic era is not happening in the right way.

And so I think it's a mess right now. I think people are going to argue and debate over which model is going to win. But I personally have a pretty good track record of predicting this kind of thing. And I think we're seeing the early signs already that there is a new form of the knowledge work around these tools that we need. And it's going to rely on getting better at some of this collaboration, not getting worse. So you'll see things like the organizations that have these runaway AI disasters have just let people work totally in isolated patterns or have caused this breakdown in the cohesion of their organization because they have slop mountain happening over here and someone who doesn't have enough time to review it over here.

And in those big conflicts between the ways people are working, you get really big errors. Really scary errors sometimes in these systems. So, yeah, that was a little high level, but that's my pitch to you, James. We can go back and forth.

James: I've got more brains in jars material that I want to just say.

Adam: Shelves of them. Shelves of them.

James: One of the other things about the brains in jars believers and lovers is the AI pill very often think that, because there is this question, can agents think? Are agents sentient? And of course, Descartes talked about the demon.

Latterly, that was re-envisaged as brains in jars. We could be brains in jars. We might not have bodies, but the demon could just be. And in that view of the world, these agents that we're bossing around to replace humans, these brains in jars, they might have had bodies at one point and have those bodies taken away.

So the brains in jars thing is very zeitgeisty, Cat. That's all I could say.

Cat: Yeah, it is. In undergrad, I would have called myself a phenomenologist. I'm married to a neuroscientist, and we're always like, hey, we have minds, so our dog also has a mind. The animals around us have minds. The mind part is fascinating. I did not become a philosopher, so I cannot speak to consciousness.

But I think the shape of information in the world is fascinating. And I think it's very tempting to look at these AI-pilled people and think these must be the people who are really getting AI or something because they're doing all this social performance about it, right? I don't actually believe that these are the people who understand LLMs very well, necessarily. And I actually think, maybe this is my bias because I would put myself more in a moderate camp here.

But I think the deeper you try to understand how humans think, how we collaborate, where the drivers of our outcomes come from, the better you actually start to understand what makes AI work.

So it really actually is a technological advantage to understand the cognitive architecture of our minds, because that shapes how we create information, how we create data, how we see relationships in the world. And that is what LLMs are built on. So to me, there's this interesting gamble you can make right now, which I'm making, which is, I think the more I care about and understand humans, the better prepared I will be for the AI future.

Adam: Well, I think that the thing that we were talking about actually last week with Jennifer Riggins was a really interesting correlation to this, is that one of the aspects that we're noticing, I personally have seen this, but also have anecdotally heard this from other organizations that are using AI in force, are actually using it in practice on a day-to-day, is the way in which it is accelerating some of the old school challenges that we used to see with regards to organization growth.

And making those challenges appear much sooner. Where it used to be that you'd hit these challenges, maybe inflection points at 50 people or 150 people or a thousand people, but you're hitting them 10x faster with the use of AIs, like agents and tooling, because the output that you're generating and even the outcomes that you're generating, it's one of the things where you're doing it at such an increased rate of speed and change that is astounding. From personal experience, you've got a team of seven developers that's outputting at, I'd say, what I previously experienced in my career of a team of around 40 to 50.

Cat: Yeah.

Adam: And it turns out the challenges that we're having around alignment, the challenges that we're having around being able to have awareness of the system as a whole are consistent with that larger team size, even though we all still fit around a small conference table.

Cat: And I think that's an interesting opportunity. It's kind of a crisis, but it's also, my friend Danilo likes to say never waste a good crisis. It is an interesting opportunity for people who are good at those kinds of activities, who have traditionally not often been valued enough in software, I think.

And so the idea that design comes last or alignment comes last, I like to ask the teams that come to me, what are you doing with your save time? Where are you putting it? What are you doing with it? And that is a question I think that faces all of humanity, as we do knowledge work, as we save time, which we do, and where are we putting it and what is it going towards?

And I believe that there is a really interesting opportunity to level up in the kind of empiricism that we bring to software. Or if we're going to have a lot of systems where we can no longer rely on, we just understand it because we wrote it, well, then how do we understand it?

There are ways that we as humans understand systems we didn't build ourselves. And a lot of those ways have to do with experimentation and observability and building apparatus around the systems that we have, as we've done in biology and, in fact, psychology.

James: Experimentation and observability. How much do we love the language that Cat Hicks is using right now?

So one of the most interesting takes on, I think, what do we do at that time, that I've had in recent conversations is with a guy that works at Dynatrace called Alois Reitbauer. And he's got a really interesting take. So they've got a lot of engineers in Switzerland.

And his thing was, okay, so the last thing you do before you log off for the day or whatever is you set the agents to do some work. You think about the problems that need to be solved and leave them to it.

In the morning you come in and spend some time looking at what they've done, and then perhaps go through another round of here are some things that should be done. And at that point, what you should really do is just bugger off and go outside and touch grass. He's like, go have a long lunch or go for a walk. But the thing about what do you then do with time is super interesting, because their thing is you can't, legally. Because the natural thing is to go spend some time with your family and then maybe catch up again with the agents for a couple of hours in the evening. Legally, they are not allowed to work in the evening. And that to me was like, okay, what do you do with the save time? What if legally you can't have that time in the day?

And you're not allowed to send emails to your colleagues after 5, 6 p.m. So, yeah, it's literally illegal to do work then. And his point was this sort of legal restrictions don't make sense.

But yeah, what do we do with the time when the law says, actually, you can't change your working practices in order that you can... And then, of course, in America, it's just like, Great, I'm going to work 18 hours a day. I'm going to code in the shower, and I'm going to...

Adam: James, the one that I saw just this morning was, whether it's performative or not, is debatable, but the individual that was pontificating on X about how they don't need to read to their kids anymore.

James: No, don't tell me about that person.

Cat: Wait, there's too many things being brought up.

James: I saw that, Adam. But they described that as parenting.

Cat: Yeah, so many social wars being fought right now.

Kim: Can I throw something else into the mix? Everything James just said, but I want to add a question that Jennifer brought up, which was, why do you need to do more?

Cat: Okay, is that a question to me?

Adam: Sure.

Kim: In general, to this whole discussion of why do I have these limitations, why can't I let my employees work after hours? Why shouldn't we go faster? But why do you need to do more?

Cat: Okay. I just posted about this recently, which y'all might've seen on Bluesky. There are a lot of reasons we want more things done, right? I want my family to be stable and okay, which is a multi-generational journey, where I can see the compounding effects of that. This is a worldwide story.

I also want information to come to me quickly at the time when I need it. So it's not all just evil and for no reason, I think, that we want things to get done in the world. And I do think, certainly economically, we have this disconnect between workers and the productivity gains that are happening from knowledge work. And so that's this existing context. If you look at people like the economist Kathryn Edwards, who was just on Jon Stewart's podcast, she speaks really well about this kind of decoupling between the gains we're having as an economy and then whether that's flowing back to workers.

So often when I talk to people about why should I be more productive at work, why should I care about speed, that pain is at the heart of it. If you're not actually getting that reward yourself, you don't feel it.

But is there just a reason at all in the world for us as a species to want things to get done faster? I think absolutely. The examples that come to mind are very real in my life, like health. My dad has cancer. And the faster that people in his medical worlds can get their tasks done, the faster that's detected. So they're these very real outcomes that happen.

And then you've raised this point of, there are these larger policy structures we're living our lives inside of. So my employer is setting these rules against this landscape of the laws in my country. And maybe not all of these actually have caught up with how I want to work as a knowledge worker. My perspective on that, the not working in the evening, the illegal to work in the evening stuff: sometimes we do actually have to experience these constraints that aren't built around us. But maybe the way I look at policy is often, I don't know, does it help most of the working moms in this country, even though I'm not a working mom? Then great. I will work at a slightly less optimal time of day for me if the outcome of this policy is most of the mothers in this country are treated better and not held back at work because they can't do what I can do, or something like that. So as someone who used to work on policy advising and the research behind policy, I always look at that kind of stuff like it's really bigger than just us.

Adam: This is great, Cat. I think that the thing that is consistent with all the points you're bringing up is, when we're looking at all of these things and anything that creates a restrictive behavior or restriction, it's always good to consider, well, yes, but are there individuals other than us that that's actually positive for? Or does that enable a more equitable type environment for people to participate, and for a broader audience to participate in? And I think that that's awesome.

James: Sorry, did you say equitable? I'm hoping at some point we might get this podcast to be sponsored. You can't use words like that, Adam. We'll immediately get the funding cut before we get the funding. Please, come on.

Cat: Trust the pendulum swing. It's going to come back, and then this is going to be the podcast that gets the--

James: Oh, I cannot wait for the return of the DEI era. Bring it back.

Cat: Some of us never left it. I do want to speak to this, though.

I think our businesses do choose speed. They choose to talk about speed when they haven't figured a lot of stuff out. So if you perceive all of this conversation about speed and acceleration as hypocrisy or kind of shallow, you're often not wrong about that.

I think that places will make these claims, workplaces will make these claims, and they won't have actually measured it. And they won't actually have a sense of speed doing what and speed in what way. And so we're starting to see the thing that always happens, which is people in the front lines of work, people on the ground, are seeing, well, okay, yes, of course code generation has sped up, but we haven't solved the review bottlenecks and all of that. And that's been something people have been screaming for a year, but the businesses are kind of up here just going, it's fine, it's fine.

The speed up is happening. And that to me is not just about AI. That is about, again, experimentation and observability, that businesses are often getting away with having very poor practices around the evidence that they are using to understand themselves. And that's a tough thing to live inside of. And it's a really tough thing to try to change as a person who cares about that stuff inside of a workplace.

James: There was a brilliant presentation at Observability Day yesterday, which was run by Honeycomb. And it was folks from, it used to be called Intercom. It's now called Fin. Brian Scanlan and his colleague. And there were some really interesting things about measurement there. They were doing a lot of experimentation and observability to understand, basically, the implications of the models that they were using.

One thing I thought was very interesting: they still maintain that no pull request can be more than 150 lines of code, which is good standard engineering practices of the past 15 years, but some orgs seem to be jettisoning that in the AI era, because they're like, well, we'll just ship huge things that the agents built. From a quality perspective, they think they need to keep the changes small. But also, it's very interesting, things around some of the agents were too verbose in their commenting, and they're like, actually, we don't need that. And so they were using agents to cut down the amount of commenting.

Cat: Yeah.

James: So their main software agent is called Shrek. And they felt they had to personalize it because the developers increasingly, if they felt that Shrek was on their side, that is good. When Shrek was not on their side, not so good. So there were lots and lots of human factors research, but also models.

So false positives. Okay, they're all 150-line pull requests, but also there's still such a volume that they're using agents to review code because they can't do human review for everything. They were doing experimentation at the level where they would roll out a model change. They thought they could use a cheaper model to do the code review. The problem was, the cheaper model, there were more false positives. And that was slowing teams down.

Cat: That's not necessarily where I'd put my expense. And that shows the value imbalance that we have sometimes, right? Where we're just so fixated on generating the code is the real work and the real technical thinking.

James: Yeah, no, they were doing a lot of work in that regard.

Cat: Yeah, that's cool.

Adam: The interesting thing there, though, is that, because we've had this conversation internally on our team a little bit, it's not so much the distinction between the real work happening at code generation and the easy work happening at code review. It's actually more about what the models themselves are good at, in terms of the lower end models oftentimes are really good at, in fact better at, doing pattern matching or being able to do anomaly recognition, as opposed to the newer models now, something like a Fable.

It's actually not as good at that, and it will take forever. So you actually want to do some of the lower end models sometimes, because the iteration, or the ability to be able to do that quick iteration and quick response time, so that you can loop.

That's the kind of assertion that we've had. So it isn't about the value of the work. It's about, are you choosing the model that's actually optimized for the type of work?

Cat: Well, this is the part where the ground shifts under your feet constantly. So I have this talk I gave to a CTO conference and I put up a slide where I said, you're not evaluating AI plus my organization. You're evaluating model times harness, times code base, times documentation, times practices of teams, times individual developer choices, times... So we cannot keep all these interaction terms straight in our heads. It's too much.

But I think that there's some really interesting, under-exploited, low-hitting fruit right now. And I've seen this because of this learning opportunity skill that I wrote, which is explicitly designed to help developers actually build back their mental models when they have really large amounts of generated code.

So I find it very interesting that we're treating some of this as just a sheer quantity problem. I actually think there's also this whole area of engineering that we're going to have to have in the future, which is about how do I pull out the structural pieces across large amounts of code and these large technical systems. And I think we've relied on this just happening at the individual human level, but there are actually interesting things we can do.

So we know less about codebase comprehension in the research than we do about creating and writing code. And that's a really interesting gap because now we need to know a lot more about how does someone ramp up into an unfamiliar code base, into code they didn't write. What do expert reviewers of code actually look for? And they do look for things.

And what's exciting to me is there's stuff we know about how experts learn and quickly outside of software that I think you can bring in. So experts look for shared structural patterns. They also look for where those patterns break down and edge cases and outliers. And when I wrote this learning opportunities skill, which takes a pass back at the files you pointed at and creates a 10 or 15 minute place where it quizzes you about the structure of the code that's been generated and teams started using it, they started telling me, I thought there was no way I was going to be able to understand this mountain of things. But even just with this little bit of practice, 15 minutes at the end of my 45 minutes of AI work, I started to get the entry points and the structural pieces. And I think about things like when we discovered certain laws in biology, like we discovered the mechanism of evolution. There's so much that we don't know in biology. There's so much complexity.

And yet, if you know about evolution, if you know that there's this mechanism always working, it gives you this pattern to look for and this set of physics, basically, that you can use to predict what's going to happen. And I hope this doesn't sound crazy, but I think that we need to identify those types of understanding for software as we build more and more complex systems, and we just haven't quite gotten there yet.

Adam: I completely agree. I think the interesting part that came up recently in a conversation I was having was I was talking with a senior developer, and he was saying it used to be that when you joined an organization or started working on a new code base, there was a backlog of paper cut type work that you could immediately jump in and start helping out with, and that would give you the ability to ramp up on the code base.

And now, if you're working in an organization that is aggressively using AI, that list probably doesn't exist anymore. Because it's the first list that people throw agents at.

And I think that his point was it was really interesting to try and figure out what is the new way to be able to come up to speed.

Cat: I think that's fascinating. And there we see the split.

If you're taking a Brains in Jars approach to AI, you don't care about the person, you don't care about how the juniors ramp up. You're just like, figure it out or have your robot figure it out. And you miss the fact that in those quote unquote trivial tasks, there was actually vital information being learned, right? About the org, about the practices, about the social context. Probably if you've ever worked on a project where you've had the chance to talk to someone who's been there for a long time, they'll make the throwaway comment that helps you understand, oh, we think this way and not that way, or there's this history here. And one of my favorite data sets I ever touched was this big data set of comments back and forth on pull requests.

And in particular, we pulled out, when I was in the Dev Success Lab, the lab I used to run at Pluralsight, we pulled out all of the emojis that were used. And it was so lovely. So you could literally trace, without knowing the content, you could trace the meaning of the conversation through emojis. Because there'd be junior developer, little prayer hands.

Adam: Right, right, right.

Cat: Here's my first pull request. And then there would be senior developer reviewing it, strong arm emoji, like, we've got this. There'd be hug emojis.

It was genuinely so sweet and lovely. And I think about that.

We have to have places where we exchange those things. We have to have places where we are able to do that. And so I don't think AI will succeed in orgs if everyone's in a box alone, but I do see glimmers of something different. I have some folks who wrote an email to me who said, we're now using your learning opportunities skill. And as our agents are running, me and my friend are getting together and we're quizzing each other, and this is our new paired programming.

Adam: That's cool.

Cat: And it's not with the same goals. We know we don't have to write that much code, but we're doing comprehension reviews instead of code reviews. And I thought that was just so cool, and I'm trying to bring that into my own practice. So the possibility is there, I think.

Adam: One of the things that we used to refer to this as, or I've talked about this in the past, is cultural equity.

Cat: Yeah.

Adam: You think about financial equity that you gain as you have tenure at an organization. This idea of cultural equity, where the longer you're at an organization or work in a team, you have this knowledge set that is almost non-transferable. And I think that that's something that, to your point, it's becoming a lot harder to build that if you're further removed or isolated in a jar.

James: This ties into, I was actually going to ask Cat about this. So in the book, we talk a fair bit about psychological safety and how important that is as an underpinning in a culture which can be aligned and which can take advantage of automation and which can do the work.

I'm interested in the changing nature, perhaps, of psychological safety in this current era.

Cat: Yeah.

James: This conversation we've just had.

So Richard Sworder, who runs a product at the Atlassian-Williams engineering team, he spoke to me and made the point that he's gone from sketching cars, doing aerodynamics, through to latterly automating things to the extent that he's running their Kubernetes platform and knows how that works and the Helm charts and all the YAML and has all of that. And then he knows every piece of the engineering org from top to bottom.

And so when he's using agents, because he knows it all, he's feeling very productive. He is psychologically safe in a sense, and I realize psychological safety has a specific meaning, this being able to make mistakes.

But he was really concerned about burnout amongst his junior team members, or even just other team members that were not quite as AI-pilled, perhaps didn't understand the overall system and how it fitted together, and were therefore more likely... I mean, how wonderful he is that he's aware that they were likely to burn out because they lacked context.

Cat: I think you're right to be concerned. I wish I could say differently, but before AI was accepted in software, I released this project, and it was the very first open science project I ever released in public on the internet. I posted it on Twitter, right? That's how long ago it was.

And it was about this thing I called learning debt. And it was about the fact that we're not providing enough time for knowledge workers to learn and we're treating them like they are static. And that does not reflect the actual reality of what you need to do to do technology work, to handle change.

That's not what you see. The societies and the groups of people who are most successfully able to metabolize complex technology, they allow for teaching and learning exchange. They allow for skill building. That is the mechanism. If you want to talk about, I mentioned the mechanism of evolution, the mechanism of human societies being able to develop better and better technology is social learning, is teaching and learning.

This is widely accepted by all of psychology and just not heard in software at all.

And so I worry about that. I do, actually. And I think that one of the measures that I measure with clients, with end orgs, that's really useful is this thing I named overproduction pressure.

And you can ask people, do you see long-term and short-term goals? So long-term goals, like this is going to be good for our code base. This is going to be the necessary thing we have to do. And short-term goals, get it done now, get it done today, get good enough, etc. Valid reasons to have both.

But if the balance is off, if you are always, always, always subjecting your technical people to this feeling that all they can ever do is work on the short-term goals, you get this dynamic I call overproduction pressure. And you actually just waste horrific amounts of time because you get churn, you get short-term thinking. And so I actually have a measure of this.

And when I run it, I've tested it across quite a handful of people now, which is so fun. And it connects to all of these other outcomes that we care about. So people who say, yes, I'm feeling this overproduction pressure, they feel much more AI skill threat.

They feel paralyzed when they think about AI. They feel disconnected from software communities. They feel like, I'm not sure if I belong anymore. They feel all of these negative consequences.

And when you feel those psychological things, that psychological threat, it comes in, it destroys your sense of psych safety. And it just costs a huge amount of cognitive energy from you. So you are pouring gasoline into your end org and lighting it on fire if you don't care about these factors.

Adam: Everything's fine.

Cat: So I hope that wasn't just totally doom and gloom because I see a very different possibility, which is, if you can build back and cultivate this respect and love for the skill building and the expertise building, you will actually see the benefits in the output and the outcomes and the productivity. That's the way our minds work. But I'm worried about the burnout cycles.

And I think that if you don't make that cost visible to leaders, to orgs, they will get away with it for quite a while. And then they will wonder, I wonder why our product failed. I wonder why our business can't... What a big mystery, what a strange mystery that we treat all of our technical people like total garbage. And somehow our product is now garbage.

I like making that stuff visible, though. It's really fun to run those measures inside of an org and put it on a chart and say, look at this. Look at this data. And a lot of people believe it when you can do that.

Adam: Absolutely. Well, thank you so much, Cat. And I think Kim has a final question for you.

Cat: Yeah, thank you for having me.

Kim: Yes. Who else should we be talking to?

Cat: Oh, I think it'd be interesting if you talk to some teachers, talk to some people who are teaching programming in the era of AI and really grappling with it and really trying to construct because that is an interesting place right now. And I think you'll see little glimmers of the future when you talk to people who are actually dealing with the computer science majors and programming across all fields.