Ask HN: How you ever quit because the engineering culture is too messed up?

My point of contact was their head of marketing, who said that all development had to go through the IT team. Despite having a large web presence, their VP of IT was adament that IT would handle all web-related work. Their developers were all employed and trained as IT technicians, even though they came from development backgrounds. Obviously, finance is a protected industry, so working IT in a place like that is no joke, but having IT handle all software development AND the maintnenace of IT systems meant that nothing got done, and when outside work was brought in they had to confirm to crazy standards.

Anyway, I was brought in to fix some build systems, built by a previous company. I spent three days there and got it working in the end. I actually spent most of my time chatting to the marketing lady, who was constantly asking me hypotheticals about how things work with other clients, how long it takes to get changes made/approved on a website, etc. Her questions were quite in-depth around clients we already had, and I said roughly how things worked. A week later, the VP of IT kicked off about unapproved work on the website build server (which was approved by one of the IT/dev guys), and she resigned. A week after that, she was a marketing director at the client she had questioned about.

I ended up chatting to her face-to-face a few weeks later, and she said there was a huge split in the company on how the engineering team should be run, causing nearly a dozen developers to join her at this new company. They all handed in their notice within the week, and the VP was so pissed off he put them all on paid gardening leave and told them to never come back.

Fast forward around a year, and I was at a conference taking a workshop on BDD with a new employer. A few of us were chatting to the guy running the workshop, when one guy chimes in about why he was on the course. He said some idiots at [Company Name] had built an awful website with a crazy build server setup, and that their IT team were looking to learn enough to perform a complete rebuild. The company name was my old employer, but the cringe doesn't end there. The person running the workshop was employed at the company that initially built the website and the build server, and I remembered his name in the commit logs as the one that lead the entire build. Their IT guys were literally bitching about incompetent developers to the guy that had built their systems, and his face dropped when he figured out they were bitching about his project. Despite trying to skirt around the subject or justify why some things are built the way they are, we sat there for twenty minutes as they tore apart what I'd consider a valid setup (onsite TeamCity, generated build scripts and artifacts running on a separate secure box to ensure that the site could be deployed if the build server went down, and a test suite to switch a blue/green type setup).

I pryed about their team, and they said that their IT team was trimmed to run a lean senior-level team. In the space of 18 months they had lost at least 20-25 people, and their IT/engineering team were going to rebuild a large-scale website with very little web development expeirence, all while maintaining the IT systems for a fairly large company. To pry further, I pretended to know a developer that had worked there previously, and the guy smugly said "well, if he's not there any more he was cut - not everyone can handle what we do".

It's been a few years since then, and from what I can tell they're still running the same website. I wish I could remember this guys name or the VP's name, just to see if they are still there.

If you're brand new, then just be quiet and listen for 6 months. Find out why they do things the way they do. They often have, if not totally valid reasons, at least reasons that are more valid than they seem at first glance. If you don't know their reasons, and you're telling them that they should do it differently, then of course the aren't listening to you.

But if you've been there for a while, you know which are the bad ideas, and you can't get them to listen to better ones, and that frustrates you, then it may well be time to leave.

I worked at a YC startup a couple of years ago. The day after I started, the guy who hired me (eng manager) quit. All engineers reported to the CEO (former dev). That was the first red flag.

The second red flag occurred a week or two later, when two of the other three engineers cornered me in a room and tried to convince me that I should do what they say instead of what the CEO wanted. Second red flag.

Third red flag was when any tough decisions were made, the CEO would leave it up to us to work out amongst ourselves. Majority ruled. He was so afraid of pissing off any of his engineers that he just wouldn't do anything at all. Total clusterfuck.

They would play games once a week to try and team build, but it was a joke. Nobody trusted anybody else, and everyone was trying to undermine the CEO. Technically, they were doing things fairly OK. They wanted 100% unit test coverage, they had a proper CI/CD pipeline, they expected 2 people to approve every PR, they versioned their APIs appropriately. But none of that works if the people culture blows. And this one blew hard.

I stuck around as long as I could while I tried to find something else, but I couldn't have been more glad to leave a place. It was hell working there.