You're assuming, incorrectly, that management (especially upper management) is worried about producing quality products. They sort of are, but for any of the people who mange to survive in those positions, that's a secondary (or even tertiary) concern - their primary concern is survival. The only way to survive has little to do with creating a great product and everything to do with making sure the blame never falls on you.
Well said! I'm immediately reminded of the paradox of the 4th down punt in American Football. Put simply, head coaches choose to punt far more often than they statistically should; but, they do so anyway because it ensures they won't take the blame for the "unorthodox" decision.
In this case, it's management giving the impression that they are "doing something." We see the same thing with, "can we add more developers to speed this up?" The answer is almost universally "no" and, presumably, any manager in the modern era should have read (or at least be familiar with) the over 40 year-old book, "The Mythical Man Month." But, from a senior management position, there aren't many levers to pull--and when the heat is on, they have to be seen to "do something."
One interesting source on the topic (there are many others):
Speaking to senior management about being "seen" doing something here. Maybe you should pull up your bootstraps and ask your team what they need, use your authority to knock down any blockers the team identifies, listen to them, work with them in the trenches, and in a way become their slave, ready to move on anything they ask of you. But hey, that's just what I'd do in the situation and be danmed if someone tried to tell me I wasn't doing something.
I don't know how much that would help. If senior management were capable of contributing at this level, they'd be an architect or product owner. They're not, so they cannot help.
A certain design and a certain set of requirements is what defines the time table. You can influence it to a very small degree by adding more people, but that's it. Nothing anybody can do will make it faster, unless they propose a better more efficient design or way of doing it. Or reduce the requirements.
The flip side, though, is that intrinsic measures of software quality are terrible. Most boil the ocean looking to define what makes something good in the small, and completely fail to generalize into the large.
Worse, too many are interested in building a general solution when they haven't even done a single concrete solution. I have yet to find a proud developer that said, "I used the boring choices for this problem and got a solid solution."
This is akin to expecting an artisan to give better results for a standard kitchen than a builder would get from buying Ikea.
And don't take that as some sort of value judgement either way. Builders are there own to of Craftsman. Different doesn't need a hierarchy.
My gut for why this is? In a fiercely competitive field, leverage from success is the primary driver. And you get more leverage and success by being different. The upside is huge. Naturally, so is the downside. Survivor bias kicks in and people think they succeed from wiser choices, so they are incapable of reflecting and making less risky choices as they age as an org. Which requires an influx of young risk takers that have not hit a downside yet.
I'll blame writing on my phone while on the bus. With my stop coming up. :)
That said, probably nothing too deep. I certainly wasn't aiming for it.
My main points:
* Most of us in engineering focus on intrinsic measurements of our code's quality. These don't generalize well to product quality
* Nothing wrong with being a builder, instead of an artisan. Especially when it comes to building.
* Most people that succeeded fall to survivor bias and think they know why they succeeded. They are usually wrong.
Note that it isn't the case that anybody who goes into management is automatically survival-oriented as opposed to doing-good-work-oriented. It's just that the ones who prioritise their own survival tend to survive longer than those who do not. It's sort of a combination of the anthropic principle and tragedy of the commons - management is the way it is, because if it weren't, it wouldn't be where it is. Meanwhile, if your company was structured in a way that rewarded striving to produce quality product using humane practises, you will (paradoxically) make less money over the long term than sweatshops. Sadly I'm not smart enough to come up with a system that fixes this, except perhaps to run companies like democracies and do away with monarch-style CEOs. But then my employee-focused democracy would be outperformed by the money-focused kingdom next door.
UBI would help these situations. Those managers would probably invest less time in the survival mode stuff if they knew there was always an option out. Further, their staff wouldn’t need the work so desperately so the amount of stress they felt would be “capped”.
There's also probably a portion of managers that cause the crunch by being incompetent up front. Not managing scope, escalations, resourcing, decisions etc leads to tight deadlines and 'sudden' urgency to meet earlier expectations that were never managed or adjusted along the way.
