If you're catching up to Fight for the Human I'm doing a special series: a running public conversations with Charity Majors where we discuss learning, AI Skill Threat, our shared norms and values, and how to thrive in the AI era.

Part 1 tackled: Where do AI norms and values come from? Where should people start?, by Charity.

Part 2 tackled: How social identity is constructed, and how to defang the threat of identity loss, by yours truly.

Part 3 tackled: If your team is happy, are you doing a good job? by Charity

Part 3 ended with this question: Cat, when you measure fairness, are you looking at people or systems? What do you actually look at?

Just a tiny, easy, basic little topic and definitely not a lifelong and multigenerational societal challenge for us to think about with our workplaces as knowledge workers 😂 but let's do it. Welcome to the jungle Part 4!

But first, a one act play

Scene: you, starting your workday.

If you’re like me you have a warm mug of coffee in hand to fortify yourself against the information reorientation and submergence that’s about to happen as you re-login to your corporate 24/7 messaging system, your email, your ticketing system, your review queue, your developer workspaces, and whatever other caves of human communication you need to spelunk through in order to make decisions about your tasks.

Behold: a notification! Before you even parse the full details with your executive functions, your complex social cognition has recognized the context and is already sending a signal straight to the pit of your stomach.

Coffee curdles against the back of your molars. It’s a review request from a name you recognize, and it’s here to wreck your day.

You brace yourself for a task you’re already anticipating, because it’s happened before and they said it wouldn’t happen again and you knew it would and now it is: you have to clean up someone else’s work. You will experience this as unfair, burdensome, one-sided, high pressure, unappreciated. You grind your teeth. You click into the notification and see that you’ve been assigned to review someone else’s messy, uninterpretable, larger-than-human set of changes, decisions, and output.

You will do this with very little sense of what good means anymore. You will worry about what else you could be doing with your time. You wonder how they are enjoying their day while obliviously sabotaging yours. And inside of your head, you grimly tally a new point against the culture around you. The answer to the question will I be treated fairly here has been psychologically ventured and at least for now, answered negatively.

Slop Mountain looms.

Slop Mountain

If you can indulge a bit of understatement, there’s a lot of anger about unclear expectations in software right now. There’s so much I decided I needed to open with this vignette (sorry to everyone for whom this was too real).

“Slop Mountain” is a phrase that to me, really captures that sense of imbalance and overwhelm. Slop Mountain describes the cynical side of how we’re experiencing AI in software. For all its promise, generated code needs to be judged by more than just raw quantities. When some are allowed to generate huge mountains of changes that others have to spend time shoveling, disciplining, and checking, teams see bad outcomes and trust breakdowns.

But I want to point out it’s not actually just about the big PRs. This is why when people tell me about a Slop Mountain experience, I ask: “what did you do next? What did your organization do? What’s your expectation about what will happen?”

Because it’s about what comes after you get a big, overwhelming, potentially unreviewable PR with the stressful request to “just check this.” If a mistake gets checked, and your effort gets rewarded, you encode that. If not…you encode the idea that the organization is unbalanced. That you’re being given an unfair task, and that the organization around you won’t recognize that unfairness.

That belief undermines the critical equation our minds use to stay motivated when doing difficult work, the expectation that the value of our work is high enough to make the effort of a task worth overcoming, and that the cost isn’t too high.

Organizational Unfairness happens when imbalance graduates into the belief that we can't trust this place.

I chose Slop Mountain as an opening example because it’s a salient one right now. But I’d also like us to try to think bigger than accusing the last colleague we interacted with.

In your recent piece, Charity, you talked about how we need to mature our understanding of psychological safety. I think noticing the features that create or erode organizational fairness is a way to do that. As you wrote, we are also going to try hard to shift our attention to structural drivers:

“we’re wired to see people where there really are systems.”

