What helps an identity crisis?

This piece is something special and different on Fight for the Human. And honestly, as a fan of collaborative thinking, distributed cognition, and the notion that innovation is most likely sparked in the interactions between people, I can’t believe I haven’t done this before: a back-and-forth with Charity Majors of Honeycomb and Observability fame! 

As described in her first post in the series, the two of us kept finding each other in the same “backstage,” talking and thinking about software experiences. In this series we’re bringing that conversation into the light, and pointing at some of the themes we’ve both been uncovering.  

Talking to Charity about this, one of the major themes that surfaced for me was this feeling that despite our deeply domains, there are so many experiences of fear and uncertainty in software environments right now. As she writes, “There’s a vast sense of unsettledness and insecurity in our industry.” This is undeniably tough. 

Yet I believe that how we respond to uncertainty has some predictable logic to it, particularly in how it shapes how we think about our teams, our orgs, and our choices at work. In her first piece, Charity draws our attention to norms and ethics; I am going to follow up on this by spending time on how I think about norms as the shared group belief systems that are shaping how we appraise the situations in our workplaces and the actions of others. 

It’s been my bet for a long time that understanding these pieces of our psychology can help us become intentional about designing for healthier, happier software environments. When I think about what’s most useful for teams to know now, I think about the foundational psychological dynamics that increase threat. 

Threat has teeth, psychologically-speaking. It dampens our problem-solving, erodes trust, and makes it hard for us to find real collaboration. But when we understand it we can defang it. I'd like to tackle some foundational concepts I use to diagnose how threat is impacting teams right now. These concepts shape the practical triage I use when teams come to me for a consult about their culture and practices: what are the dynamics shaping this place? What messages are people taking about whether they belong, and what makes them safe on a given team? What messages are people taking about what drives success in this place? 

You can think of these questions as how we try to determine the psychological physics of our problem space. Under threat, we’re asking these questions constantly, and the answers feel both high-stakes and uncertain. This drains cognitive resources and attention. I believe this increased vigilance and uncertainty is one of the reasons we all feel as tired as we do. Psychological threat directly drains your cognitive resources, just as tangibly and measurably as solving math problems all day.

Identity Threat: what is it?

The agreement that software development is having an identity crisis is everywhere right now. Many people have written and thought about it. For example, over a year ago now Annie Vella wrote a piece called "The Software Engineering Identity Crisis." When I read it, I wasn’t surprised it resonated because it’s an articulation of something many people in tech are feeling: fear of loss of craft, debates about whether developers are becoming managers of machines instead of builders, and the grief of watching things we loved about our work change. It’s come up in multiple of the interviews I’ve been doing around my learning-opportunities skill too. 

In all this, I recognize a specific thing that we have both a name for and years of research on in psychology: identity threat. What we know about this state and experience mostly comes from social identity threat theory. This well-studied theory tells us that our minds get catapulted into a different, vigilant threat state when something in our environment signals that a group we belong to is being devalued, displaced, or redefined in ways that undermine our sense of who we are. 

Recently, Kroeper and collaborators contributed an excellent measurement project on this, looking at a Social Identity Threat inventory with an impressive nine studies and 8533 participants (you can access the text here if you want a full read). In their words: social identity threat is a vigilance state in which a person anticipates that others in a setting may devalue them because of one (or more) of their social identities. This threat can be situational and contextual, shifting with how we are appraising other people's changing beliefs about us (and our attributes). As Kroeper et al. write, Threats emerge from the social
meanings attributed to specific identities situated within specific
contexts.

You might be wondering about the social part. Most psychologists study this phenomena (understandably) about social identities that are very salient to us, like how our societies see gender or race. But there are many identities we carry around with us. For knowledge workers how we see ourselves professionally, and as members of a certain skill group, is a significant source of identity. So when that changes….we can also experience identity threat. 

I don’t think it’s a mystery why we’re hearing so many stories that seem to center on identity crisis right now: you aren’t a good developer if you x, our teams are at war, everyone is an idiot but me. Us-vs-them stories are the type of explanations our minds like to reach for under threat.  

Here’s how I wrote about it in my book: 

I’ve studied whether rigid, narrow identity beliefs about being a software developer are associated with more threat during AI. The answer is yes. 

