[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.

[theideaofcoffee]

I personally take an adversarial view on management because the large majority of the 'managers' I have had in the past were useless to the point of providing negative value, to both the technical and to the business side, so my views are colored by that fact. Not all of them of course, and they were the good ones. But most were just managers in name only.

A coasting employee may be a problem of the employee's making, but it is still a failure of management. If an employee isn't doing anything then you fire them. But it's still a failure of management because that wasn't fixed right away. And again, if someone doesn't know what they are doing (if that's truly the case why did you hire them, but that's another conversation), even async, a keen manager should be able to pick up on that and provide coaching, connections, or other resources--you know, actually 'manage' this person. Failing all that, then cut them loose. But it's still the manager's problem.

[marcinzm]

If they're coasting then you have a 1-on-1 conversation and if needed fire them. A manager who needs some type of public shamming ritual to do that isn't a good manager. There's a manager fallacy of focusing on minimizing the bad versus maximizing the good. In my experience, it's better to focus on making your best employees more effective versus trying to make your worst employees slightly less ineffective.