A Psychology Modality for Engineering

The One Framework That Actually Fits Engineering's Mess

You’re in a one-on-one and someone just said something that made your chest tighten. A senior engineer is shutting down a junior. A team is locked in the same architectural argument for the third time. Someone is shipping nothing because they’re convinced it’s not good enough yet. Your instinct is to fix it: to convince them they’re wrong, that their fear doesn’t make sense, that they should just move forward.

And then nothing changes.

This is the gap that opens up in engineering leadership. The work itself, the technical problems, you can solve. But the problems hiding inside people’s minds? The spiraling thoughts, the frozen decision-making, the resentment that hardens into cynicism? Those don’t yield to the same tools.

If I had to point to one framework that actually maps onto what’s happening in those moments (and what your brain needs to do to help), it would be Acceptance and Commitment Therapy, or ACT (pronounced “act”, and not spelled out). Not as therapy, but as a coaching stance. Because ACT works not by trying to convince people to feel different before they act, but by helping them notice what’s happening inside and then choose what matters anyway.

Here’s why that distinction matters for you as an engineering leader.

Why the usual move doesn’t work

Your instinct is often to argue the other person out of their thought. If someone thinks their ideas aren’t good, you reason with them. If someone thinks a change is pointless, you make the case. If someone feels like a fraud, you list evidence to the contrary.

And engineers, especially, will engage with this. Your team is full of people who can run arguments in their heads all day. But here’s what neuroscience shows: the more someone argues internally against their own thought, the harder they try to win the debate in their mind, the more stuck they often become. Your brain interprets the argument itself as evidence that something is actually wrong. If I have to convince myself this hard that I’m good enough, maybe I’m not. If the outcome was really safe, why am I still worried?

ACT offers a different move altogether. It doesn’t ask someone to win the internal debate. It asks them to notice the thought as a thought, not as a verdict about reality, and then ask what actually matters and what can be tested. That’s it. Your mind is predicting failure. Okay. That makes sense given what happened. Now, separate that prediction from what the evidence actually shows, and pick the smallest experiment that moves uncertainty down.

This works because it stops the escalation cycle. The person isn’t fighting themselves anymore. They’re acknowledging what their brain is doing and choosing their action anyway.

The mechanism beneath this

Your brain is a prediction machine. It evolved to anticipate danger and protect you. When you’re in unfamiliar territory, when you can’t see clear success criteria, when feedback is late, when people disagree about what matters, your brain gets louder. It generates a lot of worried thoughts. It’s trying to keep you safe by running failure scenarios. This is not a bug in your team members. This is how brains work, especially brains that are good at engineering, because those brains are wired to notice what could go wrong.

ACT doesn’t try to quiet that voice. Instead, it trains people to notice it without being puppeted by it. Your mind is doing its job. That doesn’t mean the thought is true. That doesn’t mean you have to act on the prediction. You can hear it, acknowledge it makes sense, and then choose what you actually want to do based on what matters and what you can learn.

For you as a leader, this is the most powerful part: you can help someone take good action without requiring them to feel calm first. You don’t have to fix their emotions. You just help them look at what’s real and decide what’s next.

How this actually shows up in the moments that matter

A junior engineer comes to you quiet, shoulders tight. I guess my ideas aren’t good, they say. Your instinct is to debate this, to counter it with evidence. Stop there.

Instead, stay with what actually happened. I hear the thought: My ideas aren’t good. That makes sense given what you experienced. Let’s separate that thought from what actually occurred. Walk me through the meeting step by step. What was said? When exactly did you stop speaking? You’re anchoring them in observable events, not in their interpretation of what those events mean about them.

Once you have the facts, you move to choice. Not confidence. Not reframing. Choice. In that room, in those meetings going forward, what kind of teammate do you want to be? Not the person everyone else approves of, but the presence you actually want to have, even when someone pushes back? Then you get specific about the behavior. A two-sentence point they can practice. A clarifying question they can ask. A calm interruption repair: Can I finish the thought?

You’ve turned a global collapse into a testable, doable practice. Their mind will probably still generate the worried thought next time. That’s fine. They’re learning to act anyway. And when they speak anyway, their brain updates. The thought becomes less sticky because evidence contradicts it. This is how people rewire: not through arguments, but through practice that collides with their predictions.

