You would think that keeping the team effective is the basic job of a manager. Dealing with people who don't know how to do some part of their own job is of course an unfortunate, yet inevitable reality. But this is on the level of "developer who doesn't know how to code". The article leaps into teaching the manager to do their job, but often just switching teams or companies is much easier. Plus, after you put in all the effort, not every manager can turn around and appreciate it, many will just take credit and give you nothing. So if you're going this direction, there should be some thought given to deciding whether your manager would recognize your efforts.
It sounds like you're assuming "managing up" is about managers who don't know how to do their job. I don't think this article is saying that.
My best managers weren't ones who knew every detail of each project and could give unsolicited effective advice. They were ones to whom I could tell what was going on on my project, could ask for help, could tell them what I needed, and then rely on them to follow through on helping make that happen. Sometimes that was needing more time for a deadline, sometimes it was needing a mediation in a complicated relationship with another team, and sometimes it was using manager clout to go escalate a request for compute resources.
In any case, two-way communication is going to create a more effective relationship than expecting your manager to simply _know_ what you need.
I mean, if you’re in an adversarial relationship with your manager you should think of changing that, but a lot of these are just misunderstandings and the inability to have the entire team in their head at once. Like, as a developer, you can be pretty good at writing code and still get useful feedback from a code review. Having a communication channel open with your manager helps them do their job better and also helps you, and doesn’t necessarily indicate any sort of personal failing.
The fact that you implicitly assume that sharing information with your manager means they are failing to do their job is probably indicative if a bit of an adversarial attitude. At least it also came across like that to me. The way I see it, most managers I've worked with have been stretched for time and me giving information will only make things better for me and my team because the quality of their help will be better, regardless of how good they are at their job.
I agree you should not try to push through a bad situation, it really depends on the people involved and it's hard to give generic advice.
There’s an “if” in front, to help people recognize that my comment applies to healthy relationships and not unhealthy ones. No comment on your relationship with your manager.
However at the end of the day, what's important to me is to feel I've tried doing the right thing.
This means I can't do things conditionally or "only if I trust my manger won't take credit for it". If I want to be credited for my work, I feel that it's mostly my responsibility take credit for it.
It can be very difficult to change people, teams, processes, companies so I understand why we may want to get something out of trying hard to improve things we feel others should want to improve as well. It's not always as obvious as "a salary increase" or "public recognition", but employees who try to improve processes indicates to management they are interested in sharing their input and committed to making things better. This fosters credibility, and creates a more positive work environment.
Job hopping may often be easier but is often seen as a red flag by employers and it can make it difficult to build a strong, long-term career.
What is unfortunate in my opinion is working with developers unwilling to learn more about systems and infrastructure. With the rise of DevOps, it's often the norm that many developers don't know how to do some part of their job. As opposed to your comment this is not on the level of "developer who doesn't know how to code" but "developer who don't know how to work with the underlying systems, builds, deployment processes, and the underlying infrastructure powering their code".
When people are unwilling to learn from others, they are missing out on opportunities to grow and improve. This can lead to a feeling of being stuck in a rut, and can ultimately lead to dissatisfaction with one's job or career; as much for people who lack some expertise and are unwilling to learn, than for those who can help them increase their competence in this closely related field of work, who often end up doing most of the work in this field
