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

51–60 of 102 posts

Re: How to build toxic software teams

#51

Post by seattle_spring »

pydry wrote: post #31
teeray wrote: post #2

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.

The non dysfunctional way to deal with this is to allocate between 20% of dev time to process improvements and vote on large scale changes.

Every place I’ve worked has had a “20% tech debt” time. Universally, it’s used as a reason to not fix technical debt as opposed to enabling engineers to fix long-standing problems. “Oh you need to re-write such and such? Well that’ll take 40% of your time for 3 weeks and the max time we can allocate is 20% so…”

Re: How to build toxic software teams

#52

Post by nineplay »

teeray wrote: post #2

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.

I have a feeling you're being sarcastic but this isn't terrible advice. I've seen a lot of dysfunction caused by that one engineer who constantly complains about the current code base and tell everyone how it should be done. If a tech lead can get them to quiet down and move on it will do the whole team a lot of good.

Re: How to build toxic software teams

#53

Post by seattle_spring »

alexachilles90 wrote: post #37

Let me add: 1) Always micromanage down to the lines of code changes. Have your reports depend so heavily on your next-steps that you maintain your influence on them to the point that nobody can make strategic decision when you are on vacation. 2) Encourage narcissistic, rude, and self-serving behaviors in the teams to the point that the other team members would think that there is no way ahead other than copying thes…

> Always micromanage down to the lines of code changes

I’ll never forget what one of my directors asked me to do a few years ago. I was a first-line eng manager with a handful of native mobile engineers. The Android guy had a better reputation for coding ability than the iOS guy, which was reflected in peer reviews come performance eval time.

Director received this feedback and instructed me to have iOS guy write his code exactly like the Android guy, down to function and var names, classes, logic, etc. No acknowledgement whatsoever that the 2 platforms use different languages, best practices, UI flows, etc., just: “Have him write the exact same code in his language and he’ll learn how to be a good engineer!”

Re: How to build toxic software teams

#54

Post by neilv »

superfrank wrote: post #30
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 too…

> If daily stand ups are a problem for your team, it's usually a symptom of a bigger problem, not a cause.

I'm sure that's true for some teams, but daily standups can also be a problem for teams that are functioning well.

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?

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)?

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?

Re: How to build toxic software teams

#55

Post by uncletaco »

ravenstine wrote: post #50

Always be in hiring mode, and be vocal about it so your employees know you're ready to replace them. Mention every day that you are interviewing someone, even if you really aren't. It's not like anyone is going to prove you didn't. In a similar vain, try to prevent your team from knowing when other members of your organization have quit or been let go. Also, do not announce in advance that a new person will be joinin…

Ah Martha, I see you haven’t changed one bit.

Re: How to build toxic software teams

#56

Post by Swizec »

bombela wrote: post #38
Swizec wrote: post #17

Earlier quoted context omitted.

My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so” Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well

Or they were actually asking for time to officially work on it. Thinking their superior must have a good view of the big picture. Waiting confirmation that their idea made sense in the grand scheme of things.

In that case giving them permission does the trick and the improvements happen. Huzzah!

The other side is making sure to always plan for enough slack in the system so people have time for these things, if they choose to use it.

Re: How to build toxic software teams

#57

Post by dudul »

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…

I would bet a lot that there is probably very little difference in outcome between hiring randomly and hiring with these complicated, disconnected, grueling interview processes that every company seems to be doing now.

Re: How to build toxic software teams

#58

Post by fruzz »

Retain rockstar programmers at all costs, even if they push everyone else to quit over being mistreated. Give them fancy job titles.

Have upper management crack sexist jokes, and HR laugh with them, so that women at the company who are sexually harassed know reporting it will do at best nothing, and at worst risk their own career.

Only hire young men in their twenties, and praise the idea of working long hours. Child care is for their wives to do.

Create artificial deadlines, that have no real-world repercussions for missing. But make it an urgency that must be done, instilling stress, and causing people to work long hours. Then after the deadline passes, note how it was unimportant, and repeat.

Have upper management make engineering decisions without accepting the input of engineers. Then when things blow up in a manner predicted by engineers, blame the engineers.

Pay new grads more than you do women engineers who have been at your company for years.

Have interviews that are focused on sports, and how much fun you would be at a party.

Praise the management style of Jeff Bezos and Elon Musk.

Re: How to build toxic software teams

#59

Post by [deleted] »

samtho wrote: post #19
refulgentis wrote: post #8

Earlier quoted context omitted.

Narcissist has become exponentially more abused over the past couple years. I've ended up leaving it for people who are attention-seeking, in common culture it is reduced to "people I have conflict with who I don't think care about other people", which has some irony, that's how a narcissist would perceive many interactions.

From Mayo Clinic: > Personality qualities include thinking very highly of oneself, needing admiration, believing others are inferior, and lacking empathy for others.

[deleted]

Re: How to build toxic software teams

#60

Post by Ensorceled »

> If something goes wrong, start an investigation. Figure out who to blame and do it publically. Raise your voice, send nasty emails, mean-mug without delay. Anytime there is a failure, don't miss an opportunity to assert your authority.

I've worked at a number of companies with this behaviour. What happens is most people in this situation just start keeping their head down and not doing anything at all unless specifically tasked by the leadership team. Things usually grind to a halt.

Post reply on HN