Now flip the scenario. The senior engineer says, I’m just being efficient. We don’t have time for hand-holding. You feel the impatience in that sentence. There’s something driving it: fear, maybe, or the very real pressure of velocity. That’s not the lever.

You coach them through what’s actually happening. When you feel the conversation dragging, something in your mind pushes you to cut it off. I get it. There’s real time pressure here. You’re validating the experience, not the behavior. We also have a standard for how we work together. What impact do you actually want to have in those design discussions? Then you offer an alternative that still respects speed, because speed wasn’t the real value. Control and efficiency were. If you think an idea won’t work, ask one crisp question first: What constraint are you optimizing for? or What failure mode worries you? If you still disagree, say it plainly and move: I don’t think this holds under load because X. Let’s test Y by Thursday.

You’re not reshaping their personality. You’re helping them choose a behavior that meets your team’s actual standard. And here’s what happens: when they do this once and see it work, when they see the junior actually clarify the thinking and the decision move forward, their brain updates too. The threat they felt in the conversation (wasted time, inefficiency, someone failing) resolves differently. They find out the team standard isn’t actually slow.

The architecture war

When two strong engineers lock horns, and they will at some point because good engineers have strong models of the world, ACT gives you a way to lower the temperature without erasing the legitimate disagreement.

First, you name the pattern they’re in. Not as a criticism, but as an observation. I’m hearing defense and counter-defense. Let’s pause. Then you move from positions to the actual concern underneath. What do you fear will happen if we pick the other approach? Now you’re in the real territory. One person fears long-term maintenance costs will explode. The other fears missing the launch and the thrashing that follows. Both are legitimate risks. Both are real.

Here’s where most leaders try to find the compromise that makes everyone unhappy. Instead, you steer toward what reduces actual uncertainty. We’ll prototype for two days, measure the impact, and decide Friday. If the data is even split, we choose the option that best protects uptime. You’re not deciding the architecture. You’re deciding how to reduce the uncertainty that’s driving the argument. And you’re creating a clear commitment that stops the debate loop. The conversation ends because there’s a decision point, not because someone was convinced.

This is profound: the argument itself was partly a way of trying to reduce uncertainty through discussion. Once there’s a concrete path to actual information, the argument often dissolves. Not because someone changed their mind, but because they have something to do instead of something to defend.

The refactoring that never ships

Here’s a pattern that shows up constantly: someone keeps expanding scope, refactoring, reaching for better. The work doesn’t land. They tell you, I just want it to be good.

You could argue about what good means. Don’t. Make it concrete. When you say good, what does that look like in observable terms? What does good enough to ship look like? When they describe it, you gently name what’s actually happening, not as a criticism, but as something their nervous system is doing. It sounds like shipping feels risky. Like people will judge it.

Now you build a plan that contains the risk instead of trying to eliminate it. Ship behind a flag. Define acceptance criteria together. Stop when criteria are met. Move “better” into follow-up work with clear ownership. You might also say something like, Your mind wants certainty about this work. This work can’t give you certainty. It can give you tests, monitoring, rollback, and learning. That helps them move without requiring them to feel calm about shipping first.

What’s changed is the frame. It’s not about willpower or confidence anymore. It’s about what tools actually exist (tests, rollback, iteration) and using those tools to manage the legitimate risk. Their mind might still generate worried thoughts. But they’ve got a structure that works even when those thoughts are loud.

The code review spiral

A developer reads a blunt PR comment and their whole body tightens. They think I’m incompetent. Their mind has leapt from the code has an issue to I am the issue. This is how human brains work: we personalize feedback as identity feedback.

You don’t tell them not to take it personally. Instead, you help them translate it into something actionable. Let’s read the comment word for word. What change is it actually asking for? What doesn’t it say? You’re anchoring them in what’s there, not in the story their mind wrote. Most blunt feedback has no identity commentary in it at all. The mind added that.

Then you help them respond in a way that keeps both clarity and dignity. I see the concern about the edge case. I’ll adjust it. Can you point me to the guideline you’re referencing so I align with the team standard? This response does something important: it treats the feedback as information about a standard, not as a judgment about the person.

And you coach the reviewer too, if there’s a pattern. Your feedback is often correct. Your wording is making it harder for people to use it. When you write This is wrong, people stop thinking. Try This breaks when X happens plus one suggested fix. You’re helping them see the impact of their communication, not shaming them, but making it visible. Over time, this becomes a team norm: comments name a risk, propose a fix, avoid personal diagnosis. Everyone moves faster because the feedback loop actually works instead of triggering identity spirals.

