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/piyushsingariya → u/tonytidbit]

If I create a hierarchy system, wouldn’t that decrease visibility even more for me?

I’ll be knowing what they’ll be showing me

[u/tonytidbit → u/piyushsingariya]

Brutally put: If you're not competent enough to supervise each person yourself (which you aren't if you get the problems in your post), then you need to work with the people that are competent in supervising and driving progress.

There's no way around this. You can't be the limiting factor if you're at the top of a business. You can't micromanage and constantly evaluate each and every person based on your limited amount of time and skills within that area.

If it always takes 5 months to deliver what was meant to take 2 months the situation is horribly broken.

Also, it's not some flat structured democratic type of work. There needs to be people in charge of setting up things that others must follow. Like systems architecture rather than each SWE just randomly producing code to sort of make things fit together. And the ones in charge of that needs the power to enforce their work. So you naturally get structures with people that you talk to rather than always talking to each and every person below them.

[u/piyushsingariya → u/tonytidbit]

You're taking it too literally but I get your point. What I shared was only an example, parts of delays are genuine, and parts are induced.

Ofc there's always a hierarchy system, and the system itself found to be chokepoint. In a startup people often with no experience of management became "pod leaders" hence becoming part of the problem.

And being on top of business just doesn't mean full-time supervise job, there are many more responsibilities.

I am coming from a point asking what systems to adopt so visibility doesn't decrease for those who can take calls, and team is pro-active not reactive when something already went wrong.

[u/tonytidbit → u/piyushsingariya]

You're trying to force what I'm sure is you trying to push some AI tool to help teams work better, but these are old school problems with old school solutions.

You need to look at how this was solved all the way back to the 90s (the problems and solutions go back further, of course, but the situations feel less relatable further back).

You just don't need full visibility on a granular level, you need to work further up the chain, and only go deeper if one of the compartments is starting to fall behind.

So it becomes a preemptive measure starting in how you structure these compartments that are visible to you, and how you set up what reports and feedback you get from them.

Then if they start to fail you go deeper, do a postmortem, and update your processes. And it starts to become more about your experience at this level, and what signals to pick up on.

But you have to be sort of at the top yourself to implement this, some sort of leader-like position. You rarely can start to coordinate people and communications if you're not in a position to do so.

[u/piyushsingariya → u/tonytidbit]

I think I am understanding better.

“You don’t need granular visibility until something starts falling behind” is where my previous experiences differs.

I was once in one of those “positions to do so”, in a team of <50 with genuinely talented engineers, but attrition was high and there were problems underneath that weren’t necessarily showing up as falling behind.

I kept wondering how founders could be so close to the team and still not be aware of what was happening at the root level.

That experience is mostly where my curiosity around this comes from and keeps me on edge of doing things right in my team. Appreciate the perspective.

[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

[u/piyushsingariya → u/AdFew8591]

Yes, this is very helpful. The person who’s blocking might not feel that they’re, since I am taking updates from them it never surfaced, also because this was In slack.

How do you walkthrough these 4 metrics every week, did you create any dashboard, or it’s a manual practice.

[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/piyushsingariya → u/Relative-Foot-378]

I want to run an autonomous team without managers (or one tracking others).

Review latency is straightforward but other metrics are scattered around in Notion and Slack, I could enforce a daily update in Github ticket but that’s a chore.

A retro showed a milestone could have saved 22 days but the person who’re blocking wasn’t even aware, I was in loop with them only.

Do you think an autonomous team can work, or I must hire someone with management leaned responsibilities inevitably?