Many software teams have gotten smaller. Over the last several years, a large share of the industry has drifted away from heavily layered engineeri...
For further actions, you may consider blocking this person and/or reporting abuse
Thank you for this great article and including the "Scientific References"!
Appreciate you including the Scientific References!
This is one of the most precise, useful pieces I’ve read on impostor feelings in engineering.
Most writing on the topic still treats it like a personal confidence defect. This one correctly diagnoses it as a predictable nervous-system response to unresolved ambiguity — the exact condition modern small-team, high-autonomy environments are optimized to create. The “ambiguity threat” framing is excellent, and connecting it to the original Clance & Imes work and the uncertainty literature is spot-on.
What makes it especially strong is that it doesn’t stop at diagnosis. The error-log reframing, the affect-labeling research, and the concrete team practices (review language, senior “I don’t know,” short feedback loops) are immediately actionable. Treating self-doubt the way we already treat a stack trace is the kind of mental model that actually lands with developers.
Also appreciated the clear-eyed take on AI-assisted coding: the bottleneck has shifted from generation to judgment validation, which only increases the volume of ambiguity each person has to metabolize alone.
No pep talks, no “just believe in yourself.” Just accurate psychology applied to the actual working conditions of software teams right now. Outstanding.
This essay is an absolute masterclass in tech-workplace psychology! Framing impostor syndrome not as a personal failure of self-confidence, but as a predictable threat-response to unresolved ambiguity inside hyper-flattened, autonomous squads is a profound reframe. Sollis bridges Clance's research, neurobiology, and team topologies so seamlessly. Exceptional, deeply grounding writing, Khali!
This was a genuinely useful reframe. Treating impostor feelings as a response to unresolved ambiguity rather than a verdict on skill makes the whole experience feel more investigable and less personal. The "read the error log, don't internalize it" idea stood out, especially the point that naming the specific trigger does most of the regulatory work. I also appreciated the section on shortening PR feedback loops, since a review sitting untouched for two days really can feel like a silent judgment. Noting how AI-assisted development makes "can I tell whether this is correct?" a daily question was a sharp and timely addition. Thank you for turning the research into something developers can actually use.
Really like the idea of treating impostor feelings as an error log rather than a personal verdict. In fast-moving engineering teams, uncertainty is inevitable, but the way teams handle it makes all the difference. Psychological safety, timely feedback, and leaders being comfortable saying “I don’t know” can turn self-doubt into an opportunity to learn instead of a source of anxiety. Great reminder that building better software also means building environments where people feel safe enough to ask questions, challenge assumptions, and grow. 👏
Thanks for this, Khali. Reframing impostor feelings as the nervous system responding to unresolved ambiguity, rather than a verdict on skill, was the most useful idea for me, and treating self-doubt like an error log to investigate instead of a truth to absorb makes it easy to act on. The point that a PR sitting unreviewed for two days extends the window with no "all clear" signal stuck with me, since it turns a psychological problem into a concrete workflow fix. I also appreciated that you were clear psychological safety isn't niceness, and that visible disagreement can be a sign it's working. The added angle on AI-assisted development, where validating generated code becomes its own source of ambiguity, felt especially timely. Thoughtful, practical piece.
This is an outstanding and exceptionally well-framed exploration of impostor feelings, psychological safety, and the hidden cognitive cost of modern software engineering. What makes this piece so compelling is that it doesn’t fall into the usual “just believe in yourself” treatment of impostor syndrome; instead, it asks a much more interesting question: what happens when highly autonomous teams systematically remove the layers of redundancy that once distributed not only work, but anxiety? The idea that traditional team scaffolding was “distributing anxiety” is brilliant, and it immediately reframes why smaller, faster teams can feel psychologically heavier even when they are operationally more efficient. I especially loved the “ambiguity threat” concept—the explanation that an unclear ticket, shifting specification, unfamiliar codebase, or silent PR can keep the brain’s threat-detection system humming because uncertainty itself is difficult to resolve. The connection to AI-assisted development is particularly timely as well: when code can be generated faster than confidence can be built in understanding it, the bottleneck shifts from producing output to validating judgment. That is a remarkably important observation for the current engineering landscape. The “error log” metaphor is another absolute standout. Teaching developers to treat self-doubt the way they treat a system error—investigate the input, identify the failure condition, distinguish signal from story, and take the next useful action—is an incredibly elegant bridge between technical thinking and emotional regulation. I also appreciated the article’s insistence on accuracy rather than forced positivity: sometimes the answer really is “I need to learn this,” and recognizing a genuine skill gap without turning it into a judgment about personal worth is exactly the kind of mature reframing developers need. The psychological-safety section is equally strong, particularly the distinction between safety and niceness. A psychologically safe team isn’t one where nobody disagrees; it’s one where people can say “I don’t know,” “I’m stuck,” or “I think this is wrong” without fearing that those admissions will be treated as evidence of incompetence. The examples around code-review language and shortening feedback loops make the research immediately practical rather than merely theoretical. And the idea that a senior engineer openly saying “I’m not sure” can recalibrate what competence is allowed to look like for everyone else is such a powerful leadership insight. The developer debugging checklist is a fantastic payoff because it turns the entire argument into something actionable: identify the input, separate signal from story, reduce feedback latency, and convert anxiety into action. But the closing reframe is what really elevates this article: “The signal was never the problem.” That captures the heart of the piece beautifully. The nervous system isn’t failing; it is responding to an environment full of unresolved ambiguity. The real opportunity is to design teams, workflows, feedback loops, and cultures that help humans process that ambiguity without internalizing it as proof that they don’t belong. Smart, nuanced, highly relevant, and unusually thoughtful, this is the kind of engineering article that manages to connect neuroscience, organizational psychology, leadership, and everyday developer experience without losing the reader. An exceptional piece—and an especially valuable one for anyone building or leading small, autonomous engineering teams.
Thank you for including the sources for further reading Khali, you're amazing!
Brilliant writing Khali thank you so much!
A-M-A-Z-I-N-G essay Khali thank you so much for your research!!!
Absolutely brilliant! The connection between neuroscience, impostor feelings, and psychological safety transforms a deeply personal struggle into a powerful opportunity for better engineering cultures. I especially love the idea of debugging self-doubt instead of internalizing it—a practical, compassionate, and genuinely empowering perspective. Outstanding work!