🔧 Bitter organisation landscape

There is a important book "The DevOps Handbook" by Gene Kim, Jez Humble, Patrick Debois and John Willis.
I do recommend it - this is one of the most influential books about devops I suppose. It says how things should be done, especially from work organisation point of view. The book describes how to get to devops heaven starting from some state which is imperfect to some extent.

However, I do not want to make a review of the book. Instead, I would like to describe the reality I experience everyday in quite large company (few thousands people).

Intro

I am recently in the small devops team in country A supporting subproject S which is part of large project P. There are few teams developing the subprojects S1, S2, S3 etc. where some of them depend on each other and which constitute S. S-teams are located partly in country A and partly in B (different continent). The highest management is in country C (another continent) also with some teams but I have no idea which.

Heaven and hell

I didn't realize it until recently but the reality comparing it to heaven in the book sums up to be just hell:
there is full blown waterfall model as team Q in country B is doing some manual testing slowing down everything and making feedback loop as large and slow as possible, there are separate teams for everything - for organisation wide tools, for internal libraries used by S-teams, for general support (never got any real help from them), for internal systems, for who knows what else. There is no effective communication between them: closer teams are kind of ok but distant ones act like enemies. You can write email to somebody or to some distribution list and wait forever. Like if they were located outside the solar system.
The release cadence metric shows the health or maybe the illness of the whole thing: it is few times a year.

It seems everything is on the other side of spectrum:
there is a fire-and-forget strategy among developers: they forget about the feature just after they merge the feature branch. Very often it gets stuck somewhere between subprojects blocking the pipeline. As a result, this is often the case that main job is not buildable for few days.
The work is often hidden as some guys do not register tickets for what they are doing, most of the people create tickets and pull requests without any descriptions. There is also no real CI nor CD (although most of the people think it is, take a look here what it means to integrate things: https://martinfowler.com/articles/continuousIntegration.html). Last but not least, most of the people around never think about the result of their work, but about work itself which turns into nonsense when their work is not contributing to business outcome:

• nine-to-five and I am out, I did some tickets, they payed me so whatever it is, it doesn't matter,
• detail-driven guys or better to say TDD priests which are going to endlessly program anti-asteroid system in TDD way even if there is going to be ELE in one hour,
• plumbers who are going to make perpetual manual fixes instead of thinking how to prevent the problem from reappearing in the future
• detractors which always vote for status quo

Management seems to see the problem but there is no clear plan who/how/when would start to improve anything.
Isn't the leadership supposed to be removing obstacles for the teams? I can only hear to do the workaround if there is a communication problem with the team responsible for some matter which is blocking me.

Some communication visualization here:

Trying to swim

I take some actions. I try to improve things in the nearest area by establishing some communication channels with teams I interact with. I try to introduce good practices around, but in the best scenario I need to be persuading people to change their work habits using extreme high amount of my energy and in the worst case they turn against the idea without any good arguments. I also publish internally mini-articles or show some trends which I find interesting (this is in front of country A audience) but most of the time there is zero feedback about this.

I don't know, maybe I don't see the full picture and the future is bright when looking from above. Or maybe I should just stay away from all of these, do the nine-to-five job focusing on some details everyday?

The question

Of course, not everybody is like this around me and not every team is malfunctioning, however there are too few of them to change my current perception of the organisation.

But, why am I writing this? I guess I am curious if this is the majority of medium to large organisations which have such a problems. Or is it just a bad luck in my case?

Thanks for reading.