Second hill I’ll die on with this: not every moment of organizational unfairness is happening because some people are just better than others, or care more than others, or are smarter. As individuals at work, we have different, shifting, and complex goals, we are paying attention to different effects, and we make a lot of inferences about what other people mean.

These differences empower distributed problem-solving in good cultures, but they can accelerate breakdowns of trust in tough moments.

Given evidence for this, people start to believe their organizations are less fair when they see unclear expectation and bad explanations for actions taken, not just explicit and clear wrongs. The information asymmetry that poor psychological safety creates makes this worse. Decisions that can seem good and rational to one of our colleagues can result in too much burden for another.

Melting Brains

Here's an unfairness experience on the AI user side. One developer (experience paraphrased and shared with permission) emailed me to tell me about how they were using their company’s AI tooling and my /learning-opportunities skill to understand long-languishing problems in a legacy codebase. They felt deeply excited when they uncovered an example of a pattern that they’d struggled to understand, something that also explained a previous blocker they’d gotten stuck in on another project.

This developer went into a meeting with a senior colleague excited to share. But the moment they mentioned using AI, the colleague spent thirty minutes doing a one-sided monologue, berating them about skill erosion and “cognitive offloading.” At least in the developer’s perception, this was shared with little acknowledgement that the person they were speaking to had a boss, a team and a company that were all telling them they’d better figure out how to use AI.

