> "you now have a reputation of padding estimates."
> "Now you are a slow incompetent."
This is also symptomatic of organizations that behave adversarially and assume your intentions to be malicious. In that dynamic, even if you perfectly estimated things, you would still get in trouble for delivering what was agreed on instead of what was "meant to be agreed"...
Usually this is more the case in orgs who view software engineering purely as a cost center, instead of as a business differentiator. When considering a position at a company, this is a good thing to pay attention to.
> orgs who view software engineering purely as a cost center
This is spot on! I've heard this phrase before and it's never made any sense to me. Any business concerned about profit should never have a "cost" center. If that unit is not returning a positive ROI it should not exist. Of course software development costs money just like all other labor, building and materials but it's assumed the value generated by the work product is worth the investment.
Cost centers are generally unavoidable, they're aspects of the business where there is a well-defined target past which there's no meaningful ROI.
Regulatory compliance is a good example of this. Both you and your competitors must be compliant, but past reaching that state there's no additional value add. As a business, you're thus interested in keeping the cost of compliance as close to zero as possible, all cost cutting that does not break compliance is good for the company.
Keeping the cost of compliance small isn't the same as doing as little work into compliance as possible. More often than not, it's the other way around.
Corner cutting doesn't work on any of the usual "cost centers", and most of them can be transformed into a differential.
But even your example can be viewed as an unavoidable cost of doing business where the alternative is to not be in business. In other words there's a distinction to be made between regulatory compliance where you have no choice and automating payroll processing where you do have a choice. I think it's pretty clear we're talking about the latter and I would not categorize an internal software development team who's job is to make the business run more efficiently as a cost center, even though there's not external sales of their work products.
If tech is seen as a business differentiator, wouldn't the opposite be true? It's so important that they want estimates so they can deliver more value. If it's a cost center, whatever... we don't care that much.
I think my point is, the cost center vs business differentiator is not a good indicator of the root cause of this problem.
If it's a business differentiator, there's usually a better understanding from upper management that these things are hard, that there's trial-and-error, that some of this is R&D which will not have immediate value but strengthen the long-term position (or buy a patent moat)... If not, then that business is probably about to be in trouble.
> Usually this is more the case in orgs who view software engineering purely as a cost center
In my experience, this is more of a cultural issue, with it being pushed by engineering managers and tech leads who insist that everyone can be a 10x engineer if they just throw away their life.
When they’re past a deadline, it doesn’t matter why, because they were clearly just being “lazy”.
Estimates truly are a lose-lose for software engineers and they have probably caused me more grief than any other aspect of this field.
> "Now you are a slow incompetent."
This is also symptomatic of organizations that behave adversarially and assume your intentions to be malicious. In that dynamic, even if you perfectly estimated things, you would still get in trouble for delivering what was agreed on instead of what was "meant to be agreed"...
Usually this is more the case in orgs who view software engineering purely as a cost center, instead of as a business differentiator. When considering a position at a company, this is a good thing to pay attention to.