You've been coding for five, six, seven years. You got promoted to tech lead, or you're simply the most experienced person on a small remote team and architecture decisions started landing on your desk with no one reviewing them before they ship. And right there, when you should feel more confident than ever, comes the feeling that any minute now someone's going to notice you're winging it.
This goes beyond the generic version of imposter syndrome that gets explained away with 'acknowledge your achievements.' It's the specific anxiety that shows up when you go from executing someone else's decisions to being the one who makes them, without the safety net of a senior review.
Why the shift in seniority triggers it more than lack of experience
When you're junior or mid-level, every technical decision goes through at least one review: a PR someone senior approves, an architecture a tech lead signs off on, a design the team discusses before building it. That review, frustrating as it sometimes is, works as a safety net. If you get something wrong, someone's going to catch it before it hits production.
When you get promoted, or when you simply become the most experienced dev on a small remote team, that net disappears. You're now the last line of review. And your brain does something counterintuitive here: instead of feeling like you've gained authority, you feel like you've lost backup. The same ambiguity someone else used to resolve is now yours, and the absence of an external 'yeah, this is fine' gets read as evidence that you don't know what you're doing, when it's really just the logical consequence of having grown.
The trap of looking for validation where it no longer exists
The most common mistake at this stage is trying to recreate the validation you used to have: posting every architecture decision to a Slack channel asking for opinions, even when you've already made up your mind, just to feel like someone else signed off on it. Short term, it calms the anxiety. Medium term, it signals to your team, and to yourself, that you don't trust your own judgment, and it erodes exactly the authority you're trying to build.
The difference between asking for genuine feedback and seeking validation disguised as feedback is in the question you ask. 'What do you think of this approach?' when you've already decided and just want to hear a 'yes' is looking for validation. 'Do you see any risk I didn't consider in X or Y?' when you genuinely want someone to stress-test your reasoning is real feedback. The second one makes you better. The first one just makes you feel better for a while.
Documenting your reasoning is the antidote nobody recommends
What helps most at this stage, based on what we see in the senior developers we work with at Howdy, is pretty concrete and not abstract at all: writing down the reasoning behind every architecture decision before you implement it, in a short document, even if nobody asked for it.
It's for you: when you write down why you chose one option over another, which alternatives you ruled out, and which risks you knowingly accepted, you stop operating in the fuzzy territory of 'I hope this is fine' and move into the concrete territory of 'this is what I decided and why.' Six months later, when someone asks why the system is designed that way, you'll have the written answer instead of a vague memory of a hunch. That, over time, is what builds real confidence: the accumulated evidence that your judgment holds up over time.
The syndrome doesn't disappear, it changes shape
Nobody I know, not even devs with fifteen years of experience leading teams, has stopped feeling that pang of doubt before a big decision. What changes with experience is how fast you stop listening to it, not that the impostor feeling disappears entirely. The first time you make an architecture decision with no one reviewing it, the doubt can paralyze you for a whole day. With practice at documenting your reasoning and telling real feedback from disguised validation, that same doubt lasts fifteen minutes and then you get back to work.
