The Loudest Voice in Standup Isn't the Most Effective
TL;DR: Verbose standup updaters get perceived as productive even when they're not. Quiet contributors get invisible even when they're shipping. Both are signal-handling problems, not personality problems. Use compression: control the peaks (long updaters), boost the quiet (silent contributors), and reserve standup time for blockers and shared awareness — not status that belongs in Slack.
You know the person.
Every standup, they give a five-minute monologue about what they're working on. They mention every PR, every Slack thread, every meeting they attended. They use words like "synergy" and "alignment" without irony. By the time they're done, everyone else rushes through their update because the meeting is already running long.
And somehow, this person often gets perceived as the most productive on the team.
Something's broken here. Let's talk about why, using a concept from audio engineering.
What does compression have to do with standup dynamics?
In music production, a compressor reduces the volume of loud sounds and boosts quiet ones. It narrows the dynamic range so that every element in the mix is audible — the quiet guitar part doesn't disappear behind the drums, and the drums don't blow out your speakers.
Without compression, you get a mix where the loud stuff drowns everything else out. With too much compression, everything sounds flat and lifeless — no dynamics, no energy.
Your standup has the same problem.
Why do verbose updaters get perceived as more productive?
In an uncompressed standup:
- The loud signals (verbose updaters, confident voices, people who love talking) take up all the bandwidth
- The quiet signals (introverts, new team members, people working on unglamorous-but-critical tasks) get buried
- The manager hears a distorted version of reality — whoever talks loudest appears most productive
This isn't just annoying. It's a career equity problem. The work that gets heard about is the work that gets rewarded. And if your standup format systematically amplifies certain voices, it systematically undervalues certain contributions.
What happens when teams over-correct with strict standup formats?
Some teams react by going the other direction: strict timers, rigid formats, "just say your three things and sit down."
That's over-compression. The dynamics are gone. Nobody shares anything meaningful because there's no room for it. The standup becomes a ritual everyone endures rather than a tool anyone uses.
You've killed the noise, but you've killed the signal too.
How do I find the right ratio for a useful standup?
Good compression (audio or social) keeps the signal intact while controlling the peaks. Here's what that looks like in a standup:
1. Lead with the blocker, not the activity
Instead of listing what you did yesterday (activity), lead with what might slow you or the team down (impact).
Uncompressed: "Yesterday I worked on the migration script, reviewed two PRs, had a meeting with the design team about the new dashboard, and started looking into the caching issue."
Compressed: "Migration script is on track. One thing to flag — the caching issue is bigger than we thought. Might need to sync with the data team. I'll drop details in Slack."
The second version is shorter, higher signal, and actionable. The first version is a resume.
2. Create space for quiet signals
If your standup format is "go around the room," the last few people will always rush because the first few people took too long. That's a structural problem, not a people problem.
Try this: async written updates for the status stuff (what you did, what you're doing). Use the synchronous standup time for blockers, requests for help, and things the whole team needs to hear.
This is like using a sidechain compressor — you're ducking the loud stuff automatically so the important stuff comes through.
3. Normalize saying "nothing to report"
One of the most powerful things you can say in a standup is: "Making progress, no blockers, nothing that needs the group's attention."
That's not laziness. That's signal clarity. It tells the team: everything's fine, don't worry about my lane, focus your attention where it's needed.
The loudest voice is often loud because they think silence equals invisibility. Creating a culture where brief updates are respected (not judged) fixes this at the root.
I'm the quiet one in standup — how do I get my work seen without becoming the monologue person?
Your work is invisible. And invisible work doesn't get promoted.
I'm not saying you need to become the monologue person. I'm saying you need to find the right output level — loud enough to be heard, controlled enough to be respected.
Practical tips:
- Once a week, share something you did that had impact beyond your own tickets. "Noticed the staging environment was flaky, fixed the Docker config. Should unblock the QA team."
- When you have a win, state it plainly. "Shipped the payment retry logic. Should reduce failed transactions by ~15%." Facts. Numbers if you have them. No false modesty.
- In design reviews, say one thing. Even if it's a question. Presence is participation.
This is gain staging for your career. You're adjusting your output level so the signal actually reaches the people who need to hear it.
What does a great standup actually feel like?
The whole point of a standup is to create shared awareness across the team. That's a mix — multiple tracks, balanced so you can hear everything.
When one person dominates, it's a solo. And solos get old fast.
The best standups I've been in felt like a well-produced track: every voice was audible, nothing was buried, and the whole thing was over in 12 minutes. No filler. All signal.
How can I recalibrate my standup voice this week?
Day 3 of the free Developer EQ Sprint workbook gives you a 10-minute exercise: pick the option that fits (quiet → share a real blocker; loud → strip your update to 2 sentences max), then run it in your next standup.
Communication dynamics like this — how to be heard without being loud, how to create space for others, how to read a room — are the core of Developer EQ — $20. Every chapter uses a music production concept to teach a social skill.
FAQ
Is my standup actually broken, or am I just impatient?
If your standup regularly runs over time, if quieter teammates rush at the end, or if you finish without knowing what's actually blocking the team — it's broken. A good standup leaves the team with shared awareness in under 15 minutes. Anything else is a signal-handling problem.
Should we just move standup to async-only?
Hybrid works best for most teams. Async written updates for status (what I did / what I'm doing) so nobody listens to 12 people read their Jira tickets. Synchronous time for blockers, dependencies, and anything that needs group attention. Maximum signal, minimum filler.
My manager runs the standup like a status meeting. How do I shift it?
Don't change the format unilaterally. Bring it up in a 1-on-1: "I think we could get more out of standup if we did status async and used the meeting for blockers — want me to try a 2-week experiment?" Frame as opt-in, owned by you. Most managers will say yes if it's low-cost.
As an introvert, do I have to perform extroversion in standup?
No — but you do have to make your output visible. There's a difference. You can speak twice a week (briefly, factually) and have huge career impact. You don't have to perform energy. You do have to be on the radar.
How do I handle the verbose teammate without making it personal?
Don't address them directly in standup; that's a private conversation. In standup, you can use structural fixes: a 60-second timer, written async updates, or asking the facilitator to call on people who haven't spoken. The structural fix beats the interpersonal one every time.
This is part of the Developer EQ series on social skills for engineers. Get the free 2-week workbook or the book — $20.
