What practice by a tech team pisses you off to your core?

People bossing equally qualified and ranked employees around. Weak managers who don't make an effort to address problems and just complain. People who do what they want and then heap criticism on others. Short term decision making. Inability to commit to long term plans. Lazy workers who spend hours on the phone or take the longest breaks and also do very little but talk the loudest. Mercurial people who just like to argue but can never be pinned down on everything. People who just book meetings with no agenda in emails and expect you to commit to things without any prep. People who don't read meeting agendas and relevant documentation before coming to meetings, meaning that they need to be spoonfed. People who passive-aggressively stay silent at decision times and never engage and who then make fuss down the line when it's too late. People whose lives are very clearly not working who give you mediocre surface level advice about what they want to see from you when they're not qualified to offer any kind of therapy or counselling and rather than thinking more deeply about the mechanics of people. Managers who are visiting a therapist/counsellor and regurgitate the advice they heard from their last session to you. Managers who talk about their previous awesome gigs and fantasize about recreating them rather than focusing on the problem at hand. Managers who act like they're not supposed to make 50% of the effort in connecting with employees. People focused on empire building instead of doing the job well.

I can go on.

Non-stop complaining. Totally kills optimism and energy of an entire team. Complaining is contagious too, so it's not long before 1 chronic complainer infects the team.

I don't mean focused retrospectives, which is time set aside to constructively address things worth complaining about.

The CIO, or such, that tries to show he/she is the smartest person in the room. It's especially common in the tech interviews. Or the want-to-be tech person whose conversation is a salad of tech acronyms but has very little understanding of what all of them are about. It's about trying to impress the common person since most people are too afraid to ask what they mean and risk look dumb.

Mine is when people start talking about XDR, SIEM or SOAR systems.

There's so much bullshit going on in the cyber security scene, it's ridiculous. From supposed "AI driven network analysis" to "data enrichment pipelines"... everything is built as Enterprise as possible, and as useless as possible.

An XDR system that costs more than 500k per month and cannot even show the geolocation of an IP it's supposed to be able to block traffic from...I mean, come on...

Let alone the alert fatigue Blueteams have to deal with every day, where 99% of alerts is just noise, and the supposedly "intelligent" system doesn't even correlate the OS, let alone the programming language its services are running on.

Analysts are so overworked because all the products suck and use UX from the 90s, and are not even capable of batch-closing alerts when they are identical. It's so stupidly built that I don't even know why upper management buys that crap.

Most of the people getting promoted/going into management arent the smartest or best fit, its just someone willing to gun for it/jump through hoops. So you get those types potentially bossing around someone more competent, odd dynamic

Causing others to lose face publicly. For example, calling out team members for a bug they introduced, when you could ask them about it privately.

Another one - refusing to do any testing or CI because they think it will slow down the team.

Insisting on a CI/CD "deploy-direct-to-prod multiple times a day" process without ever investing in the things that are needed to allow this to happen successfully.

I've worked in the past with teams that have cargo-culted "Build fast, break things" to mean "If CI can builds it, let it deploy to prod". No tests, no Dev checks, barely any code review (The namesake "LGTM" on 1000 line PRs within 5 mins of it being opened or the worse Reviewer=Self), and things pushed to prod which invariably breaks and then everyone is scurrying to push hacky fixes because "it's a prod issue". And rather than fix the issue, it's always suggested to add more folks on call for critical issues etc.

It's okay when junior engineers do this because they're still building up their best practices, but when senior/staff engineers still bat for this process, it really grinds my gears because they not only mess up the company but "teach" junior folks that this shit proces is an acceptable way to build software.

Everyone will acknowledge that customers are seeing a lot of bugs (to the point where customers have attritioned because of buggy behaviour), and we need to be better, but noone acknowledges that CI/CD is not a silver bullet, but a rather intricate process that has many moving parts and needs to be built up accordingly.

1) Sprint boards are not locked and things are added close to end.

2) Sprints are made overly ambitious because if not everything is done it makes it seem that someone slacked off when the achieving all targets was impossible in the in the first place.

Management pushing for new features without a care for tech debt.

