Ask HN: What is a business anti-pattern you've experienced at work?

One antipattern I've seen at a few companies is analysis paralysis, where there are endless meetings and strategy sessions to discuss a solution to a problem, but there is never an actual decision made. One company I worked for had a series of meetings with 5 or 6 people to discuss the solution to a problem and still couldn't decide on a solution (copying themes/templates between multiple sites. In the end I purchased a $60 plug-in that solved the issue. This same company paid a contractor $20k to build a custom app to turn a shared inbox into a ticketing system. This feature and more is available as a SaaS product for $20 from multiple vendors.

Another is gold plating, where more requirements get added on even after the initial requirements have been met. A few years ago I worked at a startup that made a dashboard for small businesses to manage their online business listings (Yelp, Facebook, Google, etc). They could see all reviews across sites, reply, update info, etc. So product comes up with a new feature to create offers/coupons and post them on sites. We implement all the requirements for an MVP which was creating and posting immediately. Then on the eve of releasing it they add a new requirement to schedule posts (the engineers all objected but were overruled). That led to complexity with timezones that added an additional 2 months of development and bug fixes. In the end, analytics showed that only 2% of users scheduled posts, the other 98% sent immediately.

Partial remote communication: Some members are remote, some are in office. The remote workers are often left out of the loop, and often out of friendships, and communication is not done on tools where they can listen in on. This is usually less productive than fully remote.

Mushroom management: Managers keep the developers in the dark like mushrooms. Often consulting companies afraid of being undercut by their developers. It adds communication overhead and "telephone game" communication between the managers and developers, and very often devs don't understand why something is to be done a certain way and are less motivated or cut the corners.

2nd System syndrome: The first system someone designs is underengineered. The second one is often overengineered, which is worse than underengineering. Worst case is making such a person team lead. This isn't just engineering, but also management, sales, etc, as well.

Bikeshedding: If an objective seems simple enough, nobody can agree to it, because it's within the Dunning-Kruger zone of people who want input.

Duck decoy: Middle management feels like they have to give input and criticize to be useful. An engineer can set up a "duck" feature (search for Battle Chess) which is easy to criticize and easy to remove, to appease such managers.

Friendly fire: For some reason, not enough resources are allocated to a project. Often time/tight deadlines. Team A blames Team B for not fulfilling their role. Team B blames Team A later. Blaming often freezes progress as they have to make meetings to explain the situation and possible solutions and negotiate adjustments to the schedule/budget. This can lead to a deadlock. A common option is to bring in a consultant then blame the consultant. That way only two teams are frozen in place, while the third team makes progress unhindered. The consultant will also blame the in-house teams, but their role is to keep it minimum and buy more time.

Budgeting as needed: A budget increases and decreases according to its needs. This often results in departments requesting extra computers, resources, printer cartridges, etc to finish a budget so that their budget isn't reduced next year.

socialistic workplace: Everything that happens has to happen as a group. All work has to be approved by everyone. Everyone works on everything and is responsible for everything.

Business managers at some point began thinking it was their job to destroy the individual professional. It is ridiculous, nothing gets done and no one can do anything. Imagine if a surgeon had to have a live feed of the operation and the entire hospital watched and told the surgeon they were doing it wrong. Imagine if the entire law firm came to the courthouse to sit behind the desk at a hearing, no one was in charge, everyone just spoke when they wanted, and every action was heavily attacked.

And something HN doesn't like to talk about: every hire has to be some sort of social case: handicapped, LGBTQ, under-represented minority, political refugee, or other.

75% of chief diversity officers are black women. There are virtually no other races represented.

Just some stupid stuff that started happening a few years ago.

Not trusting employees to make good decisions is a big one where I'm working at the moment. Everything we do comes from the top down often by people who don't really understand software.

For example, we have an extremely outdated code base that's full of security and performance issues which we can't fix because doing so "isn't MVP". Unless something becomes a critical issue such as a server going down we're effectively not allowed to fix anything. We also add to tech debt constantly because we always have to build features in the quickest dirtiest way possible, again because "MVP".

Thankfully I'm a contractor and I doubt I'll be there much longer. While this is one of the worst examples I've known of a company that doesn't trust it's engineers enough to build things the best way, it is quite a common pattern I've noticed among larger companies which aren't primarily software companies.

Cronyism or the buddy system. Where the wrong people are put in charge because of relationships not because of merit. These incompetent managers use fear tactics, the creation of in-group to defend their incompetence, and creation of a toxic environment which encourages bad behavior.

The business frequently expects IT to solve business problems.

The business problem should be solved by the business, then IT should transform the business system/process into a technical system by following well defined requirements.

Oh, we're late to deliver this thing? Schedule daily 1-hour meetings to discuss our lateness and make everyone write detailed reports of what they've done each day. Because nothing helps accelerating devs more than occupying their time with meetings and reports!

The people who make technical decisions (which we refer to as Architects) stop doing real technical work once they become Architects. So over time they drift away from the reality of the things they're working on, so we keep having these decisions that don't make sense at all. And these people almost never quit since they make so much money, so it's rare that we promote someone who will then go on to have sane decisions for about 1-2 years until they drift away from reality like the others.

We promoted a CFO to CEO, so now every employee, including R&D is just a cog with a cost and can totally be replaced by another random person in a 12h timezone difference.

Too many useless meetings.

Squeaky Wheel Syndrome: The noisiest issue/person is always addressed first.

This creates an unfortunate positive feedback loop.

Hiring for the sake of hiring. I cannot understand why companies think that growing implies hiring more people.

"Use it or Lose it rule..." Spend your annual budget quickly by writing Purchase orders and Hiring people before you really know what the customer wants, because (1) When the company is looking for any spare budget as the financial year goes on, they will come and take it back from you (2) next year you may not get as much as you ask for

Result = overspend on the wrong things, managed by an inadequate team...

* A manager discusses an unnamed worker's performance issues in front of the group, rather than confront the individual.

* Expecting strong performers to carry the weak without requiring the latter to step up their game.

* Requiring employee's to collect data (e.g. time-use tracking) that is never reviewed or analyzed.

That invisible inflection point in a company's growth, where the prevailing attitude switches from "we succeed or fail together" to "I could still succeed, even if you fail."

This is the earlier post, BTW: https://news.ycombinator.com/item?id=23964905