---
author: "[[Bob Marshall]]"
tags:
  - blogpost
publish: 2026-08-19
sources:
  - https://flowchainsensei.wordpress.com/2026/08/19/personality-issues/
---

## Personality Issues

Two of your engineers cannot work together. Everyone knows it. In stand-up they are clipped with each other. In code reviews, one of them leaves comments that the other reads as insults. You have had them both in your office, separately, and each has described the other in terms that boil down to _that person is difficult_.

So you file it under personality clash. Different wiring. Some people just do not mesh. You start thinking about how to keep them off the same projects.

You have almost certainly just misdiagnosed the problem, and the misdiagnosis is expensive, because ‘personality’ is a diagnosis with no treatment. If the problem is who someone _is_, your options are separation or removal. That is why the label is so attractive and so dangerous: it closes the case.

Look again and there is usually a specific, factual, fixable disagreement in there – though you are unlikely to be the one who can name it. It might turn out that one of them treats a pull request as a quality gate and the other treats it as a conversation. Neither has ever said so, because to each of them it is not an opinion – it is simply what a pull request _is_. Which is also why neither will say it in answer to ‘so what’s the actual problem?’ Nothing is being withheld from you. It is not yet in view, and it comes into view for its owner or not at all.

### Why We Reach for Personality First

Psychologists call it the _fundamental attribution error_: we explain other people’s behaviour by their character and our own by our circumstances (Ross, 1977). I pushed back hard in that meeting because the deadline was unrealistic. You pushed back hard in that meeting because you are combative. The same asymmetry shows up in how we perceive bias itself – we see distortion in other people’s judgement far more readily than in our own, and we tend to insist on our own objectivity even after the mechanism is explained to us (Pronin et al., 2002).

There is a second reason, specific to work. Assumptions are invisible from the inside. You do not experience your beliefs about how software should be built as beliefs; you experience them as the way things are. Argyris and Schön (1974) drew the distinction that matters here: the theory a professional _espouses_ is rarely the theory that actually governs their behaviour, and the governing one is usually not available to them for inspection. It was formed somewhere – a previous employer, a formative outage, a mentor, a codebase that burned you – and in that context it was probably correct. What you carry forward is not the context, only the conclusion. So when you meet someone whose conclusion differs, they do not seem to hold a different view. They seem to be ignoring reality.

That feeling of _bafflement_ is the giveaway. Ordinary disagreement feels like disagreement. Colliding assumptions feel _like watching someone deny gravity_.

### The Same Argument, Wearing Costumes

What follows is a list of hypotheses, not findings. They are worth knowing because they tell you what sort of question to ask next. They are worth holding lightly for the reason in the next section.

**‘He’s a perfectionist.’ / ‘She ships junk.’** Neither is a personality trait. It is a disagreement about the cost of a defect and the reversibility of a decision. If your last job was payments infrastructure, a bug is a customer’s rent money. If your last job was a consumer app with a two-hour deploy cycle, a bug is a Tuesday. Both people have calibrated correctly for a context. Only one of them is in it now, and nobody has said which.

**‘He’s obstructive.’** Usually this means he believes he owns a decision that you believe you own. Decision rights are the single most under-specified thing in most organisations, and the resulting bottlenecks are structural rather than temperamental – they cluster predictably at the seams between functions, between the centre and the business unit, between inside and outside partners (Rogers & Blenko, 2006). Two people can spend a year in low-grade conflict without ever discovering that both of them think the architecture call is theirs.

**‘She’s not a team player.’** Often: she is optimising for a different objective from the rest of the team, and she thinks it is the one she was hired for. The platform engineer blocking your feature is not territorial; she has been told she is accountable for a reliability number that your feature threatens. Two objectives, one of them unstated, and it comes out as a character note.

**Estimation fights.** Almost never about estimates. They are about what an estimate _is_. One person thinks it is a forecast with error bars. Another thinks it is a commitment. A third thinks it is a bid in a negotiation and is inflating accordingly. All three are being perfectly reasonable inside their own definition, and all three think the others are respectively vague, rigid and dishonest.