I'm not sure this pisses me off "to my core", but I've seen so many teams stop fixing bugs in something because they're writing a replacement that's supposedly going to be done in 6 months and will have none of those bugs. 2 years later the V1 is still the only solution that exists, and it's been allowed to rot while everyone suffered through the same bugs for 2 years. This happens most often when a team inherits a codebase they aren't familiar with and aren't excited about learning.

Two, related:

Not enough bottom up feedback. Roadmaps that can reflect the opportunities with high mechanistic-sympathy or address the real issues/opportunities seem rare once scale gets even mildly higher.

Product driven orgs that too often ask for quick & dirty & fast. Cutting corners is ok sometimes but if you keep doing ot, everything becomes a geometrically worsening half-baked barely-thought-out terribly-tentaclly-tangled mess, and the managerial/product class people never face it, see it, & move on, leaving the engineersired on their shit.

Quick & dirty also has a raft of personal issues associated with it. It's pretty insulting, often, as though product thinks they know best & are going to get some big savings. But 4 out of 5 times the damage more than makes up, but thats rarely admitted to or seen, and the savings never seem super significant. Also, good luck telling engineers to not take pride, to just throw shit together; I have found few respected peers who like being told that & who stay motivated when being told this is low quality whatever we're working on & to you know, just make some rough cuts at it & ship it.

The second of my two, asking for quick & dirty, leads to shit relationships & shit systems, which are major major reasons why my first issue, the on the ground knowledge of what we have & what we should be springing for & ehat we should be improving, becomes just a critical restabilization; bad jobs (or more often just accrued legacy to be honest) make it so fewer & fewer have the technical appreciation to right the hole-ridden old ship.

When the team doesn't talk synchronously. So many times I've seen folks post a question that needs swift response to some issue tracker and then act indignant when they are held accountable for the thing not getting done. The answer is almost always "well no one responded until 3 days later".

Yes well no one asked you to leave some text on a server somewhere and hope someone sees it. They asked if you could do X by Y time and you said YES.

Just any kind of “cheating”/intentional tech debt/low quality to meet an arbitrary deadline.

Pull requests which have artificial requirements. Which, these days, may mean many things.

It's illusion that PR can usually be compact in terms of lines and files. That not only requires a good quality of code, which isn't ubiquitous, but also good understanding of code, which changes all the time with different opinions resulting in that code being modified. So PRs become rather large - and sometimes surprisingly missing useful things, because exact change isn't easy.

The PR which is hard to review may mean that the code isn't understood the same way by different people, and this is a signal that some discussion is needed. Unfortunately often that's not done, and after some efforts PR is pushed through, while misunderstandings grow.

not letting devs push code on friday afternoon

Changing code you have committed working on (as can be seen in the product management tool) without notifying you, which makes git return hundreds of merge conflicts when merging the main branch into your work branch -- basically ensuring you either can start over again based on the new code or risking drama when force rewriting the main tree without said unexpected changes.

Worst time it happened to me was the day just before the start of my Christmas holiday and it almost made me quit.

Teams that don't take responsibility for their fuck ups. "Oh, that's your code." Yes, it's in our repo, but you wrote it in service of your needs. "We need you to help us get this out this week" well then you should have started sooner.

"Hallway meetings" (even if virtual) which do not include all stakeholders and at which nothing is recorded. Just "oh yeah we decided" a week or a month later. When I was in a position to do so, my answer was "no you damn well did not".

micromanagement.

Hate it when director joins regular meeting and brings a lot of confusion with their little domain knowledge but speaking loudly thei ideas...

And also when people try to understand what business value brings shifting a button from right to left and talking about it for 40min.

"Seems fast enough to me," when something is clearly slow.

So instead we're just not going to optimize anything, and every tool just gets slower and slower and slower.

Scheduling {anything} for release in the 4th quarter.

It isn't going to make it, and it will annoy/discomfit/make life miserable for everyone.

When the culture is very hierarchical, so even small change requests travel up the chain several notches for approval.

Mis-handling public communications about releases of significance.

Mis-handling of public communications on significant outages.

When my job description gets expanded. I am a rails/elixir dev. I don't do ops, that is a hard and complex job that takes practice to be good at. I respect the ops team. I can't just dip in and do one of their tickets when things are slow.

There is no such thing as full stack. Unless the stack is super small.