> your own work falls behind

which is why one should not self-sacrifice. It garners no reward for one. Secondly, if the boss doesn't realize how much of an enabler you are, then it's time to start looking for a new job before the layoffs even starts as a thought in the boss' head.

Great workers know when they can help others without falling behind themselves. Or have good communication skills to explain what they were doing.

Or are good at communicating and don't need to do anything because they can just lie.

Well at some point you expect some artifacts to show up, even if not just code, design docs, RFCs, code reviews, something. If there truly is nothing I don't think that's a viable way to contribute either. Sure one can "only help others" but all good engineers I've worked with can help others and still do their main tasks, and if they get to a point where they are a point of reference for everyone else and everyone else gets blocked without them this is a high priority thing to fix in the team, probably one of the highest priority things to fix.

I've seen management let bad engineers re-do projects from scratch 2 or 3 times. Because they blame bad requirements, poor choice of programming language, and whatever on all the issues that the project has.

They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt.

But thanks to how good they are at communicating, are considered by management to be good engineers.

While doing a working project at the 1st try, without using this week's new framework and so on isn't as valued.

I mean at some point we just get generic enough that we have to agree on the ultimate fact that at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles. I agree what you say happens but if good work isn't consistently recognized and you think you've worked on your comms, there's not much else to do really.

> at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles

Unfortunately, this can cut the other way as well where you can have someone incompetent override competence or not even involved people further down which is common during large layoffs

Incompetent CTO can promote incompetent developers to be leads, so now all of the projects from that team will be done terribly. But the CTO can't go back on his decision because he'd rather waste years before getting a result that works acceptably rather than show that he made a mistake.

As a senior engineer I've learned that is my job. I take on much less work than anyone else because I know I will be called on to solve those problems.

This is in fact known in management literature: assign your best people to the least important project. That way the second best can grow to become the best, while the best are always free to help out if your fourth most important project has issues - it isn't a big deal if your least important project doesn't get done on time and if they manage to finish it so much the better. (your best are also free should sales discover a short window where a quick feature can bring in a large sale - though this is obviously easy to abuse)