Tech has always evolved quickly. New frameworks, new architectural patterns, new flavors of Agile have always shown up faster than anyone could absorb. AI has cranked the pace up to a level that makes the old churn look slow. Coding assistants change every month, the patterns for using them keep shifting, and even what counts as “good” practice is up for debate (much less “best” practice).

Nobody is actually keeping up. The people who seem to be keeping up are usually just tracking one corner of it well.

That constant motion produces a particular feeling: the everyday version of Impostor Syndrome, the low-grade suspicion that everyone else is figuring something out that you aren’t, and it’s only a matter of time before they notice you’re behind. Senior engineers feel it. Founders feel it. The people who look the most put-together on LinkedIn quietly feel it too.

This hits harder at startups and small businesses. On a team of five engineers, you are visible all the time. The “rock star” is the person sitting next to you (figuratively or virtually) every single day. Their work is visible to you, and yours is visible to them. The comparison is constant, and Impostor Syndrome thrives in those conditions.

The antidote is still the same one I wrote about five years ago: ask questions, all of them. On a small team, a handful of question types pay back especially well, because they consistently teach you the most about how the product, the team, and the business actually work.

A few categories of questions that work especially well:

Why questions. “Why did we choose this database?” “What were we trying to solve when we built it this way?” These show you respect the path that got the product here, and they often surface context that nobody bothered to write down.

Tradeoff questions. “What did we give up to ship this on time?” “What happens to performance if we add that code?” “What tech debt did we incur by doing it this way?” Engineering is mostly choices, and asking about the choices positions you as someone who thinks like an engineer.

Outcome questions. “What problem does this actually solve for our customer?” “How will we know if it’s working?” These pull the conversation up a level and remind everyone that the code is in service of something, which is easy to forget when you are heads-down in it.

Mental-model questions. “If you were starting this from scratch, where would you begin?” “How do you decide when something is ready to ship?” These are golden because they ask experienced people for their thinking. You learn how they reason, and that turns out to be more useful than learning what they decided.

Pressure-test questions. “What am I missing here?” “What would break this?” “Is there a simpler version?” These show you’re not over-attached to your first attempt, which is one of the most senior things an engineer can demonstrate.

You don’t need all five every day. Pick the ones that fit the situation. What they have in common is that they treat not-knowing as a starting point for figuring something out together, instead of as evidence of inadequacy.

Engineering teams at startups and small businesses have a lot more freedom to choose the latest coding pattern, tool, AI agent strategy, etc. than larger organizations do. As I have written before, some of the pressure to adopt comes from a real engineering need, but much of it comes from the same Impostor Syndrome we’re talking about, the worry that everyone else is using something newer and getting more out of it. Again, ask questions: what problem this would actually solve for you, what you’d give up to switch, and how you’d know it was working. If the answers are vague, the trend probably isn’t worth chasing yet.

On a small team, asking questions is part of the job. The team is too small for anyone to be an expert on everything, and the AI landscape is changing too fast for anyone to pretend otherwise. The engineers who thrive in this environment got comfortable being curious in public a long time ago. They figured out that the team gets smarter by asking together, and that nobody is actually expected to have all the answers.