Many software teams have gotten smaller. Over the last several years, a large share of the industry has drifted away from heavily layered engineering departments and toward small, highly autonomous squads — three or four people who own a service end to end, ship independently, and answer to a backlog instead of a hierarchy. The pitch is obvious: less coordination overhead, faster decisions, tighter ownership. What gets less attention is what this shift does to the person sitting inside one of those small teams at eleven at night, staring at a pull request they're not sure is right, with no senior engineer down the hall to ask.
That scene is becoming increasingly common, and organizational psychologists are starting to notice the cost. Research on team design has found that as organizations flatten and autonomy increases, individual cognitive load rises with it — engineers are absorbing more decisions, more ambiguity, and more responsibility for judgment calls that used to be distributed across a bigger group. The traditional scaffolding of a large team — a tech lead to sanity-check your approach, a QA process to catch what you missed, a manager buffering you from the business side — is exactly the kind of redundancy that autonomous team structures are designed to strip out. That redundancy, it turns out, was doing more than distributing work. It was distributing anxiety.
This matters because the psychological experience of writing code hasn't changed at the same pace as the org chart. Developers still have the same nervous system humans have always had, one built to read ambiguity as danger and isolation as risk. What's changed is the amount of unresolved uncertainty an individual is now expected to metabolize alone. The result is a workplace environment where many developers report higher levels of performance anxiety, and where a very old, very familiar visitor keeps showing up: impostor feelings. This piece is about why that's happening, what the underlying psychology actually is, and what a developer — and a team — can do about it that isn't just "believe in yourself."
The Ambiguity Threat: Why Your Brain Treats a Vague Ticket Like a Predator
Impostor syndrome gets talked about as if it were a personality quirk, a flaw in certain people's self-confidence wiring. That framing is mostly wrong, and it's worth being precise about why.
The human brain did not evolve in a world of shifting technical specifications, but it did evolve in a world where not knowing something — where the threat was, whether a stranger was hostile, whether the ground ahead was safe — could get you killed. Ambiguity itself, not just concrete danger, is something the brain is built to treat as risky. Neuroscience research on uncertain-threat anticipation has found that ambiguity engages threat-processing networks involving regions such as the amygdala and related circuits associated with vigilance and prediction, and that these networks tend to stay engaged for longer, and less predictably, than when a threat is clear and defined. A known threat, oddly, is often easier on the nervous system than an unknown one. Certainty lets the brain relax once the threat has passed. Ambiguity keeps the alarm running in the background indefinitely, because there's no clear signal telling it the "all clear" has arrived.
This is not a fringe finding. A body of work on anxiety and uncertainty, reviewed in detail by researchers studying anxiety disorders, describes something close to a general principle: people don't just respond to danger, they respond to the inability to predict danger, and that inability is often more distressing than the danger itself. People with a harder time tolerating uncertainty show heightened activity in threat-related brain circuitry specifically when a situation is ambiguous, even when nothing bad is actually happening.
Translate that into a developer's daily experience and the pattern becomes obvious. A vague ticket, a codebase you didn't write, a spec that changes mid-sprint, a pull request sitting unreviewed for two days with no comment — none of these are physically dangerous. But they are ambiguous, and ambiguous is precisely the category of stimulus your threat-detection system was built to flag. When you're on a small team without someone to immediately clarify the ambiguity for you, that flag doesn't get resolved. It just sits there, humming, and your brain interprets the hum as evidence that something is wrong with you rather than evidence that the situation is genuinely unclear.
That's the mechanism behind what we might call the ambiguity threat in engineering contexts: a baseline of low-level anxiety that isn't really about your competence at all. It's a background threat-response running because the environment is feeding your brain exactly the kind of unresolved signal it's wired to worry about. Machine-speed codebases — fast-moving repos, rapidly shifting dependencies, specs that update while you're mid-implementation — generate an unusually high volume of that signal. Your threat-detection systems don't have a clean category for "ambiguous but professionally routine." They just have ambiguous, and they respond to it the same way they always have.
AI-assisted development adds a newer version of this same problem. A developer can now generate code faster than they can build genuine confidence in their understanding of it. The bottleneck shifts from producing output to validating judgment. When a model hands back a plausible-looking solution with reasoning that isn't fully visible, the psychological challenge stops being just "can I write this?" and becomes "can I actually tell whether this is correct?" That's a harder, more ambiguous question, and it arrives more often, for more of the day, than it used to. In that environment, the team practices described below matter even more, because asking out loud "does this approach actually hold up?" needs to function as a normal, expected part of engineering work rather than something that reads as a gap in skill.
Impostor Syndrome Wasn't Designed for Software Engineering
The term "impostor phenomenon" comes from a 1978 paper by psychologists Pauline Clance and Suzanne Imes, who studied a group of more than 150 highly accomplished women — professors, professionals, people with strong track records of success — who nonetheless felt they were frauds who had somehow fooled everyone around them. Clance and Imes described this as an internal experience of intellectual phoniness, one that persisted no matter how much objective evidence of competence a person accumulated. Notably, they didn't even call it a syndrome — Clance later pushed back on that label, since it implies a disorder located inside the individual, when what she was actually describing was more like a persistent, situationally reinforced belief pattern.
In the decades since, research has confirmed the impostor phenomenon shows up well beyond its original context — across genders, across professions, and with particular intensity during transitions: new job, new team, a jump into unfamiliar technical territory. That last detail matters a lot for engineering. Software development is one of the only professions where the "unfamiliar territory" transition never really ends. Frameworks turn over, best practices get revised, an entirely new tool can become table stakes within eighteen months. Developers are, in a sense, permanently new.
What's useful about connecting the ambiguity-threat research to the impostor-phenomenon research is that it reframes the whole experience. Impostor syndrome isn't a verdict about your actual skill. It's what it feels like from the inside when a nervous system built to treat unresolved ambiguity as risk is placed in an environment that produces an unusually steady diet of exactly that kind of ambiguity — a fast-moving codebase, limited external feedback, a small team without much structural redundancy. "I'm not good enough" is a more emotionally coherent story than the accurate but less intuitive one: my threat-detection circuitry is responding to unresolved uncertainty, and it doesn't reliably distinguish a vague spec from a genuine threat.
That reframe doesn't make the feeling disappear. But it changes what you do with it, which is the more useful question.
Cognitive Reframing for Engineers: Read the Error Log, Don't Internalize It
Developers already have a mental model that's unusually well suited to handling this, they just don't usually apply it to themselves: the error log.
When a system throws an error, a competent engineer doesn't take it personally. Nobody thinks "this stack trace means I'm fundamentally broken as a person." The instinct is investigative — what triggered this, what was the input, what's the actual failure condition. That instinct is worth deliberately importing into how you handle self-doubt.
This isn't just a metaphor; it maps onto something real in the psychology of emotion regulation. A well-replicated line of research on what's called affect labeling — the simple act of naming an emotion in specific, concrete language rather than just experiencing it — has found that putting a feeling into words is associated with reduced amygdala activity and increased engagement of regulatory regions of the prefrontal cortex. In practice, this means the difference between "I'm an impostor, I don't belong here" and "I'm noticing anxiety because this ticket is ambiguous and I haven't gotten feedback on my approach yet" is not just semantic. The second version is functionally closer to reading a log line than absorbing a verdict, and the research suggests that specificity itself has a calming effect on the underlying physiological response, independent of whether the situation has actually changed.
The practical version of this looks something like a debugging checklist, applied to the feeling itself rather than suppressed or fought:
What's the actual input? Usually it's something concrete — an unreviewed PR, a spec that changed twice this week, a codebase you inherited without documentation. Naming the specific trigger, rather than the diffuse feeling of dread, does most of the regulatory work.
Is this ambiguity resolvable, or is it structurally built into the situation? Sometimes the fix is asking a direct question. Sometimes the honest answer is that the codebase genuinely is underdocumented and the anxiety is a reasonable response to a real information gap, not a personal failing.
Is there a feedback loop I can shorten? Impostor feelings often thrive in feedback vacuums — work that goes into a PR queue and sits for days without comment. Shortening that loop, even by asking for a quick async check-in, gives your threat-detection system the "all clear" signal it's been waiting for.
None of this is about talking yourself out of a legitimate skill gap — sometimes the honest read of the error log is "I do need to learn this," and that's a fine, ordinary conclusion, not a crisis. The goal of reframing isn't relentless positivity. It's accuracy. Treating self-doubt as a data point to be examined, rather than a truth to be absorbed, keeps the signal without letting it metastasize into a story about your worth as an engineer.
Building Team Immunity: Psychological Safety in Small, Fast Teams
Individual reframing only goes so far if the team environment keeps generating the same volume of unresolved ambiguity. This is where the research on psychological safety becomes directly relevant, and it's worth being precise about what that term actually means, because it gets used loosely.
The concept comes out of work by Harvard Business School researcher Amy Edmondson, who in the late 1990s studied hospital teams expecting to find that better-performing units made fewer medication errors. She found that higher-performing teams reported more errors, which suggested they were more willing to surface mistakes rather than hide them, while lower-performing teams were more likely to under-report the errors they were actually making. Edmondson's subsequent research formalized this into psychological safety: a shared belief within a team that it's safe to take interpersonal risks — asking a question that might sound basic, admitting you're stuck, flagging a mistake before it compounds — without fear of embarrassment or punishment. Years later, Google's internal Project Aristotle research, studying roughly 180 of its own teams, independently arrived at a strikingly similar conclusion using very different methods: among the characteristics Google's researchers identified as associated with effective teams, psychological safety emerged as the strongest one, ahead of who was actually on the team.
It's worth being clear about what psychological safety is not, since the term gets softened in ways the research doesn't support. It isn't the absence of high standards, and it isn't a euphemism for niceness. Psychologically safe teams still disagree openly and give direct feedback — in fact, visible disagreement is often a sign the safety is working, not a sign it's absent. What it protects is the willingness to say "I don't know" or "I think this is wrong" out loud, rather than silently absorbing the uncertainty alone.
For a small, autonomous engineering team, this translates into fairly concrete practices, most of which live in the parts of the workflow developers already touch daily.
Code review language matters more than it seems. A comment that reads "this is wrong" produces a very different physiological response than one that reads "I'm not sure this handles the edge case where the list is empty — can you walk me through the reasoning?" Both might be pointing at the same bug. Only one of them treats the ambiguity as a shared problem to investigate rather than a verdict on the author.
Normalizing "I don't know" from senior people specifically does more work than any written policy. When the most experienced person on a small team openly says they're not sure how something works, or that they'd need to look something up, it recalibrates what "competent" is allowed to look like for everyone else on the team. Edmondson's own guidance on this point is that leaders acknowledging their own fallibility is one of the more reliable ways to shift a team's norms, because it directly contradicts the assumption that not-knowing is disqualifying.
Shortening feedback loops on pull requests is a structural fix for a psychological problem. A PR that sits unreviewed for two days doesn't just delay a merge — it extends the window in which the author's threat-detection system has no "all clear" signal. Even a same-day partial response ("haven't done a full review yet, but this approach looks right at a glance") closes that loop faster than silence does, and the ambiguity-threat research suggests that matters more than it might seem to on a busy team.
This becomes even more important in AI-assisted environments, where the ability to question, verify, and challenge generated output needs to function as a team capability, not just something each developer is expected to sort out alone.
None of this requires reversing the industry-wide move toward smaller teams, which brings real benefits in speed and ownership. It requires recognizing that smaller teams removed some of the structural redundancy that used to absorb ambiguity on a developer's behalf, and that the difference has to be made up somewhere — either by the individual's own regulation skills, or by deliberate norms the team builds into its daily workflow. Realistically, it needs to be both.
The Developer Debugging Checklist
The reframing described throughout this piece compresses into something closer to a quick reference than a mindset. When impostor feelings show up mid-task, it can help to run through it the way you'd triage a failing build:
Identify the input. What concrete uncertainty triggered this — a vague ticket, an unreviewed PR, an unfamiliar part of the codebase?
Separate signal from story. Is there real evidence of a skill gap here, or is this an information gap that anyone in your position would hit?
Reduce the feedback latency. Who can help close the uncertainty loop, and how quickly can you actually ask them?
Convert anxiety into action. What's the next smallest experiment or question that would move this from ambiguous to resolved?
None of these steps make the feeling vanish on contact. They just route it toward something a debugging mindset already knows how to do: investigate the input instead of accepting the alert at face value.
Conclusion: The Signal Was Never the Problem
The presence of performance anxiety among developers isn't a sign that engineers have gotten more fragile, or that today's teams are somehow less capable than the generation before them. It's a predictable outcome of an environment that generates an unusually high volume of unresolved ambiguity compared with more traditional engineering structures, delivered to people working in smaller units with less structural buffering than they used to have. The nervous system responding to that environment is doing exactly what it evolved to do. It's just applying an old survival mechanism to a workplace it wasn't built for.
Understanding impostor syndrome this way — as a response to environmental signal rather than a verdict on personal worth — doesn't dissolve the feeling on contact. But it does change what a developer does with it: name the actual trigger instead of the diffuse dread, treat the feeling as information to investigate rather than truth to absorb, and recognize that shortening the gap between uncertainty and resolution is a legitimate technical and psychological intervention, not a soft skill tacked onto the real work.
As engineering organizations continue experimenting with smaller, faster, more autonomous team structures, the psychological cost of that speed is likely to become a more explicit part of how teams are designed, not just how individuals cope. The next wave of tooling and process design in software engineering may end up looking less like project management and more like applied cognitive science — feedback loops, review norms, and team rituals built with an explicit understanding of how the human threat-detection system actually works. The code has been moving at machine speed for a while now. The interesting problem left to solve is how the humans writing it keep up without quietly convincing themselves they don't belong there.
Scientific Reference
Clance, P. R., & Imes, S. A. (1978). The impostor phenomenon in high achieving women: Dynamics and therapeutic intervention. Psychotherapy: Theory, Research & Practice, 15(3), 241–247.
Grupe, D. W., & Nitschke, J. B. (2013). Uncertainty and anticipation in anxiety: An integrated neurobiological and psychological perspective. Nature Reviews Neuroscience, 14(7), 488–501.
Hur, J., Smith, J. F., DeYoung, K. A., Anderson, A. S., Kuang, J., Kim, H. C., Tillman, R. M., Kuhn, M., Fox, A. S., & Shackman, A. J. (2020). Anxiety and the neurobiology of temporally uncertain threat anticipation. Journal of Neuroscience, 40(41), 7949–7964.
Lieberman, M. D., Eisenberger, N. I., Crockett, M. J., Tom, S. M., Pfeifer, J. H., & Way, B. M. (2007). Putting feelings into words: Affect labeling disrupts amygdala activity in response to affective stimuli. Psychological Science, 18(5), 421–428.
Edmondson, A. C. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383.
Edmondson, A. C. (2019). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
Duhigg, C. (2016, February 25). What Google learned from its quest to build the perfect team. The New York Times Magazine.
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
Top comments (0)