The resentment that hardens

Cross-functional work reliably creates friction. Product keeps changing the priorities. Someone says, Product keeps changing everything, and you feel the edge in their voice. They’re starting to treat the other function as the enemy. This hardens fast.

ACT keeps you grounded in what actually happened instead of letting the story take over. What changed, specifically, and what did it cost us? You’re not arguing with their frustration. You’re asking them to be specific about the impact. Once they name it, you redirect toward what they can actually influence. I hear you. I also need us to choose what we stop doing so we can protect quality. You’re helping them move from resentment to assertive collaboration, with language that keeps the relationship intact. I can support the change. Here’s what I need.

This is a small move, but it’s powerful. Instead of stewing in product is the enemy, they’re making a clear request. Their brain goes from threat mode to problem-solving mode. And the relationship stays intact, which means the next conflict won’t feel like another attack.

The incident that becomes shame

On-call stress and incidents create a specific kind of internal problem. Someone freezes during an outage. Later, they beat themselves up. I should have known, they keep replaying. I should have moved faster.

In the moment, you coach toward the next right step. Not toward confidence or calm. Toward action. Tell me what you see, what you tried, and your next hypothesis. You’re narrowing the task, keeping their mind from racing, pulling in a second set of eyes early. You’re not trying to make them feel capable. You’re structuring the work so they can function despite the fear.

In the debrief, you separate learning from identity. This matters deeply. The system failed in a predictable way. You responded under pressure. Let’s write down what we’ll change in the system and what we’ll rehearse as a team. You’re not asking them to decide they’re good enough. You’re asking what can be changed and what can be practiced. There’s learning without punishment.

If shame shows up, and it will because humans are wired to use shame to prevent future failure, you can name it without drama. Your mind is replaying the worst moment to protect you from repeating it. That’s what brains do. We can learn the actual lesson without punishing yourself. Then you get practical. What do you want to do next time when your heart rate spikes? You practice a short script they can use during the next incident. State the facts out loud. Ask for help. Take one small step. That’s it. Not perfect performance. Just the next right move.

The load that becomes resentment

Someone says, I always get the hardest tickets and nobody notices, and their tone gets sharp. You can feel the simmering underneath. This person is running hot.

You don’t try to convince them they’re appreciated. You help them get specific about what they actually want. What do you want, exactly? Fewer interrupts? More visible work? Clearer credit? A different growth direction? When they name it, you help them request it directly: I want to work on a feature that grows me in X. I can carry on-call, and I need a boundary around interrupts. That’s a request, not a complaint. It changes the whole conversation.

And you own your side if needed. I haven’t made tradeoffs explicit, and I haven’t recognized the load you’ve carried. I’m going to change that. You’re not being defensive. You’re being responsible. This person’s resentment often has real facts underneath it. Acknowledge those facts. Change what’s in your control.

The bottom-line

Here’s what runs through all of these moments: you keep conversations anchored in observable events instead of in the stories people’s minds have written about those events. You treat emotions and thoughts as information, signals that something matters, rather than as commands that have to be obeyed or fixed. And you end every conversation with a next action someone can actually take in the next day or week. Not someday. Not when they feel better. Now.

This is leadership in a domain where uncertainty is the constant. Your team is going to keep having worried thoughts. They’re going to keep spiraling into what if. That’s not going away. What changes is whether they’re stuck in those thoughts, or whether they can notice the thoughts and choose their action anyway based on what actually matters and what they can learn.

You’re not a therapist. You’re staying firmly in the lane of leadership and coaching. When someone needs support beyond workplace functioning, when the struggle is about more than managing uncertainty at work, you route them to appropriate resources through EAP, benefits, HR, or a clinician. You’re not trying to treat what needs treatment.

But in those ordinary moments, the one-on-ones, the code review spirals, the architectural arguments, the incidents and the resentment, this stance gives you something real to do. You can help someone stay steady while they make good decisions with incomplete information. You can keep them from getting tangled in their own minds. And you can do it without pretending any of it is easy, without false confidence, and without requiring them to feel okay before they act.

That’s the entire game in engineering leadership. And ACT trains you to play it.

Reference:

Harris, R. (2022). The Happiness Trap (Second Edition): How to Stop Struggling and Start Living. Shambhala.