[88913527]

Leaders have a responsibility to ensure their teams deliver. When the teams agree to async communication --and the channels remain silent-- where is the accountability when there is no deliverable and no visibility into the scenario that led to no output? To be clear, this doesn't mean 100% sync. But a 10 minute daily sync can ensure the team is focused on producing something of business value. Maximal autonomy within some guardrails keeps the ICs and management at their best.

[marcinzm]

> Leaders have a responsibility to ensure their teams deliver. When the teams agree to async communication --and the channels remain silent-- where is the accountability when there is no deliverable and no visibility into the scenario that led to no output?

A good leader then talks to the team as the professional adults they are to understand why there isn't communication at the cadence that was agreed upon and discusses why such communication is important.

[theideaofcoffee]

If there's no deliverable and no visibility, that's a failure of management, either to define the deliverable to a more granular extent where an update could cover the progress, even if async, which would also fix not having visibility. A developer piping up async and saying 'no updates, still working' is still an update and gives visibility.

If they (managers) want to lord over the process and do work for work's sake, then they should write out requirements that say "thou shalt commit one line of code by X date". It just comes down to the individuals doing the 'management' being lazy if they're in this position expecting their 'reports' to drop everything and context switch to a meeting when they can't be arsed to do the managing.

[beezlebroxxxxxx]

> If there's no deliverable and no visibility, that's a failure of management, either to define the deliverable to a more granular extent where an update could cover the progress, even if async, which would also fix not having visibility. A developer piping up async and saying 'no updates, still working' is still an update and gives visibility.

That's really the bare minimum that a developer can say and still get away with when you have a lenient manager. HN tends to take the most adversarial take on managers possible, but it's not always necessary.

But, when you've worn both hats (manager and managed), sometimes employees simply don't want to do much work. Again, you can say "that's a management problem", but some people are bad actors and are very good at hiding it in "corporate speak". The internet is full of stories of coasting --- I can even attest to doing it many times and easily getting away with it. Getting someone in a room, or on camera, and actually running through their work can cut through a lot of bullshit and bullshitters. Some developers think "coding" takes precedence over the business -- but some of their "coding" time is completely useless to the business perspective. It seems crazy to insist that managers have no stake in trying to figure out if that's the case.

Sometimes you also need to have a meeting because in an async setting some people have no idea what they're doing. Even with clear goals and deliverables, stuff can easily fall through the cracks.