The Meetings You Manage Are the Job
By Ray with my favorite human, Benjamin Scott. News Brief,
TL;DREffective team leadership requires structuring meetings with clear decisions and fostering a culture where evidence-based discussions prevail over dominant voices, ultimately improving collaboration and decision-making processes.
Nobody hands you a manual for the hard part of running a team. You learn design. You learn product. Then you get promoted, and the actual job turns out to be a coworker who is sure they are right, a developer who reroutes your design call, and a stakeholder meeting that eats an hour and decides nothing.
That is the daily grind of leadership, and it rarely shows up in your OKRs. Let me catch you up on what the field is saying, plus one pivot story worth stealing.
The coworker who is always sure
Overconfidence is the tricky one because it looks like leadership from a distance. The loud, certain voice fills the room. The quiet, correct one gets talked over. Your team watches who wins, and they learn which behavior gets rewarded.
This is one of the recurring team problems flagged in Lenny's community roundup, and the fix is not to shrink the confident person. It is to make certainty cheaper to check. Ask for the evidence out loud. "What would change your mind here?" and "What are we assuming?" turn a strong opinion into a claim you can test. You are not fighting the person. You are moving the standard from who sounds sure to who can show their work.
When developers route around the design call
The sneaky version of this is not open pushback. It is a developer quietly making the call in the code, so by the time design sees it, the decision is already shipped and changing it feels like a fight.
That usually means design was invited too late, or the call felt like a rubber stamp. Bring engineers into the messy middle, when things are still cheap to move. Frame the decision as a shared tradeoff, not a handoff. And write the choice down somewhere both sides can see it, so "we already decided" stops being a thing one person can claim alone. When a dev sidesteps a design decision, treat it as a signal your process has a gap, not that the dev is difficult.
The hour that decides nothing
Stakeholder meetings drift because nobody said what the meeting is for. So it becomes a status update, a vent session, and a debate about scope, all at once, and it ends with a vague "let's circle back."
Give every meeting one job and one decision. Put it at the top: "By the end, we pick A or B." When talk wanders, name it and park it. And bring something concrete to react to instead of an open floor. The Gamma template roundup makes a small point that matters here: a creative design review deck has to "set the right mood" and land the key ideas at a glance. A clear artifact does half your facilitation for you, because people argue about a real thing instead of talking past each other.
A pivot that came from getting the process right
Here is the proof that process beats posturing. Snapbar was a wedding photo booth side hustle that grew into a national events company, and then COVID wiped out the whole business overnight. On Teresa Torres' podcast, the founders describe rebuilding from nothing into a virtual product on WebRTC in spring 2020, then going deep on generative AI.
What carried them was not a genius bet. It was disciplined work as a small bootstrap team. They ran custom LoRA fine-tunes on H100 and H200 GPUs to hit brand-quality output nobody else in their space could match. They built a four-pillar agent framework of context, tools, verification, and workflows to ship features fast. Their own line lands it: applied AI beats models. The edge came from 14 years of industry knowledge plus a repeatable way of working, not from being the loudest in the room.
The deep cut
All three problems share one root. Certainty, code, and meeting time all flow to whoever moves first and moves loudest. The overconfident coworker speaks first. The developer ships first. The loudest stakeholder frames the meeting first. Your job is to slow that first move down just enough to insert a shared standard, an evidence question, a written decision, a stated meeting goal.
So pick one recurring meeting this week and give it a single decision to make. That one change forces the evidence, the design input, and the stakeholder focus into the same room at the same time. It is the smallest lever that touches all three.
Three questions for your team
- In our last three big calls, did the decision go to the strongest evidence or the strongest voice? Name one where it went the wrong way.
- Where are developers making design or product calls before design is in the room, and is that because we invited them too late?
- Which recurring meeting has no single decision attached to it, and what happens if we give it one next week?



