Meetings — The Arena
You're Probably Losing

Here is a scene that has played out in every engineering organization on earth. A meeting gets called to decide the architecture for a new system. Six engineers show up. The most technically correct engineer in the room — the one who read every paper, ran every benchmark, thought about it all weekend — says almost nothing. They answer when asked. They give a thumbs up or a thumbs down at the right moments. And the meeting ends with a decision that is… fine. Not wrong exactly. But not their idea. And they walk out feeling vaguely cheated, muttering that the best idea didn't win.

Meanwhile, one engineer in the room who talked for twelve minutes, drew two boxes on a whiteboard, and asked two well-chosen questions is now listed as the "decision driver" in the follow-up doc.

The technically correct engineer will tell you the meeting was political. They are half right. What actually happened is that meetings have two layers — the technical layer everyone can see, and the social layer most people never learn to read. One engineer was playing on both layers. The other was playing on one.

This chapter is about learning to play on both.

Why Engineers Lose in Meetings They Should Win

Let's be direct about why this happens. Engineers are trained to be right. The whole job, for years, is about correctness — your code compiles or it doesn't, the tests pass or they fail, the logic holds or it doesn't. You build a deep identity around being the person with the right answer.

Meetings don't reward being right. They reward being convincing. And convincing is a different skill that nobody explicitly teaches.

Here are the four patterns that kill technically strong engineers in meetings:

Pattern 1: The Data Dump

You have done the work. You have the spreadsheet, the benchmarks, the architecture diagram, the migration plan. You are ready. The meeting starts. And you proceed to share all of it, in order, starting from first principles.

You're still talking when you notice people checking their phones.

The problem is sequencing. You built the argument bottom-up — gathered evidence, formed a thesis, arrived at a conclusion. That's how good engineers think. But meetings require top-down delivery — conclusion first, evidence on demand. When you lead with data, you are making the audience do the synthesis work you already did. They don't want to do that work. They want to hear the answer and then decide whether to trust it.

The second version does the same intellectual work. But it respects the room's time, signals confidence, and — crucially — gives the audience agency. You've handed them a steering wheel. People who feel in control pay attention.

Pattern 2: Talking to Fill Space

There is a specific kind of engineer who speaks in every meeting. A lot. They rephrase what the previous person said. They think out loud at length. They summarize the summary. They ask a question, get an answer, and then ask a slightly different version of the same question.

This engineer believes that speaking is participating. It is not. Speaking is just making sounds. Participating means moving the meeting forward.

Here is a hard truth: in high-caliber orgs, the people who talk the most in meetings are rarely the ones others most want to promote. Verbosity signals two things — low signal-to-noise ratio and poor editing. Both are bad. Editing is a senior skill. The ability to say the one precise thing at the right moment, instead of the five approximate things that drift through your mind, is what separates the engineers others lean on from the engineers others tune out.

Pattern 3: Waiting for Permission to Have an Opinion

Some engineers come to meetings in receive mode. They are there to gather information, understand the situation, form an internal view — and then maybe share it if directly asked. They treat the meeting like a lecture they might have a question about at the end.

The problem is that meetings are not lectures. They are negotiations. And if you don't show up with a position, you're not at the negotiating table — you're furniture.

This pattern is especially common in engineers who are technically very humble. They don't want to be wrong in public. They wait until they're sure. But in meetings, certainty is a luxury that almost never arrives on time. The senior engineers in the room are not more certain than you are — they are just more comfortable stating a position before they're certain and updating it in public if new information emerges. That is called good judgment. And it is visible.

Pattern 4: Being Right at the Wrong Time

This one is subtle. The meeting has moved on — the group reached a consensus, the energy is wrapping up, someone is about to summarize. And then you speak up with a technically valid concern that reopens everything.

Maybe you're right. But you have just made everyone's morning longer and yourself the person who "derailed the meeting." Even if your point gets incorporated, you don't get credit for being right. You get a reputation for being difficult.

Timing is a form of intelligence. Knowing when the window for input has closed — and routing your valid concern to a Slack message afterward, a design doc comment, a one-on-one with the decision-maker — is a skill that looks like social grace but is actually strategic precision.

Before the Meeting: Where the Real Meeting Happens

This is the single most underused tool in engineering communication. The pre-meeting.

Most engineers show up to a meeting cold. The calendar invite arrived. They read the title. Maybe they skimmed the agenda. They show up and begin forming opinions in real time, which is approximately the worst time to form opinions. You're under social pressure, people are watching, the conversation is moving fast, and you haven't had time to think carefully about anything.

The engineers who consistently look sharp in meetings have done something you didn't see. The day before — or morning of — they had a five-minute conversation with one or two key stakeholders. Not to lobby. Just to calibrate.

Why does this work? Because when you understand where people already are, you can meet them there instead of trying to move them from somewhere else. The fastest path to alignment is not the most persuasive argument. It is the argument that accounts for what the other person already believes.

There's a deeper game here too. When you have that pre-meeting conversation, you have already begun building a coalition. The person you spoke with now feels that their input shaped your thinking. That means when you articulate your position in the meeting, it doesn't land as your idea that they're evaluating — it lands as a shared direction they helped form. They're not judging you. They're nodding.

