> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
In one of my previous jobs, I worked on a software project that frequently got the following two kinds of comments from the managers:
"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."
"You have five developers working on one project? Isn't that too much?"
Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.
So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.
The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.
The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.