Management Issues in Engineering

I can't claim to be able to say much, but if it's anything like my experience, it can be an organizational problem.I've seen this happen where there is something like an "architect / senior" vs "normal programmer" role split, where the architect can sell some stupid idea that sounds good, or make a proof of concept implementation, then throw it over the wall to someone else who needs to maintain and fix the mess.Or if practices like code review or te

Most of the fast growing companies run into your described problems. As long as there is no upper management commitment to the values of "proper written tests and benefits" or "correct GIT usage" or something else, there will be no change but "Burn Outs" (the one's that try too hard to do 100%).Your "Head of IT" is most probably "forced" into dropping those values in favour of a "up & running" product.In my personal case

As a consultant to large orgs who was paid handsomely to fix the situation you describe, I can say that is exactly what they think, and also exactly wrong.[edit] Many people in these orgs are doing exactly that. Having come in, diagnosed the ultimate crap that kept them on that 1 button for six months, helped give them the autonomy to do what was needed helped everyone involved, from the devs to the PMs to the division itself.It's a common and insidious pattern, but even big companies

I can confirm this, I've seen this happen in a startup that has ~40 people. The cause seem to be that devs aren't sensitive to business needs, and product managers/owners don't fix this.

Accountability is what you are looking for.This is not a technical problem. Try to find out who is accountable. Who gets fired when the software doesn't perform the way it should. Notice nobody gets fired. Because the whole chain of command is afraid of accountability for themselves.

This is a valid story, and I have no doubt it’s real. I’ve heard and seen many stories like this that have happened.But… I’m going to say the dirty, quiet, and unlikable thing out loud.That had nothing to do with DevOps or its philosophies, processes, or patterns. That was bad leadership from the top down plain and simple. It’s likely not even the individual engineers faults. It’s leaderships fault for not setting clear objectives, implementing them, ensuring that the engineers had a real

It's this "committee" job to make sure the organisation has the right tools without descending into anarchyit's senior managements job to make sure the dev leads are working wellBasically this is senior / middle management in every companyyou had senior management that have not realised the importance of software to their business - so they let a situation develop they would never allow in sales or accounts

I think you mean organizational issue not development skill issue. If shit is constantly hitting the fan, that is the orgs fault, not the engineers

This sounds more like bad management than bad engineering.

This looks like a cultural problem where the top brass either believe in strong-arming developers or aren't aware about the dreadful impact of not following processes (code review etc.)Your expectations are perfectly reasonable. I think you should consider explaining to everyone (including non-developers) how bad things can go if these practices continue.