My experience with toxic teams
dev.to
dev.to
tl;dr: Toxic teams come from lack of vision from an equally toxic management.
To be precise, toxic teams always develop from an overworked, understaffed workplace, on a vision-less project, thrown together so fast and so haphazardly that it cannot tolerate any degree of failure, with no fallbacks implemented due to cost and time. This profile fits every failed "disruptive" startup or company I've worked at over the past decade, especially in FinTech.
No one uses vacation time or sick leave since no one can fill in for you. Having any sort of redundancy is seen as "bad", in all circumstances. If one employee is going out for a week, and his or her part of the project breaks, that's going to stay broken for a week if that person leaves. Employees are told they can start "living it up" just as soon as sales "hooks the big one", then they'll hire more devs, and it'll all be fixed, surely!
If you insist on taking vacation, they'll expect you to be "on call". In my personal experience, I saw a manager give a sales rep an employee on vacation's cell number with the instructions "if they call in about [component], throw her on the call." There is no escape.
It's always crunch time because planning anything in advance beyond the next fiscal quarter isn't possible, due to, well, crunch time. This one feeds on itself. Startups and FinTech darlings think they can be a 1-year-old vineyard selling 10-year-old wines to 100-year-old clients who see right through this BS.
The priority of the day shifts to whoever is screaming loudest because, as we've discussed before, the project was thrown together so fast and so haphazardly that it cannot tolerate any degree of failure, and something crucial just broke, or in the case of one startup I worked at, "the laws of physics got in the way."
Socializing with other teams is frowned upon because talking with other teams gets people fired. It's a paranoid (but completely justified) mentality that discussion with other teams may reveal someone from one team is better at solving a problem than a person on another team - which can alert managers, who then tell their superiors, who then tell the better employee to move to the other team. And the poor guy he bested? "It's his last day, and now two teams are angry at you because you opened your mouth."
The communication you _do_ have has been reduced to some trendy iteration of IRC with half-baked teleconferencing built-in. Teams cannot see other teams' chats, for reasons unknown. Miscommunication is always dismissed as "Oh, we already discussed that in our team channel." The people who need to be on the chat app, which is pretty much all of management, never use the chat app. E-mail doesn't work, because no one checks their e-mail anymore. E-mail inboxes are where excuses from the CFO for that terrible last quarter go to die. There is only despair and automated messages in the inbox.
Never expect documentation. Ever. If the software is too crucial to let rot on the vine, and too complex to maintain if the maintainers are laid off, you won't find a shred. Writing good documentation means that someone with a certain level of technical competency can follow it, someone who the suits could pay a lot less than they do you.
If a company suddenly requests thorough technical documentation on a product, the poor soul's days are numbered. Many are directed "on a whim" to write exhaustive documentation, only to be laid off the week after said documentation is finished and announced to management. The system is then thrown to a team of contractors elsewhere. Yeah, one could argue that the system must have not been too important, but no one deserves to be treated this way, knowing you're basically writing your job away, one keystroke at a time, for several months.
There is little or no recognition of good work because "the work is never done". Everyone can rest when the project is done, which never happens because either the money runs out, or the project is abruptly cancelled (the money ran out).
Check-ins are constantly skipped. If there is a check-in, it's a cover for the actual intent of the meeting - layoffs, or announcing that people have been laid off. Ergo, no check-ins is a good thing.
Project-stopping roadblocks are ignored because that would implicate to management there was no proper planning ever involved, which everyone knows damn well there was no proper planning ever involved. If the remedy is a third-party service, suddenly there is enough money for said service, especially if the person (if any) responsible for clearing the roadblock is paid more than that third-party service costs.
Insults abound in the workplace, but they are crafted in a way to appear superior to management, who see the pecking order as "structure". Complaints are shrugged off by HR as "banter". If it's any consolation, these same people doing the pecking are being pecked at by someone higher than they are.
It isn't safe to fail because the company never had any money to afford failure in the first place. That doesn't stop them from acquiring other companies in a desperate attempt for growth, though! Yes, there should be safeguards to prevent failure from being catastrophic but that safeguard is to have a product that actually solves a problem, rather than having a product to solve a "problem" created simply for the product's solution to solve. It's the tech equivalent of a Seen-on-TV gadget.
The saddest part about all this is that everyone on the team feels the same way. No one benefits from this, and it's only prolonging the inevitable, when everyone has to pack their stuff in a box and leave the premises by lunch. It's a miracle if you still get severance. Am I jaded? you bet!