This is a terrible sociocognitive message to get in the workplace, from a colleague with power who could have made the choice to try to find a shared point of view instead. The bombarded developer told me (with their permission for anonymity, I've put this in my own words): “I felt sure that my coworker was thinking I was stupid. I wondered what they were assuming about what I was doing. I started to feel scared they'd tell my boss I wasn't working hard. I didn’t know how to explain that I was trying really hard to use AI to learn.”

At the same time, their senior colleague might have experienced that moment very differently. It’s possible they felt they were passing on important advice, or sharing a friendly rant. After all, software communities often taken passionate rants as a sign of commitment to the craft.

But notice that this tough moment is exacerbated, profoundly, when you don’t know how to predict whether the expected behavior around you will be fair or whether it'll come down onto you like a hammer at the slightest misunderstanding. When you wonder, like my developer friend did, about how the person in the room with you will treat you when they have power over you.

Unfairness is a powerful learning signal for us. We are vigilant for it, we encode it deeply, and it casts a very long shadow through our behavior after we’ve experienced it. We have significant cognitive and psychological architecture built to assess whether the people around us are authentic or hypocritical, whether our group enforces shared rules equitably, and whether we’ll be ok if we ever make a mistake.

Because of this, big, nasty eruptions in our workplaces of organizational unfairness are costly. They're also a sign of a chaotic, unfinished technology and teams that haven't put the right kind of work into shared norms, in my humble opinion. It feels unsustainable because it is unsustainable to worry about inequitable expectations while also experimenting with new ways of working.

There are three major points I often feel like I need to make when I talk to technical teams about unfairness and AI and our misconceptions about it. The first is that unfairness can happen regardless of our beliefs about the utility of AI. The person who shovels Slop Mountain feels that their effort is getting disconnected from their adequate reward, and the person learning and experimenting feels they can’t be seen for who they are.

The second is that loyalty, and caring about work, doesn't help people "get over" moments an organization messes up and treats them unfairly, like your passion for your job will just balance out the scales. Leaders especially should be cautious of assuming they can lean on people's passion for work and loyalty to help them metabolize org unfairness; actually, this can make its effects worse. People who strongly identify with their organization and genuinely want to be there are often even more sensitive to violations of fairness because it is such a significant rupture from how they want to see it, and threat to a place they value.

Third, for most orgs, every new dimension of unfairness is probably making itself known in the context of past fears about unfairness. This means we are looking not just at the way we're being treated right now, but most of us are scanning to see if we find evidence for old bad patterns where we've seen unfairness unfold. One big one I see is that systems for vetting, checking and understanding software work have not been valued at the same level as our generation and production systems have. Therefore, people who do that kind of work don't always feel as respected or rewarded. Across tech we often fundamentally devalue work that we see as less “core” to the stereotypes we have about what technical thinking is; that’s a point I’ve made many times over as I write about how much social learning is devalued in software communities.

I firmly believe that in order for us to continue to benefit from increasing automation in technology work, we will need to develop this side of the work. We need to learn to see unfairness patterns, because they interfere with how we think, learn, and build together.

But how can we even learn to see it?

I don’t think the presence of organizational unfairness in our workplaces means the situation is hopeless. Cultures change regularly, and as they do, we can make different choices to shift to a climate of fairness.

The colleague who notices our good contribution at a meeting reaffirms our sense of fairness. The leadership that calls a halt and a change to a process that isn’t working can reaffirm our sense of fairness.

Good explanations encourage us to believe that our organization will act fairly, even when we don’t agree with its choices. Fairness doesn’t mean consensus. People who believe their organization is making fair decisions, even when they personally don’t agree with them, are less rattled in their work and more capable of seeing multiple sides of the issue.^[1] Just as the real and rigorous definition of psychological safety is less about gooey feelings and more about inferences we make about information flow and risk, organizational fairness is less about never-challenged agreement and more about mature, grownup commitment to striving for impartial fairness as an ongoing practice.

In fact, fairness benefits are one of the biggest reasons I tell engineering leaders it’s worth it to cultivate a transparent, open, and co-designed evidence practice. You're going to implement AI and claim it's not going to affect code reviews? Well what's your pre- and post- measurement of that? You're going to care about developer comprehension? Well what's your signal that people are getting enough time? Even if people don't see a measure as perfect, they'll know how we've chosen to evaluate something in this moment that we're saying matters to us.

Just showing people what you are basing your decisions on and what might move them increases our sense that information is fair – in other words, feeling like we have access to information that impacts our lives, and that we know what our leaders are learning from and using to steer their decisions.

On that note, you asked if I look at people or systems. Charity, to a psychologist, people are systems! And systems, like soylent, are made of people.

Why choose? I look at both. As I wrote in my identity crisis piece in this series, unpacking identity threat gives us a map to some of the useful and key diagnostics we can make about improving our environments at the individual level. As always in psychology, even for identity threat measures on the individual level, it’s about seeing individual beliefs as shaped by social context.^[2]

In particular, I find individual measures like AI Skill Threat (which I’ve used often on teams), or developer motivation and agency (factors from my LABS model) helpful outcome measures for this era. They show the cost of poor environments on the individual, and can be used as a guiding light for improvements.

But in the quest for diagnostics to change things, I go structural. Good news for us though: you can ask individuals about structural features of their workplace (with a well-designed scale, one that’s been validated and robustly tested!). And when you do you’ll find there are shared cultural conditions across companies, teams, and technical communities that either pour fuel on these simmering tensions, or help your org metabolize them. Perceptions of organizational unfairness is one of those conditions, a structural driver we can start to unpack.^[3]

Starting frames for measurement

In psychology, we try to get a view on fairness and how to fix it by asking people questions about multiple subcomponents.

I think about diagnosing and then working toward repairing organizational fairness/justice by thinking about:

1) what people get (distributive justice)
2) how decisions are made (procedural justice)
3) and how people are treated (interactional/interpersonal justice).^[4]

Org fairness is understudied in technical workplaces and has rarely been studied with software developer populations (like all psychological experiences!). So I’ve designed my own, over months of reading research and testing different items with real teams. I started using organizational fairness measures across real working teams and…spoiler alert, they’re awesome. Org fairness measures have absolutely shifted my conversations with engineering leadership away from individuals, and toward thinking about the structures we're putting around individual choices.

Warming my empirical heart, these measures also associate in exactly the ways I’d hoped with all kinds of moment-by-moment frictions for teams, and the large human outcomes I look for as red flags for whether people are set up to do their best technical thinking together: dampened sense of belonging, inability to choose long-term goals, and fears of reporting mistakes, incidents and errors.