**Sales versus engineering.** The oldest one. ‘Sales overpromises’ and ‘engineering sandbags’ are the surface. Underneath is a real, substantive disagreement about which constraint binds the business: demand or capability. If demand is the constraint, promising the roadmap to close a deal is obviously right. If capability is the constraint, it is obviously suicidal. That is a question with an answer, and it is an answer the two departments have never sat down and worked out together.

**‘They just don’t get it.’** Frequently a definitional gap wearing a contempt costume. What counts as _done_. What counts as _technical debt_ rather than a deliberate trade. Whether ‘the customer’ means the buyer, the user, or the person who renews. You can run a whole quarter on a shared vocabulary that is not shared.

Notice what all six have in common. Each is plausible enough that if you said it out loud in the room, everyone would nod. That is precisely the danger. A formulation accepted out of deference is indistinguishable, from the outside, from one that is true, and it closes the case exactly as efficiently as ‘personality’ did. It just closes it on a more flattering answer.

### How to Tell Which One You Have Got

A few reliable signals that you are looking at assumptions rather than personalities.

The conflict is **topic-bound**. They are fine at lunch, fine together at two in the morning during an outage, and at each other’s throats about deployment process. Personality does not switch off for lunch.

Both are **well regarded by other people**, just not by each other. The patterns that survive every context show up in every context.

Each describes the other as _not making sense_, rather than as wrong. Bewilderment beats disagreement as a diagnostic.

The word **‘obviously’** appears a lot. ‘Obviously’ is what we say at exactly the point where an assumption is doing load-bearing work and has not been checked.

The argument **recurs in different clothes**. Same two people, same heat, new topic every month. That is a stable disagreement upstream of all of them, unresolved because nobody has gone upstream.

The distinction is not merely rhetorical. Conflict researchers separate _task_ conflict – disagreement about the work itself – from _relationship_conflict, the personalised friction between individuals (Jehn, 1995). A meta-analysis covering 116 studies found that relationship and process conflict are reliably bad for group outcomes, while task conflict is not straightforwardly harmful at all, and is associated with better results where teams manage to keep it from bleeding into the personal (de Wit et al., 2012). Filing a task conflict under ‘personality’ does not just misdescribe it. It converts the tractable kind into the corrosive kind.

### Going Upstream

The move is to convert a dispute about people into a dispute about the world, because disputes about the world can be settled and disputes about people cannot. The catch is that you cannot perform the conversion on someone else’s behalf.

_Ask each person what would have to be true for the other’s position to be the right one._ This is a genuinely hard question and it is the fastest route to the hidden premise. It also has the useful side effect that nobody can answer it while holding the belief that their counterpart is simply an idiot.

Ask where the belief came from. ‘When did you learn that?’ gets startlingly specific answers: a company, an incident, a manager. Once the origin is on the table, the belief looks like what it is – a local adaptation – and you can ask the real question, which is whether the local conditions still hold here. This is the work Senge (1990) described as surfacing mental models, and it is unglamorous: mostly it consists of asking people to say the obvious part out loud.

Both of those are questions, and that is not incidental. An assumption becomes visible to its owner or it does not become visible at all. Delivered from outside, it converts on contact into a proposition to be agreed with or defended against, and either way it stays theory – the one thing it does not do is become something the person can see themselves holding. So keep your own reading of the situation to yourself and use it to choose the next question rather than to announce the answer. If you do offer it, offer it as a guess, and treat a flat rejection as information rather than as resistance to be worked through. You were guessing. Now you have a better guess.

Separate the layers. Most stuck arguments are three arguments braided together: a factual question (how often does this actually break?), a values question (how much risk are we willing to carry?) and an authority question (who decides?). Untangled, each is tractable. Braided, they are a personality clash.

Then write the resolution down, along with what would make you revisit it. Not to be bureaucratic – because an unwritten decision decays back into two private assumptions within about a month, and you will have the same fight again in a new costume.

None of which means waiting on insight. You are not anybody’s therapist, and two kinds of authority come apart cleanly here. Whether reviews are gates or conversations on this team is yours to settle, and it may need settling on Thursday whether or not either of them has had a realisation. What is not yours is the account of what they each believed and why. Decide the question without claiming to have read their minds, and the decision will hold better for it: most people can live with a call that went against them far more easily than with being told what their problem was.

