Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to build toxic software teams

badsoftwareadvice.substack.com

Post reply on HN
Print view View original

21–30 of 102 posts

Re: How to build toxic software teams

#21

Post by hereforthecake2 »

Something a lot of people miss or don't understand: software engineers typically emulate other software engineers, not managers.

If you are tech lead you should be keeping this in mind at all times - your behavior, attitude, and approach to things gets amplified across team members.

If you are a manager you should also be keeping this in mind at all times - the values and behaviors want demonstrated on your team will need to be cultivated by key devs in your group. Working with them to help shape their understanding of how to be effective and how to lead others will really help things solidify in the group.

Re: How to build toxic software teams

#22

Post by jdlshore »

zenolove wrote: post #14
hack34news wrote: post #5

Hire some Product Managers. EOM.

Awww. As a product manager who hopes to be serving, encouraging and fostering his team well, this saddens me to read

I wouldn’t worry about it. HN is prone to these sorts of thoughtless dismissals.

Re: How to build toxic software teams

#23

Post by KerryJones »

I enjoy the sentiment of Charlie Munger of "invert, always invert" or "All I want to know is where I'm going to die, so I'll never go there."

I wish there was more to this list? There's so many more things that can go wrong, a short list: - Asking for input from the team, then ignore it - Gaslight engineers to thinking that other people think they are "bad at X" - Set out clear expectations, and then change them - Forget about previous conversations and insist they didn't happen

etc. etc.

Re: How to build toxic software teams

#24

Post by 3-cheese-sundae »

zenolove wrote: post #14
hack34news wrote: post #5

Hire some Product Managers. EOM.

Awww. As a product manager who hopes to be serving, encouraging and fostering his team well, this saddens me to read

I read that response in the inverse (that is, hiring product managers is a way to avoid building a toxic software team). Why? Because I'm on a team with no product manager, and we are expected to all service in that role, at least tangentially. Not ideal.

Re: How to build toxic software teams

#25

Post by sokoloff »

dangerwill wrote: post #7

I do wonder if people have any experience around doing root cause analysis that doesn't just end up in blame games? I've worked for three companies in a row that claim to have blame-free cultures, and all of them did put work into it (structuring the documents to not assign an individual's name to any given misstep and telling people to be kind and understanding). But in every case, you can feel it in the air that ev…

I think we ran an effective process to cover the RCA area of our operations. Importantly (IMO), we did go to lengths to understand and ascribe actions/activities that resulted in/contributed to an outage to a specific individual; we were just careful to not assign individual consequences to them. I think it's critically important to understand as precisely as possible what happened, who did it, what they were looking at that caused them to take that action, and which parts of that [if any] we'd change with the benefit of hindsight. I ran the Ops team at the time and it was easy for me to enforce the lack of consequences for anything short of an intentionally destructive act.

If "blameless post-mortem" means "we want to make sure that no one has any idea who was responsible", you can achieve that but you probably won't like the results.

If it instead means "we want to know why it happened, who contributed, and why, so that we can not repeat it", you have a fighting chance.

I've written and published multiple RCAs that explain in detail why /u/sokoloff caused an outage, when it started, when it was contained, and how to avoid that mistake in the future. I think that trying to obscure who did something is not only not worth the effort, but is actively destructive to the learning and trust.

If I can't trust that my name can appear next to an honest mistake, what else must I be distrustful of? If instead, I see respected, senior staff readily taking responsibility and sharing their mistakes without fear of consequences, I trust my company's leaders more, not less.

Re: How to build toxic software teams

#26

Post by temporallobe »

On a positive note, we just had a sprint retrospective today and the entire team gushed with praises for each other and we all agreed that team morale is great, and that we are accomplishing great things despite all the challenges we had been facing recently. I attribute this to a few things I’ve observed. First, we do have some extremely dedicated engineers who lead by example rather than granted authority. This garners huge respect for those members and makes everyone work that much harder so that they don’t disappoint anyone. Second, we have extremely positive non-technical members (PO, TL, SM) who are very encouraging, respectful, and willing to go to bat for anyone. Thus, we feel empowered and trusted. Third, we course correct, a lot. If there are problems and/or mistakes, we own up to them and focus on the solution. We face problems head-on instead engaging in finger-pointing and deflection. It’s honestly the best team I’ve ever worked with, and I will be sad when that has to end. I’ve worked on extremely toxic teams where all of the above what the exact opposite of what I just described and it usually ends in failure (through attrition, project realignment/cancellation, etc.). Oh, and the source of the toxicity is usually ONE person, but it spreads like a disease.

Re: How to build toxic software teams

#27

Post by chaosharmonic »

minorinscrum wrote: post #9

Do a daily stand-up Make sure to monitor your team every day and force their performance first thing in the morning. Focus on the daily grind to ensure meaningful change can never occur. Hire randomly Never put in the work to identify potential candidates based on their contribution to the industry or relevant projects. Always rely on blind applications to a job ad then make the applicants perform grueling and humili…

Pay quietly

Don't pay your staff consistently for the same work. Refuse to advertise your budgets, and loosen your "ranges" to get people in the door when they push you about it, but then use those same targets to hand-wave away people already inside -- who come to you after comparing notes or observing the impact of broader market conditions like inflation. Also, stop them from comparing notes or doing fifth-grade level math like compounding effects. That education is there to help you, not them - and speaking of which, it taught them better than to talk out of turn, let alone to question the people they work for.

(...satire aside though, you do know standups can be done in the afternoons, right?)

Re: How to build toxic software teams

#30

Post by superfrank »

minorinscrum wrote: post #9

Do a daily stand-up Make sure to monitor your team every day and force their performance first thing in the morning. Focus on the daily grind to ensure meaningful change can never occur. Hire randomly Never put in the work to identify potential candidates based on their contribution to the industry or relevant projects. Always rely on blind applications to a job ad then make the applicants perform grueling and humili…

> Do a daily stand-up

I absolutely disagree with this one. Both the best and worst teams I worked on as a developer both had daily stand ups and the frequency, length, and process was nearly identical. If daily stand ups are a problem for your team, it's usually a symptom of a bigger problem, not a cause.

I'm a manager now and I have multiple teams who report up to me. Personally, I hate daily stand ups so when I took over a new team last year, I floated the idea of switching them from 5 stand ups a week to 3 a week and they unanimously vetoed it. Of all the teams who report to me, they're actually the one that does the best work and are the most independent.

If you feel like your manager or PM is micromanaging, removing your daily stand up isn't going to fix that. They're just going to micromanage you though a different medium.

Post reply on HN