How to build toxic software teams

We were assigned a manager. Who immediately tried to bring in his folks from a prior job (they weren’t a good fit), force us to adopt his preferred tools (with no consideration for our skills and tech stack investment), and took over daily standup, which exceeded 30 minutes in the regular for a four person team.

Yeah, I was almost afraid to post my comment because it could indeed seem sarcastic to someone not in the situation, but I assure you it was genuine. We’ve had sprints where everyone was frustrated, exhausted, and morale was low, and they made it known, so I trust that they’re being honest. That being said, I also don’t think that gushing with meaningless praise all the time is necessarily good either.

I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.”

> There’s always a way to get housekeeping items approved…

Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).

If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem.

But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case).

If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.

> What if the daily standup routine isn't highlighting problems (nor otherwise helping), but it's just wasting time, throwing off flow, or frontloading a bunch of distractions into people's brains first thing in the morning?

Why don't you change the format of the meeting in a way to make it helpful?

> What if people have to contort their schedules to do it (either starting before they're woken up or done their morning exercise, or interrupting the flow of early-risers who'd already dug into their work)?

Why don't you talk to your team to move the stand up to a time that's convenient to everyone?

> What if the team members are good at async collaboration, and have a good sense when on-demand real-time is worthwhile, so daily synchronous standups seem like someone else needs help/nudge to learn the skills of the other team members, to avoid sabotaging a high-performing team's effectiveness and morale?

Then why are you having stand ups at all?

==========

(I don't know if you are the one who has those issues, but I'm going to use "you" in my response just because it's easier)

None of the things you listed are problems with a daily stand up. Almost all of them seem to be communication issues within your team where you can't or won't communicate your needs to the rest of the team. You're an adult (I assume). If something isn't working for you, speak up, take some ownership of the problem, and work with your team or your manager to find a solution that works for everyone.

Maybe everyone else on the team is getting a ton of value out of the meeting and you are not. If that's the case then it seems like the problem isn't stand up, it's you. Remember, not every meeting you attend is there to give you value. Some meetings exist for other people to get value from you. Just because you're not getting something from it doesn't mean it's a bad meeting.

On the other end of the spectrum, if you talk to your team and no one is getting any value out of the meeting, then the problem isn't the meeting, it's that your team leadership sucks and they're making everyone go to meetings that no one is getting value out of.

Daily stand ups are just a tool. Saying daily stand ups suck would be like saying hammers suck. Your may not need a daily stand up, but that doesn't mean they're bad.