One of the main factors I see failing right now on AI, and reach for, is people’s shared sense of procedural justice.

Here is an example, a general survey item I have used for work with software teams this year to get a quick pulse check on their feelings about procedural injustice when it comes to AI adoption:

If I raise a concern about how AI adoption is being measured or incentivized, I believe it would be heard

Or

If an AI process works in one team context but doesn’t work in another’s team’s context, I believe my organization will take that into account

There are a lot of ways to tailor these items (you could ask about managers, leaders, colleagues, and org in general – I often try to run a diagnostic against all of those levels). This newsletter is already long and would turn into a whole book chapter if I made it about psychometrics, so just let me say, we think about how to design behavioral measures a lot, talk to your psychologist friends about your measures!

The patterns between my Org Fairness scale and other developer experience measures are super fun to explore; as I hoped, when I tested a scale of this concept in the field it mapped quite nicely onto the Agency part of my LABS model for Developer Thriving.

Agency, generally speaking, is your sense that your effort is going to reliably connect to an outcome. None of us have perfect agency, but we can move in and out of situations and environments that bring it to the surface as a reliable psychological affordance around us.

In my work, I’ve seen that developers who already find themselves with a strong affordance of Agency (where this is a norm in their environment) are taking that affordance downstream with them into the specific moments of wanting to dispute AI. Developers already challenged on agency find it difficult to engage with procedural channels for reporting AI concerns even when those channels exist.

So this gives you a bit of a roadmap: establishing channels for raising concerns won’t work when people doubt the safety of those channels. But when you have high agency but no shared procedural justice channels to direct it, all that agency might boil over into slack arguments, unproductive conversations, and chaotic interactions.

On the other hand, you might find your workplace is doing pretty ok on procedural justice, but not interactional/interpersonal justice. That requires a different fix.

Developers experiencing interpersonal injustice might feel that they are experiencing a constant slow-drip of unfair treatment from colleagues that doesn’t quite rise to the level of an organizational structure, and if your org lights up red on this subcomponent, that’s super useful to know because the intervention to fix it probably needs to look more like manager training and culture resets than like procedural channels for adoption concerns.

Interpersonal injustice is a potent subcomponent here because it undermines the dignity we feel at work (“Chilly Climates,” one of the three thinking traps I describe in my book that get us stuck in Brains-in-Jars models of software development, is a cultural default that can create interpersonal injustice). Managers who set an otherwise relatively fair policy but make constant contempt comments alongside it, or who fail to intervene when a member of the team undermines someone else’s sense of psychological safety, can be perpetuating interpersonal injustice even when explicit work policies are fair.

This leads me to a point I always, always try to make with developer experience measures: an enormous amount of the insight will always happen in the interactions between factors and what they tell us about characterizing an environment. Don’t get stuck on thinking that the quest is for a single silver bullet. Like measuring multiple vital signs and also taking in patient context (a heart rate after a run is completely different information than a heart rate at rest), we are interested in holistic, interacting pictures.

Also of note and really important here, when I run this kind of item even for people who strongly disagree with how their orgs are adopting AI, those people report better outcomes. They are engaged more deeply in their work of their orgs, they rate their teams as more effective, they have a deeper belief that people around them give a shit about them, and they are less checked out from the problem.

In your last piece, Charity, you wrote: making your team happy is not the job. I agree with this for the shallow historical model of “happiness” you critique. But meeting the preconditions for good human thinking and collaboration absolutely is the job. I think organizational fairness is one of those preconditions.

and now...join us!

Folks, if you've found this series interesting, let's talk about it all together. I'm excited to share I'll be joining Charity on October 21 for a live discussion and AMA on AI, Trust, and Identity in Engineering Teams. I hope you can join us, and bring your own questions, experience and insight!

Register here!