How to build toxic software teams
badsoftwareadvice.substack.com
badsoftwareadvice.substack.com
He was right, his department was great to work in. No recrimination for honest fuck ups (I took down a national banks ATMs for a few hours once).
It was a great place to work and everyone was better / more productive because of it. People were positive, honest, and adults!
Years later we joined a larger company. They acquired another company who had 3x the people doing half the work…. They were all about blame and recrimination. Their productivity was absolutely related to their culture. They were so follow the process / afraid of getting blamed (and people got blamed for no reason) that they were terrible / found the worst ways to work.
Lol, you should add that this is a sarcasm.
Always make sure you sow doubt and confusion in your employees. Make sure they question their own lived experiences and wonder if there is something inherently wrong with them. If they seek out advice and feedback from you about their work make sure you respond with vague suggestions, not based on reality and facts, and make sure it's about a character flaw you see in them. Never use examples or facts to back up your claims and never give direct advice about how to address the issue. They will soon wonder what it is they have done to become so flawed that no amount of therapy will ever undo the damage you have wrought. Do this to enough employees and watch as egos and careers are laid to waste.
Make sure everyone works alone and never talks to one another. If someone asks for advice it's because they're not competent enough to have known the answer. Make sure they know that is why they're not being promoted. Don't let them talk or share ideas. It's a waste of time. Workers who are isolated and silenced are easier to manipulate, learn to feel helpless, and depend on you to tell them what to do.
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!”
With the industry wide layoffs this feeling has only gotten worse now that there is a decent chance that accepting blame (or your manager deciding the blame is on you) will be the difference between having a job or not in 6 months.
Maybe this is unavoidable given that these processes only kick in when something goes wrong, and you can only screw up at your job so much until you get shown the door?
This is how I prefer it too, but the problem is that honesty is a luxury when times are good. When times aren't so good, having a self-documented history of failure doesn't help your case for retention when the jerk next to you who deflects everything appears to be a golden boy.
> I'm not sure hiding it would be helpful, but I haven't tried that.
From the police playbook: after raising awareness of a problem, proactively make excuses for other teams and/or deflect blame to a vendor ("we don't know it's that team's fault; they're understaffed and we don't know what they're having to deal with over there; give them a break because nobody can understand the vendor's fucking incoherent documentation and their software is garbage anyway"). Confusing the issues and misdirecting blame gives the team time to address the problem while saving face. Everybody hates Microsoft anyway so they're an easy scapegoat. (Sorry, Microsoft employees.)
For better or worse, it fosters a culture where people cover for each other, not throw each other under the bus. This is how you wrangle even the most toxic Narcissists-- they recognize and appreciate when someone's doing them a public favor, and (IME) this compels them to respond in kind because they'll want to one-up you as everyone's savior. (We're starting to see this with all the moral crusading and self-appointed "safety" workers. All Narcissists.)
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.
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 humiliating coding tests until they've successfully demonstrated their pain tolerance and allegiance.
RTO
Make your developers as uncomfortable as possible and force them to move to the most expensive real-estate market possible. It's important to remind individual contributors of their position on the social hierarchy. Home ownership and starting a family is for execs only.
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?)
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.
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?
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.
Social bonds are built through repeated casual social interactions. Standups are a mechanism for building social bonds within the team by creating an environment where they take place.
If you think that standups are about status updates or resolving blockers than you're being led astray.
> Never put in the work to identify potential candidates based on their contribution to the industry or relevant projects.
Corollary: Never promote internally
If there is someone on the team interested in and capable of stepping up to become a team lead or manager, ignore him or her, and instead hire someone externally for the leadership role. Bonus: Always use the excuse "Gosh, we can't find any good internal candidates, so we grudgingly need to look outside the company for leaders!"
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.
Tolstoy was right. There are infinitely many ways for a team to be toxic and only one way for them to be happy.
A shared sense of a common goal, knowing how each member uniquely contributes to that goal, and a common respect for the value of those contributions. Deviate from that and you get in trouble.
My team went through a lot of instability. We lost 2 devs, a manager, a director, and a VP in 2 months. We were the only 4 software engineers working on the product.
The company worked according to milestones. Every month we'd need to meet some arbitrary feature set. We were planning to launch every month for 9 months straight. That's right, the entire 800 person company was aiming to launch in less than 30 ways for 9 months.
Our product was shit. It was rushed and messy. After we hired a new director and hired more devs those original 4 people (including me) got yelled at, blamed for the bad product, and pushed out of the company.
---
In 2020 I briefly worked for a small company. I should have said no, but due to life circumstances, I was uncomfortable passing on the job.
When I joined, there were security problems all over the place. They were self-hosting a Mercurial server with http, not https. I eventually brought up the issue with the (cough) tech lead. (I should point out that the lead had been the lead since graduating college, for a decade, and generally had little to no mentorship in the process.)
First, I asked why they were self-hosting their Mercurial server. I got back a wishy-washy "that's how we're used to doing it" answer.
Next, I subtly pointed out, "You know, if you were using Bitbucket to host source code, you wouldn't have this issue."
The response was, "Oh, don't you remember, Bitbucket dropped Mercurial years ago."
My next response was, "Uhm, then do you think we should switch to git?" (For context, I used to like Mercurial better than git, but years ago moved everything to git when I started using git at a prior job and saw "the writing on the wall.")
The (cough) tech lead then went on a tirade about how we just couldn't switch to git, because he didn't want to have to handhold everyone in figuring out git, and then arguing about minutiae regarding minor differences between the two.
I tried to reason with him in pointing out how, if you build a business around a technology, and that technology loses in the marketplace, you put your business at risk. I mentioned that a business that used Betamax would have needed to switch to VHS once it became clear that Sony was discontinuing it and VHS was winning in the marketplace.
A few weeks later, the (cough) lead mentioned at standup that he was having trouble getting his medication, and acted like he was going through stimulant withdrawal. He never acted like someone with ADD or ADHD off of their meds, though. At that point I put two-and-two together and realized that his behavior was textbook "too many stimulants."
Shortly before my time with this company ended, they very nervously announced they were switching to git. I watched everyone on the team, except the leadership, breath a sigh of relief.
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.
I think it's easy-ish to get promoted to Senior based on your personality and inclinations that lend themselves to being a "natural" role model; moderate deficiencies can easily be glossed over as long as there's enough compensatory strengths, and you aren't expected to be perfect. But once you start to become a role model - formal or informal - you gain a new job responsibility: consistently demonstrate the culture of professionalism and courtesy the company wishes to inculcate. Because your actions will be emulated, for better or worse.
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.
Double points if you tie this to financial reward like bonuses.
Ask your direct report to do all of the prep work for a critical project that they are most qualified to run and oversee, ask them to share the pre-reads with a decision making group, invite them to the kick-off meeting, tell them five minutes before the meeting starts not to say a word during the meeting, or else.
Show up 20 minutes late to a 30 minute meeting, then spend the next 20 minute talking at the group, allow for no interruptions, keep everyone over time.
They don't care why you want to be miserable, ("Perhaps you thought of spraying Black Flag on your father's Cheerios."), they just tell you how.
Later when the deadlines slide by a mere 2 weeks, blame the engineer saying that the time given to them was "generous".
Use performance ratings as a tool to set them up for failure, but only after getting the guarantee of a backfill headcount.
This ensures job security for the in-crowd who already knows the code base, and ensures only super-geniuses can later join their ranks.
Also, if someone contributes tests, never run them yourself.
Bonus points for making changes in other peoples' code without even running it locally before committing and pushing up.
I've become more or less convinced that having a positive environment takes a lot of work and it's easy to go wrong - regardless of whether someone is being a bit malicious, or just makes it worse unknowingly.
If somebody just improved all future deadlines at the expense of a delay in one, isn't it great? (Yeah, there are a few times when it isn't; but if those are not few enough to be clearly communicated, your management is a bunch of dummies.)
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
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.
To most people they're just asking for a quick 10 minutes of your time, what's the big deal. But they don't see the other 20 people doing the same thing. If you devote 200min+ of every day to fulfilling others' requests, when will you have time to do your own work?
The problem grows only worse the higher in the org chart (formal or informal) you get.
Someone like a VPofEng may have 100 people asking "quick questions" all the time. Without the Wally Deflector, there's literally not enough time in the day to even have all these conversations, let alone do anything about 'em.
Over time, they'll become some of your favorite object lessons about employee engagement!
This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the better, as this guy is no longer my manager. For the record, my super-great-idea was upgrading some 5+ year old software that was giving us and the devs a lot of headaches. I was told it could not be done, and it would be replaced by The Next Great Thing, which would take 6-8 months of engineering. I upgraded the thing in a day (in dev) just to prove that it could be done. Despite praises from my teammates (and devs) I had undermined The Manager. Although I know he wanted to, he could not berate or yell or force me to rollback —- imagine telling dev we are rolling back to a five year old version. In any case, ten years in and I’ve learned that the manager is a hard cap on the productivity of a team. The most productive team I’ve been on did not have a manager. We didn’t need a JIRA board or a roadmap or someone to help us plan or prioritize. We simply got our work done. Imagine that.
> 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).
I feel your pain then.
Well what happened? Why did you leave? It sounds great!
How did you prioritise?
Ive been in the weird scenario of not having a real manager a couple times. One time it was how you described. Another was pretty bad, we basically became the dumping ground for unwanted projects and tedious work because we didn't have authority to say no.
I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.
Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.
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.
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 joining your team. Remember, you want to keep your team in a constant state of disorientation.
Make sure to have at least one subordinate with authority over the rest of your team who can be the "good cop" to your "bad cop".
Use burndown charts as a way to measure individual performance, and immediately point out a team member is "falling behind" when their velocity is even a smidge less than it was the last sprint.
Turn your daily standups into status updates that only you are allowed to be the master of. Discourage your developers from self-organizing and performing standups on their own when you're late or not around. If your developers take the initiative to give you notes on the standup you were away from, display a lukewarm demeanor that tells them that their notes will never be read.
Speak as if your team is in competition with other groups in your company. After all, why should they be collaborating when they should be working?
Frequently ask your team whether they know about some new and/or obscure tech they problably haven't heard of before. Even better if the tech is made up! Your team members must feel intellectually inferior to you at all times.
Randomly pull aside individual developers on your team and give them a pop quiz on how one of their fellow team members is doing. The point of this is not to learn anything about the other developer, but to sow distrust and subtly communicate that you know everything that's going on.
(^^ Yes, that's based on something I actually experienced)
If one of your devs writes some code that you don't like, subvert the team's code review process by insisting they have a one-on-one meeting with only you. If any of the other devs like the code you don't like, you definitely don't want them around to defend them. This is your team, so take full control of it!
When a developer implements something in a way that you don't like, compare it to some nebulous standards, guidelines, or systems that don't actually exist anywhere on paper. For example, you can say that the new UI feature "simply doesn't align with our design philosophy." That philosophy doesn't have to exist because, hey, you're in meetings all the time, so what difference is it to you? Make sure that it never exists because otherwise it can be used against you. The point is to look like you're the only person who truly knows anything for sure while disarming any arguments that will waste your time.
its really the little things of being professional
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.
> Personality qualities include thinking very highly of oneself, needing admiration, believing others are inferior, and lacking empathy for others.
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.
Men aren't impervious to sexism either.
>Only hire young men in their twenties, and praise the idea of working long hours
Young women are working ridiculous hours as well.
>Child care is for their wives to do.
What child care, most of the highly educated aren't having kids to begin with. (Exaggerating, but it's not the big deal given what most career couples in their 30s make.)
>Pay new grads more than you do women engineers
That's universal as well, not specific to women only. Several companies are overcorrecting by overpaying younger women compared to both the older cohort and their male cohort, too.
Men aren't impervious to sexual harassment, that's true. But in my career women have been overwhelmingly on the receiving end. I've seen a woman not be hired by a male interviewer because she was "too hot", I've had one woman tell me she was groped, a number been subject to unwanted sexual advances, and I've seen male staff cat call. I've had a manager massage me out of the blue. It's a gendered problem, the statistics bear this out, and acknowledging that is necessary in order to address it.
> Young women are working ridiculous hours as well.
That's not the point I was making.
> What child care, most of the highly educated aren't having kids to begin with.
That's not the point I was making.
> That's universal as well, not specific to women only.
Again, yes, Not Only Men, but there is a gender component to this that I am acknowledging.
Given that GP didn’t say they were, why is your first instinct to assume that anything OP didn’t mention, in what were fairly obvious examples, was specifically excluded?
> Young women are working ridiculous hours as well.
So are the elderly, why are you excluding them?
And so on.
Come on. There’s absolutely no need for the ridiculous pedantry, and it adds less than nothing to the comment chain. Be better.
But it sure does tell us a hell of a lot about the person who wrote it.
That said, I am actually actively trying to grow my engineers into somewhat of mini product managers themselves.
It’s going quite great so far— the more they get exposed to users and problems, the more they are taking ownership of their work.
I don’t hear things like “the user doesn’t understand” anymore, but rather “I tried to make it clear to anyone who uses it”.
They started coming up with features and changes that were way more brilliant than anything I could come up with. And also interviewing developers (who are also target users for us), performing small tests to validate hypothesis, and so on.
And they also started making little jokes in customer calls to keep users’ mood up! Some users even thanked us for letting them test our early “broken” work-in-progress :D and apologized for not testing well enough. The first time I saw this, it was crazy!
I am so incredibly proud of them!