Management giving estimates? No thanks. I'd rather them take my input and do their job of understanding trends. When I say something takes a long time and it takes longer, I'm not bullshitting. When I think something takes a long time and doesn't, its generally because shortcuts are rarely understood up front. Will I find the same shortest path next time? If I'm doing the same exact work maybe.
I do work in a place where we are a software company but very few people, even some of the devs, understand this culture. I don't say something is complex just for the hell of it. I want to give good estimates but at the end of the day that is all it is, a somewhat educated guess before I've gotten in the weeds. I don't need people that absolutely don't understand this concept to mandate a timeline that is unrealistic. It does absolutely no one any favors. That is why I leave. I don't need to promote unrealistic expectations down the line to customers who think everything is extremely simple. Especially when all we do is create custom software where almost 0% is turn key or off the shelf. Its just insulting to continue that nonsense and the quicker I can facilitate a reality check for all parties, the better and more trust is given to my judgment (and theirs if they actually take the time to learn)
I have done it using the XP planning practices. Basically, you make the suit break everything down into relatively small lumps and place them in priority order. Every week, the team completes a few lumps. Before you do them, engineers grade their relative complexity in arbitrary units. (The smallest substantial thing you do is 1 point; something twice as big is 2 points, and so on.) Every week, you count up the points completed. That's your "velocity".
From there, you let managers do all the estimating they want to. If they want the complexity of a unit of work measured, they ask the engineers. If they want to know when X will be done, they look at the team's recent velocity, what's in the queue before X, and do some basic math.
The nice part about this is the mental judo involved. Whenever they want to know when something will be done, it's their problem to trade features against time. Working like this, it's not geeks vs suits; the suits channel their schedule pressure into productive work: grooming the backlog.
I misspoke. What you are describing comes from developer feedback but indirectly in a sense. This, I think, is a nice standard of measurement. Its when people solicit absolutely no feedback either in the form of past projects where hours are measured somewhat or what they just "feel" something should take. I'm all for metrics based estimation because that's how most developers would likely estimate. Its when management seems to pull things out of their ass to get a prospective client I have a problem with. I understand when we need money but I can also trace some of our worst clients to some of the most unrealistic estimates we've ever given. They're almost a 1:1 direct correlation and its like no one sees how much of a drain they can be all around.
I have been there, and feel your pain. It has taken me a long time to learn to say, "Oh, you told somebody that? Well, then you have a problem, don't you?" Of course, there are some companies that are so pathological that this stuff just won't get better: there's a broken feedback loop between the promises and the consequences. Ugh.
If you think about it, though, estimates (time, money, personnel) is really a management function.
You write "I'd rather them take my input and do their job of understanding trends." that's exactly what I'm talking about. They need to take your input, and do their job.
If a worker is told: "Here is what you (personnel) have to do (task), with these tools (environment), and we want you to do it in this amount of time (money)", and the worker fails to complete the work in the amount of time, then it is management's fault. They improperly estimated the amount of time it would take the worker to perform his task.
That management ask the worker how long the task will take means management does not understand the task, and if management does not understand the task, how can they know whether the worker's skill, experience, and knowledge is adequate for the task? Now, they also seem to not understand the worker's skills, experience, and knowledge, so the problem is compounded.
It is a management function to clearly define the tasks that must be performed, attract people whose skills, experience, and knowledge fit the tasks, and fund these people with the appropriate environment, tools, and salaries for them to perform the tasks.
That is the role of management. If they are unable to estimate what tasks must be performed, what people need to be retained, and how much money and time will be spent, they fail at their managerial duties.
That they then blame the workers themselves for improperly estimating the work is doubly wrong, a sign of managerial immaturity.
I do work in a place where we are a software company but very few people, even some of the devs, understand this culture. I don't say something is complex just for the hell of it. I want to give good estimates but at the end of the day that is all it is, a somewhat educated guess before I've gotten in the weeds. I don't need people that absolutely don't understand this concept to mandate a timeline that is unrealistic. It does absolutely no one any favors. That is why I leave. I don't need to promote unrealistic expectations down the line to customers who think everything is extremely simple. Especially when all we do is create custom software where almost 0% is turn key or off the shelf. Its just insulting to continue that nonsense and the quicker I can facilitate a reality check for all parties, the better and more trust is given to my judgment (and theirs if they actually take the time to learn)