I ran an empirical study directly looking for signals to predict what helps developers manage skill and role-based identity threat as they grapple with AI making changes to how work gets done in software. In 2024, a bit ahead of this lexicon exploding across tech, my co-authors Carol Lee and Kristen Foster-Marks and I predicted that identity threat would emerge in the context of increasingly-generative AI. We published The New Developer, an empirical study across 3,000+ software engineers and developers in 12+ industries, studying how identity beliefs link directly to increased anxiety and threat (note, you can also use our open access measures from the study in your own team, org, or just as personal reflection – they're linked as supplemental materials and open access under CC BY-SA 4.0).

Grounded in the theoretical frameworks and empirical evidence from how our minds work when they grapple with threat, we introduced a construct we called AI Skill Threat, a measure that we adapted from existing threat inventories to quickly get a measure for developers' fear, anxiety, and worry that their current skills will become obsolete as they imagine AI tools being used in software.

This evidence and the many applied followups I've led has been a cornerstone of my evidence design work with orgs for the last few years, so I’ve written and spoken about this study a fair number of times. But if you’re not familiar with it, in short, the high level takeaway is that we see a startlingly higher amount of threat reported by people who also believe that software development problem-solving is only available to a few, is based on innate attributes (rather than learnable), and is likely to be something that people around you are ruthlessly testing you on, attempting to identify whether you do not truly belong. When this happens pervasively we call it a Contest Culture. 

Right there, we have a roadmap for a few group norms that we need to target if we want to lower the identity threat temperature for our teams:

• Are we making every argument a “test” about who is a “good technical thinker”?
• Are we attempting to measure and reward “technical skill” directly, or are we getting stuck on niche experience with past proxies that might not match new technology?
• Are we steered by person-focused justifications (well they’re a senior developer so no one is allowed to tell them what they’re pushing is just a slop mountain for others to shovel!) instead of process-focused analyses that promote fairness (no matter who you are, we expect your work to hit these criteria that allow people to collaborate well with you)?
  
  All signs of a Contest Culture. 

When shared by enough people, and reinforced across the messages in how an organization and its internal authorities act, these expectations become norms. Norms tell us what a group wants from us, and how they expect us to think and act. Left undefined, norms that accidentally cement identity threat can make it a hell of a lot harder for people to productively figure out a path forward when ways of working are changing. 

A personal identity story 

It’s not just theory, data, and empiricism for me. I also study this stuff because I’ve lived it. 

I taught myself to code in order to do applied computational work on the scale of thousands of learners, students and (eventually) developers. It is a form of problem-solving that I love, but for me, learning to code was never separate from survival and social identity threat, because I learned to code while working under the enormous threat of needing to keep my career going and needing to prove, constantly, that I could belong in tech. 

Code was a route to safety, a proof of skill. For me, what it meant to be a person who can code was an identity that wasn’t just about the triumph of problem-solving (although it was that). It was also a critical key that turned a lock, the attribute I needed to have in order to think other people would let me belong in my professional area. And so on and so forth, I formed an identity (I am a statistics coder now!), with real joys and real triumphs, and yet that identity was also tangled up with judgments about what investing in it might give me (safety! Credibility! Belonging!). 

That gives me a history that helps me feel a lot of compassion for both sides of this story. For me how I learned to code, and under what duress, tells a story about who I am. I question how to use AI and how to maintain my skills. I feel disoriented by how much change it’s brought to tech. 

But I know that my problem-solving is also a lot deeper than the specific path that brought me here. And I know that there are old threats, and old pains, that even after all this time can lead me to feel a lot of fear about how my skill is seen by others. One of the reasons I spend time on experiments like /learning-opportunities is because I want to prove to myself and others that an optimistic future for human learning is possible even inside of increasingly complex technology.

But what happens when the second part of the bargain you thought you were making (this one activity gives me my identity, and my identity means I'll be safe) shifts underneath your feet? Here the cracks start to show. You can value those first parts, the problem-solving you love, without much psychological risk. But experiencing constant and ongoing threat can lead us to justify a lot of bad psychological beliefs about others. Into the gap of uncertainty that threat creates, flood more dangerously alienating beliefs about getting safety not because we think we belong, but because we think other people don’t. This cycle, ratcheting tighter and tighter when we don’t defuse our experience of threat, keeps contest cultures alive.

Rather than giving people healthy, resilient self-concepts, contest cultures are on the hunt, constantly, to detect who might not have “it,” some mystical quality of innate brilliance. You belong as long as you don't lose (this, psychologists call "belonging uncertainty," and it feels absolutely terrible). I’ve seen a lot of Contest culture dynamics get supercharged in the adoption of AI, perhaps as a protective response when we’re debating what technical thinking really is, and feeling increasingly out of control of that definition. Paradoxically I think doubling down on Contest Culture norms makes us much, much worse at actually facing the real problems that AI adoption brings because those norms set us up to devalue learning and value just having the answer. Bad norms create a slippery slope into the poor metacognition that derails teams.

Nowhere am I saying that fighting for personal mastery, rigorous skill, and taking joy in problem-solving is not good. The problem is tangling that up with norms about “being technical enough” means we're doing identity warfare, not collaborative problem-solving. This is a dangerous, narrow way to see human work. It clouds our analysis of change. I see it drag teams into constant conflict. It makes our technical identities brittle, and easy to threaten, to always tie them to surface-level demonstrations (well….I belong because I can use this tool! This language! I'm at this one company! These are the only things that make me worthy!). Those are proxies and conventions and tools, not skill and thinking itself. 

The lens of social identity threat constantly helps me feel like I am waving around a diagnostic wand that’s lighting up in almost every interview and conversation I’m having in tech. Many developers built a professional identity that was affirmed by being the person who writes the code. That identity gave them status, distinctiveness, and belonging, and while we all agreed about our norms around what software creation was and what it should look like, it also gave them categorization certainty. 

When change takes away a part of that certainty, that’s not just a change to your role. Your mind takes this in as a threat to the social identity that you use to organize your professional self-concept. 

What helps? 

But the story does not stop there. 

We can defang threat, and reform our identities on a stronger, more resilient basis. In fact, we have a tremendous psychological capacity to do so. One of the reasons I measure learning cultures, again and again in my research, is not just because of a direct interest in learning (although I find learning fascinating). It’s because a culture that has a strong norm around encouraging learning activities sends a direct counter-message to threat.

We found this in our AI Skill Threat study: developers with strong expectations that software would give them learning norms reported significantly less threat. I suspect (based on a ton of empirical evidence about this) that the core mechanism here is that learning norms give us a re-activation of the parts of our beliefs that counteract a lot of the things identity threat is throwing at us. It draws our attention to change over time, to the values that we have in technical communities around believing that good work can come from anywhere. It starts to puncture those simplistic stereotypes about success, because it reminds you to think about process more than person. It makes the idea that we can actually successfully deal with change and remain ourselves more cognitive accessible, a hypothesis that we can test. 

Charity, to me these mechanisms around learning norms are a big part of what you’re modeling when you wrote: start by listening! Making space for those discussion moments, and even your first framing question (“tell me what AI-related thing annoyed you lately”) provokes curiosity, putting our heads together, and believing that we could actually find a path through.

Because of these despair-busting properties of learning norms, paying attention to shared values of really-in-the-process learning and gathering up examples of it is my first step too. Shared learning is the first norm I usually try to spot and cultivate in a technical workplace, even one that’s really fighting about AI, not tackling enormous philosophical AI conflicts head-on. Drawing our attention to superordinate goals and values (the things that unite us, even across disagreements), that we might be forgetting about, is a critical part of how groups reform their norms.  

I’ve seen even highly acrimonious teams start to soften the moment they allow themselves to ask: what did you learn last week? What did we learn together? Is there some way to approach this tough time with a focus on learning? Do we have any shared goals for what that learning will accomplish?

But speaking frankly, we also know it’s hard to get those teams to open up, and get our companies to see the merit in this kind of practice. I often hear teams assume that learning practices will just take care of themselves, or (truly one of my pet peeves….) misunderstand that what I’m talking about is all soft, squishy feelings instead of the hard cognitive science of our problem-solving. 

Charity, this is where I want to send this one over to you for the next piece of the puzzle. What gets us so stuck on believing we can't have both high performance and good norms? What are some misconceptions you see people (leaders, teams, software cultures...?!) carry here? 

Follow along for Charity’s response at: https://charity.wtf/ !