None of this happens by default. Saying ‘I think we mean different things by _done_‘ is an admission that you have been operating on an unexamined premise, and people only make admissions like that on teams where doing so is not punished. Psychological safety is usually invoked for error reporting, but the mechanism is identical here: the shared belief that speaking up carries no interpersonal penalty is what allows a hidden assumption to become a visible one.

Notice that none of this requires the two people to like each other. That is the point. You are not doing team-building; you are doing engineering on a shared model of reality. Plenty of people who will never be friends work together perfectly well once they agree what the code review is for.

### Where This Framing Runs Out

It would be dishonest to pretend every conflict dissolves under analysis. Some do not.

Some behaviour is contemptuous, dishonest or cruel, and it persists after the assumptions have been surfaced. Note the shape of that sentence. It is not a claim about who someone is; it is a claim about a pattern that has survived the diagnostic, which makes it the kind of thing that can be checked and, in principle, disconfirmed. That distinction is not pedantry. ‘He is a difficult person’ explains nothing and predicts nothing, whereas ‘he responds to disagreement by belittling whoever raised it, in every context, including after three conversations about it’ tells you precisely what has to change and how you will know if it has.

Keep the two apart, because collapsing them fails in both directions. Treating a pattern as an essence lets you skip the diagnostic entirely – which is the whole error this piece is about. But refusing to name any pattern at all is worse in practice: ‘there are no difficult people, only unexamined assumptions’ is a sentence that ends up asking the person on the receiving end of contempt to go and surface their tormentor’s premises for them. Sutton (2007) makes the harder managerial argument – that tolerating this has costs an organisation can actually account for, and that the answer is a rule rather than another conversation.

Power asymmetry also breaks the method. ‘Let us surface our assumptions’ between a principal architect and a graduate hire is not a symmetric exercise, and if you run it as one you will get compliance and call it consensus.

And sometimes, after all the assumptions are on the table and examined, two people simply want different things and both cannot have them. That is a real conflict. It deserves a decision, not a dialogue.

But those cases are rarer than the label suggests. The base rate is overwhelmingly this: _two competent people, each acting sensibly given a set of beliefs neither has ever articulated, generating friction that everyone around them reads as chemistry._

Personality is not a diagnosis. It is what we write down when we have stopped looking.

### Further Reading

Argyris, C., & Schön, D. A. (1974). _Theory in practice: Increasing professional effectiveness_. Jossey-Bass.

DeMarco, T., & Lister, T. (2013). _Peopleware: Productive projects and teams_ (3rd ed.). Addison-Wesley.

de Wit, F. R. C., Greer, L. L., & Jehn, K. A. (2012). The paradox of intragroup conflict: A meta-analysis. _Journal of Applied Psychology, 97_(2), 360–390. [https://doi.org/10.1037/a0024844](https://doi.org/10.1037/a0024844)

Edmondson, A. C. (1999). Psychological safety and learning behavior in work teams. _Administrative Science Quarterly, 44_(2), 350–383. [https://doi.org/10.2307/2666999](https://doi.org/10.2307/2666999)

Jehn, K. A. (1995). A multimethod examination of the benefits and detriments of intragroup conflict. _Administrative Science Quarterly, 40_(2), 256–282. [https://doi.org/10.2307/2393638](https://doi.org/10.2307/2393638)

Pronin, E., Lin, D. Y., & Ross, L. (2002). The bias blind spot: Perceptions of bias in self versus others. _Personality and Social Psychology Bulletin, 28_(3), 369–381. [https://doi.org/10.1177/0146167202286008](https://doi.org/10.1177/0146167202286008)

Rogers, P., & Blenko, M. W. (2006). Who has the D? How clear decision roles enhance organizational performance. _Harvard Business Review, 84_(1), 52–61.

Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), _Advances in experimental social psychology_ (Vol. 10, pp. 173–220). Academic Press. [https://doi.org/10.1016/S0065-2601(08)60357-3](https://doi.org/10.1016/S0065-2601\(08\)60357-3)

Senge, P. M. (1990). _The fifth discipline: The art and practice of the learning organization_. Doubleday/Currency.

Sutton, R. I. (2007). _The no asshole rule: Building a civilized workplace and surviving one that isn’t_. Business Plus.
