What to Do When You're the Least Experienced Person in the Room

The gap is real. You feel it in every meeting where someone references a system you’ve never touched, every design review where the questions people ask reveal a depth of understanding you don’t have yet. I’ve written before about why that feeling is actually a growth signal, not a deficiency. But accepting the reframe is only step one. You’re in the room now. The question is what you do next.

Here’s what I’ve learned from being the least experienced person in the room more times than I’d like to admit: the people around you are the single most important resource you have. Not documentation. Not courses. Not side projects. The actual humans sitting next to you who are better at this than you are.

That sounds obvious. It isn’t. Because when you feel outmatched, your instinct is to hide the gap. You nod along in meetings. You google terms after the fact instead of asking in the moment. You ask safe questions that make you sound informed rather than honest questions that would actually teach you something.

Stop doing that.

Engineers, in my experience, have an almost universal respect for genuine curiosity. Ask the real question. “I don’t understand how this system handles failover, can you walk me through it?” will earn you more respect than a week of pretending you already know. The person who asks that question learns something. The person who doesn’t, doesn’t. And everyone in the room can tell the difference.

When I moved from London to Facebook’s headquarters to support the Cache Infrastructure team, I went from supporting the memcache experts to being the person who didn’t fully understand TAO, the system my team was now responsible for. I was surrounded by engineers who’d built it. They knew every edge case, every design tradeoff, every reason a particular approach had been chosen or rejected. I didn’t.

The technical gap closed in about six months. Code has fast feedback loops. You read it, run it, break it, ask about it, and the understanding builds. But the leadership side of the transition, learning how decisions got made at HQ, how to read the org dynamics, how to influence people who’d been working together for years before I showed up, that took closer to a year. The opportunities to learn leadership only come at the cadence of meetings and organizational moments. You can’t speed-run them the way you can speed-run a codebase.

If you’re six months into a new role and you’ve got the technical side mostly figured out but still feel lost on the people and politics side, that’s normal. It’s not a sign you’re failing. It’s a sign that leadership skills have slower feedback loops than technical ones. Set your expectations accordingly.

Pay attention to the gap itself

The people around you aren’t just resources for answering questions. They’re a map of what you need to learn. Watch what they do that you can’t do yet. Listen to the questions they ask in design reviews, the ones that wouldn’t have occurred to you. Notice what they flag as risky that you would have overlooked. The distance between their instincts and yours is your actual curriculum.

You don’t need a course for this. You don’t need a reading list. You need to pay attention, deliberately, to the shape of what you don’t know. That shape changes over time. The things that confused you in month one won’t be the same things that confuse you in month four. Track it. A simple note at the end of each week, “what did I see someone do this week that I couldn’t have done?”, will teach you more about your own growth trajectory than any performance review.

And here’s something that’s easy to forget when you’re focused on your own gaps: you’re not a blank slate. Being the least experienced person in the room doesn’t mean you have nothing to offer. It means you have less experience on one specific axis. You almost certainly have more on another.

When I showed up at HQ not knowing TAO inside out, I didn’t suddenly forget everything I knew about memcache, about building engineering teams in new regions, about running infrastructure at scale from the other side of the Atlantic. That knowledge was still useful. My team needed it. Teaching what you know while learning what you don’t is how you stay useful during the transition period. It’s also how you build relationships with the people who are teaching you. Knowledge exchange beats one-way dependency every time.

This applies whether you’re at a five-person startup or a public company with tens of thousands of engineers. The scale changes. The dynamic doesn’t. If you joined a startup and the founding engineers have three years of context you lack, the same principles apply. Ask real questions. Watch what they do. Teach what you bring. Close the gap deliberately.

Recognizing when it’s time to move

There’s a moment, and it usually sneaks up on you, when the room stops feeling hard. You’re answering more questions than you’re asking. Meetings feel predictable. People come to you for the thing you used to struggle with. The problems you’re solving are ones you’ve seen before.

That’s the signal. Not that you’ve failed, but that you’ve succeeded. You’ve closed the gap. The room that used to stretch you doesn’t anymore.

When that happens, start looking for the next room. That might mean a new team, a new role, a new company, or just volunteering for the project that scares you. The specifics matter less than the principle: growth requires discomfort, and comfort is the sign that the current environment has given you what it can.

I’ve made this move multiple times. SRE to management. Management to production engineering. Production engineering to Product Management. Product management to TPM. Every transition came with a period of being the least experienced person in the room again. Every time, the same pattern played out: the technical piece clicked first, the leadership piece took longer, and the people around me were the reason I got through both.

The hardest part isn’t being in the room. It’s staying honest about where you actually are. Honest enough to ask the questions that expose your gaps. Honest enough to recognize when the gaps have closed. Honest enough to go find the next room that makes you uncomfortable.

If you’re not sure whether what you’re feeling is imposter syndrome or genuine unpreparedness, I wrote about how to tell the difference here. The short version: if you got the role, someone with context decided you belonged. Trust that, then get to work closing the gap.