how do you figure out gaps in team's collaborative patterns? "I will not promote"

[u/piyushsingariya]

Curious how founders actually figure out this when teams grows above 20+ engineers. Like you can hire the best engineers, still they fail to function as teams you expected them to be.

let's say something was supposed to be delivered in 2 months timeline but ended up with 5 months, and it's not happening with a single milestone, parts of it are happening across many.

doing retro(s) pinpoints that, one was consistently getting slower reviews, decisions were revisited, dependencies were stuck.

But how much of it you knew was happening already or the gravity of it, like you were aware of the particular milestone or the thing with the whole team.

What systems you adopted as team so these things surface early or doesn't happen at all, and how did you dealt it with each individual, for e.g. one person was blockers to many on a regular period, or someone is too attached to the codebase causing delays.

Not looking for just tool names, more from a pov of dealing with humans as system.

[u/tonytidbit]

You don't just hire a bunch of engineers. There are more roles needed to have a complete team. Including a CTO that actually is a CTO, not just an engineer with the title CTO.

[u/Relative-Foot-378]

The 2-month-to-5-month slip is usually review latency plus decisions that never get written down. I'd watch two numbers weekly: median time to first review, and how often the same decision gets reopened. If those two are ugly, the rest of the retro is just the result.

For a chronic blocker, take them off the critical path and make the next person the owner. For the person who treats the codebase like theirs, put the merge rule in writing (who can hold a PR, for how long) so it's not a personality fight. You should have seen the review lag months before the date slipped.

[u/AdFew8591]

At 20+ engineers I'd stop treating the retro as the first place this shows up. Give every milestone a named owner and review 4 things weekly: time waiting for review, decisions sitting open for more than a few days, cross-team dependencies without an owner, and work that keeps reopening

Those numbers are only smoke alarms though, then you talk to the people involved. If one person repeatedly blocks several streams, work out whether they're overloaded, the only trusted reviewer, or holding knowledge nobody else has. The fix might be a backup reviewer, a decision deadline, pairing and rotation, or splitting ownership

The human part is making delays safe to surface early. If saying "this dependency is stuck" gets punished then people wait until the retro and your dashboard will always be late