I've been managing engineering teams for a few jobs now, but I think this article suffers from some logical fallacies.
"You don't need stand-ups"
I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.
I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.
But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.
The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.
I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.
"You don't need stand-ups"
I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.
I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.
But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.
The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.
I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.