Staff and Principal engineers do this constantly. It looks effortless from the outside — they walk into meetings and things seem to magically converge on their preferred direction. The magic is the work they did before they walked in.

Entering the Room with a Position

A position is not a conclusion you're attached to. It is a starting point with reasoning behind it. The difference matters because people can tell.

When you enter a meeting with a conclusion you're attached to, you look defensive when challenged. You deflect information that contradicts you. You argue longer than the evidence warrants. The room reads this as insecurity dressed up as conviction.

When you enter with a position you're willing to update, you look like a different kind of person entirely. Challenges strengthen your answer. New information improves your view. You can say "that's a good point, that changes my thinking" without it costing you anything — because your identity isn't fused to the outcome. This is what "intellectual confidence" actually looks like. Not certainty. Groundedness.

Write down your position before a significant meeting. Not the conclusion — the reasoning. "I think X because of A, B, and C. The main risk is D. I would update my view if E were true." That's a position. Now you can walk in ready to think, not just to defend.

The Precision of When to Speak

Speaking in meetings is a resource you spend. Spend it wisely.

Think of your credibility in a room as a bank account. Every time you speak something precise, insightful, or that moves things forward — you deposit. Every time you ramble, restate, hedge excessively, or say something obviously wrong — you withdraw. Most engineers don't track this account. They think of meetings as free — you talk or you don't, and it doesn't cost anything either way.

It costs a lot.

The engineers who are treated as the most credible voices in meetings are often not the ones who speak the most. They are the ones whose moments of speaking carry disproportionate weight. People lean in when they talk. The room gets slightly quieter. This is not charisma, though charisma helps. It is accumulated signal. They have trained the room to expect that when they open their mouth, it will be worth hearing.

You can build this. Deliberately. The method is simple and requires real discipline: in every meeting, identify the single most important thing you could say, and say only that. Don't say the second and third things. Let those go. The value of the first thing will be amplified by the absence of everything else.

How to Disagree Without Being Disagreeable

This is where most technically strong engineers lose the most ground. They are correct. And they are insufferable about it.

Here's what happens. A proposal goes up on the whiteboard. You immediately see three problems with it. You know the right answer. You correct the proposal, directly and completely, in front of the person who made it. You are right. The proposal is corrected. And the person who made the proposal now feels publicly diminished in front of their colleagues.

You think you helped. You actually lost an ally, maybe permanently.

Disagreement is not about being right. It is about being heard and integrated. The goal is not to correct the idea. The goal is to improve the outcome. Those two things often require completely different behaviors.

The key is to disagree with the problem, not the person. You do this by acknowledging what's right about the proposal before you say what's missing. This is not flattery. It is accuracy — almost no proposal is entirely wrong, and acknowledging the right parts demonstrates that you actually engaged with it.

Version B surfaces every concern Version A does. But it frames the concern as a shared problem to solve together — not as a verdict delivered by a superior judge. The person who made the proposal is now your collaborator, not your adversary. That matters after the meeting is over.

There's also a subtler technique: the question as disagreement. Instead of stating your objection, you ask a question you already know the answer to. "What happens to our p99 latency under this approach?" You know what happens. You want the room to arrive there themselves. When people reason their way to a problem, they own it. When you point out their problem for them, they're embarrassed by it — and sometimes that embarrassment becomes resistance.

The One Question That Makes You Look Senior in Every Meeting

There's a question that works in almost every meeting context. Before important decisions, during ambiguous discussions, when the room is going in circles — this question cuts through:

This question is powerful for reasons that aren't immediately obvious.

First, it reveals unspoken assumptions. Often, people in the same meeting have completely different definitions of success. Two engineers are arguing about implementation details when they actually disagree about the goal. Your question surfaces that disconnect before everyone spends two weeks building toward different targets.

Second, it reorients the room from tactics to outcomes. Most meetings get stuck at the tactical level — which library, which approach, which team owns what. The question pulls everyone up a level. Once the room agrees on what success looks like, tactical decisions often get much easier.

Third, it signals a specific kind of seniority — the seniority of someone who cares about outcomes, not just execution. Junior engineers worry about how to build the thing. Senior engineers worry about whether you're building the right thing. One question communicates which league you're in.

There are other questions in this category. They all work by the same mechanism — they move the room from where it is to where it needs to be, and they signal that you can see the gap:

• "What's the decision we need to make today, specifically?"
• "Who is the final decision-maker on this?"
• "What would have to be true for us to take the other approach?"
• "Are we solving for next quarter or next year? Those might have different answers."
• "What's the risk we're most worried about — and is our proposed approach the best way to address that specific risk?"

These questions don't require deep technical knowledge of the problem. They require situational intelligence — the ability to see what the group is missing and supply it. That intelligence is what Staff-level work looks like in practice.

Reading the Room in Real Time

Meetings have energy. Most engineers don't read it. They are watching the technical content of the meeting, which is one layer. The engineers who influence meetings are also watching the social content — who is engaged, who has mentally checked out, who is aligned, who is holding a dissent they haven't voiced yet.

