"No, it's less effort than that"

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

> developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate

I put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which case they have a legitimate need for a relative estimate, but not an absolute one). Occasionally there's a real deadline, in which case again they don't actually need an estimate, they need a "can we hit this date y/n" (or, more usefully, "what do we need to do to make this date").

I'm very happy to work as closely as possible with the business. The reason I'm writing software at all is usually to solve business needs, after all. But when it comes to estimation it really is a case of them being wrong and us being right. (The best businesspeople don't work in terms of estimates in the first place; I don't know if estimates used to work at some point in the past and have been cargo culted since, or what)

> why shorter is always better than longer

If shorter is always better than longer then all my estimates are now 1 day. Does that makes things better?

> Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense.

Yes. Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work. Engineers/Developers are part of the org – not some special snowflakes that are above or beyond politics.

> Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Yes. Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work. Engineers/Developers are part of the org – not some special snowflakes that are above or beyond politics.

And yet, none of the politicians are going to toil to make the deadline work. There is no gain to be had for the actual engineers or the actual business.

How about this, tie a deadline to a well-defined bonus that only the engineers would receive and staff the project with ALL the engineers you can get. This will allow political heads to keep doing their coalition-building while engineers also receive some benefit for their toil.

If you are unwilling to share the rewards of the toil, it is no surprise that the actual people doing the toil don't care about your coalition-building nonsense that doesn't even help the business in anyway. Your coalition-building vs their own time with family/friends, not a difficult choice to make.

Wrong. Organizations don’t exist without administration, as a necessary requirement for doing business. Part of your time, as part of that org, will contribute to that if for nothing else because a company is required to comply with baseline regulatory compliance (accounting, taxes, investor relations, etc.).

Happy to share in the spoils and many companies do this with stock/options of course - but don’t think for a minute you live in a walled garden. I mean, you can, but then you get zero input into things like deadlines; you’ll simply be ignored or moved out of the org.

Your comment is essentially “I want all of the responsibility and none of the accountability”

> Wrong. Organizations don’t exist without administration, as a necessary requirement for doing business. Part of your time, as part of that org, will contribute to that if for nothing else because a company is required to comply with baseline regulatory compliance (accounting, taxes, investor relations, etc.).

Where exactly did I say that organizations exist without administration. All I pointed out was that if the rewards are not shared with people, people will not do the work.

But since you are writing this from a org structure perspective, I can alsosay that administrative work can be done by HR. Eng management can be left to handle engineering direction and task. Specifically, the political org structure is not a necessity - it is only something that low IQ can understand. A smarter structure is technical leadership all the way up to VP + HR that manages pay and promos.

Nothing personal but I’m guessing you are either relatively inexperienced or maybe in a market that is different than the U.S.

The reward is your salary/bonus/stock, and it obviously works… because work gets done and tech talent is well-remunerated for it. The technical leadership structure you seem to be recommending already exists; plenty of ELTs have or are comprised of experienced people with deep technical roots.

> The reward is your salary/bonus/stock, and it obviously works… because work gets done and tech talent is well-remunerated for it.

By that logic, responding to requests for estimates with sarcasm and cynicism also works, because work gets done and tech talent is well-remunerated for it.