You're 26 with four years of experience, most of it doing one narrow thing well. Around the table: someone who commanded a platoon, a physician who has run an actual code, and a person who owned a $40M P&L and the headcount decisions that came with it. The team has landed on you to run the project.
The instinct is to treat this as a deficit to close—get smart fast, have a take on everything, earn the room. That instinct is what sinks people in your position. You were not asked to know the most. You were asked to make sure five people's work converges into one artifact by a date. Those are different jobs, and nearly everyone conflates them.
Process authority is a real job, and it's yours
Domain authority is knowing the answer. Process authority is owning the sequence—what gets decided, by whom, by when, and what happens to the work in between. The physician has more domain authority than you'll ever have in healthcare. She has no claim on when the integration session happens or what done means for the market sizing.
That isn't a consolation prize. On a ten-week project the failure mode is almost never a shortage of expertise. It's that the expertise arrived Sunday night in four incompatible formats with no time to reconcile it. Nobody else prevents that—each of them is deep in one piece, and you're the only one holding all of it.
The senior people know this better than you do. Someone who has run a P&L can feel a bad meeting starting within ninety seconds. They aren't evaluating whether you're the smartest person here—they know you're not, and mostly don't care. They're evaluating whether the two hours a week they hand you produce anything. Deliver that, and their experience becomes something you deploy rather than survive. It's the same job a product manager does with no authority over anyone.
Two failure modes, both of them insecurity
They look opposite. Same root, and both are visible from across the table.
Over-asserting. You manufacture a position on something you don't understand, because saying nothing feels like conceding the room. The tell is a confident claim with no second sentence behind it—ask what would change your mind and there's nothing there. Senior people catch it instantly, not because they're brilliant but because they've spent fifteen years watching junior people do it. The cost isn't embarrassment; it's that you spent credibility on a question you didn't care about, and it isn't there next week for the process decision that's genuinely yours.
Under-asserting. More common, more expensive. You defer on decisions that are process decisions—the internal deadline, whether to cut the third case, who owns integration—because deferring to experienced people feels like humility. It isn't read that way. It's read as the process being unowned, and unowned processes get filled in privately: four people running four reasonable schedules, none of them the same.
One test separates them. Do I have information this room doesn't? On content, usually not. On process, always—you're the only one tracking every workstream at once. Defer on content. Decide on process, out loud, with a date.
Say the gap out loud once, then never again
One sentence is worth spending, and it belongs in the kickoff. Plainly, without apology: I'm the least experienced person here by a decade. I'm running the process, not the analysis—tell me when I'm about to have us do something dumb.
That buys more credibility than anything else you'll say all term, because everyone already knew and was waiting to see whether you did. It's evidence of accurate self-assessment, which is the actual thing under evaluation.
Say it twice and it inverts. By the third time it isn't self-awareness, it's a request for reassurance the team now has to supply—and it pre-excuses failure, which senior people hear clearly. Worst is the apologetic preface bolted onto everything you say—I might be totally wrong here, but—the same admission on an installment plan, forever. Say it once, then behave like someone who wasn't worried about it. The first 48 hours of a new team is when it lands, and roughly the last moment it's cheap.
Make the expert legible to everyone else
The most valuable thing you can do in a meeting where someone knows more than you isn't to have the expertise. It's to make theirs legible to the other four.
When the physician says a hospital wouldn't buy this, she's compressing fifteen years into four words. To the room it sounds like an opinion, and opinions get debated by people holding none of the information. What she means is a mechanism. Your job is the question that unpacks it: what's the actual sequence—who signs, and where does this die?
That question costs you nothing and is worth more than the knowledge. A constraint that lived in one person's intuition now belongs to the team, and the expert has been made useful in public instead of overruled by a room that didn't follow her.
Watch for the moment an expert stops explaining because they assume everyone is with them. Interrupt there—back up, I don't think we all got that, and I want it in the deck. That's quality control on behalf of three people who were also lost and too senior to admit it. And when a senior teammate is confidently wrong, don't argue it—turn it into a test with an owner and a deadline.
Ask narrow questions, not open ones
What do you think? is a bad question to put to an experienced person. It gets a war story, a general principle, or a polite deferral. People answer at the altitude they're asked.
What do you think about our go-to-market? buys fifteen minutes about a company that isn't this one. You've sold into hospital systems—if our pilot has to close inside one quarter, who's the first person we have to convince, and what do they need to see? buys a usable answer in ninety seconds.
Hand them the constraint, not the topic. Constraints—one quarter, no budget, this audience—are what turn experience into a recommendation. The narrow question also proves you listened closely enough to know what their experience is good for, which reads better than any manufactured opinion.
When someone quietly ignores your process
At some point the person who's been running teams for fifteen years stops updating the board. Not hostile, not a statement. They have their own system, it works, and they've decided your Kanban is overhead.
First, check whether they're right. If the board exists because you saw one at your last job and this team is five people, it might be. Being the least experienced person means your process instincts are the least tested thing in the room—this is the one place to hold them loosely.
If it isn't overhead—if the board is how the other three know what's blocked—don't escalate and don't chase weekly. Chasing becomes nagging, and nagging from the junior person on a team of executives is where authority goes to die. Go once, in private, and frame it as the cost to a specific person rather than compliance with you: nobody could see your status, so Priya rebuilt half that section on Sunday assuming it wasn't coming. What would you actually use? That last question is load-bearing—someone who ignored one system will ignore its replacement too, unless they picked it. There are scripts for the harder versions of this conversation if it doesn't take.
If it still doesn't stick, stop spending on it. Update their line yourself after each check-in and put your leverage on what actually breaks projects: work arriving late, and done meaning two different things. Deadlines and definitions of done are load-bearing. Tooling is not.
What it looks like when it worked
The signal isn't a compliment. It's smaller and earlier. Around week four the physician starts sending her constraint before you ask, and the P&L guy asks when the integration session is instead of telling you. That's the room deciding the process is real and routing through it.
You will not out-experience these people, this term or ever. That was never the assignment. The assignment was to get five people's work to converge on a Thursday—and whoever does that is the one everyone remembers as having run the team. Which is exactly what you were afraid they wouldn't think.