Here is the most important unspoken signal in any meeting: the person who is quiet. Engineers who talk a lot are easy to read. The person sitting silently at the table — especially if they're usually engaged — is the one to watch. They either have a concern they haven't felt safe enough to raise, or they have already made a decision and stopped listening. Both cases are worth addressing.

You address them the same way: directly, with warmth. "Priya, you've been quiet — what are you thinking?" This is a small act with outsized effects. You have just given Priya a safe entry point into the conversation. If she had a concern, you've surfaced it before it becomes a blocker after the meeting. If she'd already mentally signed off, she now has the chance to confirm that — which closes the loop publicly.

Either way, you are the person who created clarity. That's the job description of every Staff+ engineer in the room, regardless of what the meeting is about.

The Exit — How to End a Meeting That Has an Outcome

Most meetings end badly. People start shuffling. Someone says "OK I think we're aligned?" in an upward inflection that is actually a question. Someone else says "great, I'll put together a doc." Nobody is sure what was decided. The follow-up Slack message arrives later with three conflicting summaries of the conversation.

The single best thing you can do in any meeting — regardless of your level — is end it with precision. Two minutes before the time is up, say:

That's it. You have just done four things that look small and are actually enormous: you named the decision, you explicitly parked the unresolved question, you assigned a clear next action, and you created a moment for anyone to correct the record if they heard something different.

Do this consistently and two things happen. One, your meetings stop generating follow-up confusion. Two, people start wanting you in their meetings, because meetings with you in them produce outcomes. That reputation becomes its own kind of leverage.

The Meetings You Should Be Running

So far this chapter has been about how to behave in meetings others control. But as you progress in seniority, the most important meetings are the ones you initiate.

Most engineers run meetings by instinct — they pick a time, invite people, talk through the problem, end when the time's up. The outcome is usually mediocre because the meeting was designed by accident. Good meetings are designed deliberately.

Three principles for meetings you run:

1. The outcome first, the agenda second. Before writing the invite, write one sentence that completes this thought: "This meeting will be a success if, at the end, the group has ___." Everything in the agenda should feed that sentence. If it doesn't, cut it or create a separate meeting.
2. Invite the minimum viable set. Every person you add past the necessary minimum increases the time to decision, increases the chance of tangents, and dilutes accountability. Senior engineers err toward smaller meetings. They know they can follow up with people who weren't in the room — but they can't undo the damage of twelve people arguing about something six of them don't have context for.
3. End early and call it. If the meeting reaches its outcome at minute 22 of a 60-minute block, end it. "I think we have what we need — let's give everyone 38 minutes back." You will become the most beloved person in the calendar. More importantly, you signal that you value people's time, which makes them value yours.

Async vs. Synchronous — Choosing the Right Arena

Before you schedule a meeting, ask a question most engineers never ask: should this be a meeting?

Meetings are expensive. One hour with five people is five hours of company time. Many decisions that currently use meetings would be better served by a well-written document. The design doc, the RFC, the written proposal with a comment deadline — these are not alternatives to meetings. They are better tools for many of the jobs meetings are currently doing badly.

The clearest framework:

• If the goal is sharing information that doesn't require discussion — it's a document, not a meeting
• If the goal is making a decision with low stakes or clear ownership — it's a Slack message with a deadline, not a meeting
• If the goal is alignment across people with different interests — it probably is a meeting
• If the goal is working through ambiguity together in real time — it definitely is a meeting
• If you're not sure what the goal is — figure that out first, then decide

The engineer who consistently chooses the right medium for the right communication type is doing something that appears to be operational hygiene but is actually strategic. They are spending the room's attention wisely. And attention is finite. Every unnecessary meeting you call is a small withdrawal from the account of goodwill people extend when you ask for their time.

The Hidden Game: What Meetings Say About You

Here's the part that nobody writes down in any handbook. Meetings are evaluations. Every meeting you attend is a low-stakes performance review. People above you in the org are constantly forming and updating their model of your judgment, your clarity, your emotional maturity, your range.

They notice how you behave when you're wrong. They notice whether you can hold two competing ideas at once without becoming anxious. They notice who you go to for information before you speak. They notice whether you help others feel smarter or smaller. They notice whether you have the social courage to say the uncomfortable thing that's obviously true but nobody wants to say.

None of this is on the agenda. All of it shapes your trajectory.

The engineers who become known as "great in meetings" are not performing. They have genuinely internalized the idea that communication is as technical a discipline as systems design. They have built specific skills, practiced specific habits, and made deliberate choices about how to show up in the room.

Those skills compound. The reputation you build in meeting rooms — as someone precise, thoughtful, senior in their bearing — filters into every other context. Your design docs get read more carefully. Your Slack messages get taken more seriously. Your concerns get more airtime at calibration. The meeting room is the highest-leverage arena for changing how the organization perceives you, because it's the arena where perception is formed in real time, in front of everyone.

You don't need to become a different person to win in meetings. You need to arrive with a position, speak precisely, listen more than you talk, disagree without damaging, end with clarity, and — most importantly — do ten minutes of work before the meeting that most people would never think to do.

Same room. Completely different game.