The technical identity is the evaluation
Engineering organizations cultivate identity markers no one calls identity. The in-group/out-group filter runs on them anyway
The senior engineer is making a case in the architecture review. The argument is sound: the proposed service boundary will produce coupling that the team will pay for in six months. The data is on her side. Two minutes in, she can see the room has stopped processing what she’s saying. The engineers who came up through the same staff-level cohort as the proposal’s author are listening politely and waiting for her to finish. The decision was made before the meeting started.
This is not a communication problem.
It is a social identity problem, operating in the specific form that engineering organizations have been quietly cultivating for years. The argument’s content was filtered through an evaluation system that runs on group membership and reads technical content through it, and the architecture of that filtering is what social identity theory was built to describe.
I want to take this theory seriously, because engineering leaders are operating it at scale without seeing it, and the cost shows up as exactly the kind of friction that gets diagnosed as a “people problem” when it’s a predictable output of the identity infrastructure the organization is running.
What the theory says
Henri Tajfel and John Turner published the foundational social identity theory paper in 1979, building on a decade of experimental work on intergroup behavior. The core claim is simple and well-supported across forty-five years of replication. People derive a meaningful portion of their self-concept from the groups they identify with. They distinguish themselves from members of other groups along dimensions that flatter the in-group. They allocate cognitive and affective resources differently to in-group versus out-group members, including but not limited to: trust, attention, charitable interpretation of ambiguous behavior, willingness to update beliefs in response to information.
Blake Ashforth and Fred Mael applied the theory to organizations in 1989 in their Academy of Management Review paper, which is now one of the most-cited pieces in the management literature. Their argument: organizational identification is social identification operating on workplace categories, not a separate category of psychological attachment with its own special rules. When an engineer says “I’m a backend engineer at this company,” the words “backend” and “this company” are doing the same psychological work that nationality or religion does in other contexts. They are markers that produce in-group/out-group dynamics with measurable effects on cognition and behavior.
A 2026 paper on software organizations extended the theory specifically to engineering teams, documenting how affinity bias and stereotypical role expectations distort technical decision-making in ways that disproportionately affect engineers from underrepresented groups. The paper is worth reading on its own merits. The part I want to extend is what social identity theory predicts about the engineering identities that aren’t usually treated as identity at all.
The technical identities engineering organizations run
Most discussions of identity in tech focus on demographic categories: gender, race, age, neurodivergence. These are real, they matter, and they produce measurable effects. They are also not the only identities operating in your engineering organization, and in some ways they are not the most active ones.
Engineering organizations produce a thick layer of technical identity markers that the theory predicts will operate exactly the same way as demographic identities, with the same evaluative consequences. The list includes: your primary programming language tribe (the Rust people, the Go people, the Python people, the people who still actively write Java); your stack identity (frontend, backend, platform, infrastructure, ML, data); your seniority caste (the staff engineers, the senior engineers, the L4s); your tooling tribe (vim, emacs, IDE, the people who use cursor versus the people who don’t); your AI faction (the early adopters, the resistors, the cautious users, the people who think the whole thing is overblown).
None of these are formal categories. All of them produce in-group/out-group effects that the theory describes. When the architecture review devolves into a Rust-versus-Go argument that has no relationship to the actual problem being solved, you are watching technical identity do its work. When the platform team’s proposal gets accepted with less scrutiny than the application team’s proposal would have received, technical identity is doing its work. When the engineer who came up through the same hiring cohort as the staff engineer making the decision gets the project assignment that should have gone to the more experienced person on the other team, technical identity is doing its work.
This isn’t bias in the sense of conscious preference. What you’re watching is the predictable output of an identity architecture that engineering leaders built without recognizing they were building it, and that runs every day as part of the normal operation of the organization.
The AI faction is the live one
The technical identity category that is doing the most work in engineering organizations right now is the AI faction split, and the theory predicts exactly what we are seeing.
When social identity theory operates on a salient new category, three things happen. The category becomes evaluatively loaded. Members of the in-group are evaluated more favorably than members of the out-group on dimensions that have nothing to do with the original category. And the boundary itself becomes contested in ways that intensify the dynamics on both sides.
The AI faction split is doing all three. Engineers who use Copilot, Cursor, or Claude heavily are now operating as one identity group. Engineers who don’t are operating as another. Each group is evaluating the other’s technical judgment with the in-group/out-group filter the theory predicts. The pro-AI engineers experience the cautious engineers as resistant to obvious productivity gains. The cautious engineers experience the heavy-AI users as having traded comprehension for output. Both sides are processing the same shipped code through different evaluative lenses, and the disagreements that look like technical debates are largely identity-based.
This connects to a dynamic I’ve written about in the more AI output you review, the less you can judge it: the cognitive challenge of evaluating AI work is real and it interacts with the identity architecture in a way that makes the disagreements harder to resolve. The pro-AI engineer’s experience of “this code is good” is partly an in-group judgment shaped by their adoption history. The cautious engineer’s experience of “this code is shallow” is partly an out-group judgment shaped by theirs. Neither read is purely about the code.
Engineering leaders who are trying to manage the AI rollout as a tooling decision are missing what’s happening one layer down. The tooling decision is also producing an identity restructuring of the engineering organization, and the restructuring is doing more to determine which engineers get heard, get promoted, and get attrited than the tool itself.
What social identity does to technical evaluation
The harder problem, once you can see the architecture, is that social identity theory predicts the evaluative consequences will operate in places engineering organizations explicitly try to keep evaluative: design reviews, RFCs, calibration meetings, postmortems.
In a design review, the engineer whose technical identity matches the senior engineers in the room gets less scrutiny applied to their proposal than the engineer whose identity doesn’t match. Nobody is intending to do this; the in-group judgment of “this proposal makes sense” runs automatically and below the threshold of conscious deliberation, and the out-group judgment of “I have questions about this” runs the same way. The engineer with the matching identity has their reasoning treated as transparent. The engineer without it has their reasoning treated as needing defense.
In an RFC, the same dynamic shows up in comment volume and substance. RFCs from in-group authors receive comments that are mostly substantive engagement, framed as collaborative. RFCs from out-group authors receive comments that are higher-volume, often more nitpicky, and framed as critical evaluation. The aggregate effect on time-to-acceptance is large enough that engineers who have been at this for a while have learned not to write RFCs in their own voice if they want them adopted quickly.
I wrote about a related mechanism in the likability tax piece: the same behavior gets read differently depending on who performs it. That piece focused on gendered evaluation, but the underlying mechanism is the broader one that social identity theory describes. The likability tax is what gender-based identity filtering looks like. The other technical identity filters do the same work in less-named ways.
In calibration meetings, the cumulative effect of in-group identity filtering across many evaluative events becomes a performance distribution. The engineers whose identity matches the seniors’ produce work that those seniors interpret as strong. The engineers whose identity doesn’t match produce work that gets interpreted as adequate at best. Both groups may be producing equivalent work. The interpretation is doing the differentiation, and the interpretation runs on identity.
Why the standard interventions fail
Most engineering organizations that recognize this problem reach for two interventions. Both fail predictably, and the theory tells you why.
The first intervention is awareness training. Tell people about their biases, train them to recognize in-group/out-group dynamics, and trust that the awareness will change their behavior. The forty-five years of research on social identity is unambiguous on this: awareness does not reliably change the underlying processing. The in-group/out-group filter runs automatically, below the threshold of deliberation, and asking the person operating it to consciously override it asks the weakest signal in the cognitive system to overcome the strongest. People come back from the training, encounter their next ambiguous evaluation event, and process it the same way they always did.
The second intervention is diverse team composition. Put more out-group members in the room, and let the dynamics balance themselves out. The theory predicts what happens here too: minority in-group members in a majority out-group room don’t produce balanced evaluation. They produce stronger in-group identification among the majority and intensified out-group treatment of the minority. Tokenism is not just a diversity problem; it’s an identity-amplification dynamic that social identity theory predicted forty years before tech HR departments discovered it.
The interventions that work are structural. They make the evaluation legible without requiring anyone to override their automatic processing.
Structural interventions that match the theory
The interventions social identity theory predicts will work are the ones that change what the evaluative process is exposed to, not the ones that ask the evaluator to think differently.
Anonymized or de-identified review. The most direct intervention is removing the identity markers from the evaluation event entirely. If the RFC’s author isn’t visible until after the technical evaluation, the in-group/out-group filter has nothing to attach to. Some organizations have experimented with this in code review and design review with measurable effects on the substance and tone of feedback. It is the closest thing the theory has to a clean structural fix.
Explicit rubric pre-commitment. If the criteria for evaluating a proposal are documented before the proposal is seen, the evaluator’s identity-based response to the proposal has less surface area to operate on. They are reading the proposal against a checklist they committed to in advance, not against a felt sense that runs through their identity architecture.
Decision documentation with dissent. The structural fix I’ve described in the likability tax piece applies here too: requiring documentation of what was decided, what alternatives were considered, what dissent was raised, and who raised it, makes the identity-based filtering visible as patterns over time. The single decision is opaque. The aggregate of fifty decisions, with names attached, is diagnostic.
Cross-team review rotation. The in-group/out-group dynamics intensify when the evaluator and the evaluatee share the same team identity continuously. Rotating reviewers across team boundaries weakens the in-group identification of any single review, because the reviewer’s identity is being repeatedly recomposed by exposure to different team contexts.
Structured calibration with content review. Calibration meetings that rely on managers’ narrative descriptions of their reports’ performance are running social identity theory at maximum operating volume. Structured calibration that anchors on specific decisions, specific artifacts, and specific outcomes, with the reviewer required to point to evidence, weakens the identity filter’s hold on the conversation.
None of these interventions ask anyone to be less biased. They make the evaluation harder for identity-based processing to capture. That is the move the theory predicts will work, and the literature consistently bears it out.
What this means for engineering leaders
If you run an engineering organization, you are running social identity theory whether you recognize it or not. The technical identities your organization produces (language tribes, stack tribes, seniority castes, AI factions) are operating as evaluative filters on every technical decision your team makes. The friction this produces gets diagnosed as a communication problem, but it is the predictable output of the identity architecture you have built, and asking the engineers caught in it to communicate better is asking them to do work that the architecture itself is making harder.
The structural interventions are the ones that work. They make evaluation legible. They reduce the identity-based processing surface area. They produce data that lets you see the patterns the in-group/out-group dynamics are creating in your organization. They do not require anyone in your engineering organization to be less human.
Forty-five years of social identity theory tells you that the in-group/out-group filter is not going away. The question is whether your organization is going to keep running it as ambient infrastructure that filters technical judgment in ways nobody can see, or whether you are going to build the structural alternatives that let your engineers’ technical content survive the trip through the identity architecture they are operating in.
The senior engineer in the architecture review wasn’t dealing with a communication problem. She was dealing with social identity theory running in real time. Whether she gets heard the next time depends on what you build between now and then.