> 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.
> Nothing personal but I’m guessing you are either relatively inexperienced or maybe in a market that is different than the U.S.
No offense taken. I am in the US and worked for 2 of the FAANGs and 2 FAANG-adjacent startups. The work culture in each of these companies is so terrible that even $400k/year is not enough renumeration for that kind of pressure and political nonsense.
What I learned by working at startups after FAANG is that FAANGs are able to have such poor management practices (e.g. fiefdoms, politics, perf reviews) only because they can hide behind infinite revenue. Startups (<1000 employees) that copied FAANG practices crashed quickly because guess what, those practices are actually harmful to the producers of services (engineers, product) and that leads to a quick drop in revenue.
Except to many it is - and I’m perfectly happy arguing from the majority in this case, because the failure rate for companies that do not adopt many of the best practices you rail against is extremely high.
You also seem to be making arguments for things that already exist and are universal, like performance-based comp, etc.
> You also seem to be making arguments for things that already exist and are universal, like performance-based comp, etc.
This appears to be a form of projection because that is not what I was arguing for. And things that "already exist" don't always exist. They especially don't exist in the form they are in FAANGs.
In fact, in my experience, the companies that copied FAANG style are the ones that suffered more than other companies that did not adopt those practices. Having worked at pre IPO companies that succeeded and that failed, FAANG-style heavy management is the single biggest reason for company failures because every IC matters in these companies, and poor management practices affect actual product outcomes a lot more in smaller companies.
If you’re not getting well-remunerated for your work at at FAANG or a startup that IPOs… you probably need to get some help finding or negotiating on your next job my dude.
> If you’re not getting well-remunerated for your work at at FAANG or a startup that IPOs… you probably need to get some help finding or negotiating on your next job my dude.
Once again, you are missing the point of the last post which makes me suspect you are exactly the mediocre manager who gets complained about a lot. Let me guess, you hold weird ideas such as "If they don't do XX, YY, I will fire them" - never once blaming yourself for hiring them in the first place.
> Let me know if I can advise you on how to score comp you’re happy with on your next role!
I have already made my millions by working with sane ipo companies. At this point, I would much rather take advice from folks who prefer a good management structure. Please continue with your TC grind. Thanks for the offer though!
> 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.
> Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work.
Nah. Internal competition is a negative for the business. Selfish individuals do it so that they can get better results for themselves. Refusing to take part is the right thing for the business.
> I never said it had to be competitive nor is my comment recommending that.
You said "Thats how coalition-building, budgeting, and reporting works in business." In my experience that's only true in the bad kind of business where there's too much internal competition.
> You don’t own 100% of your time when participating in group activities.
You're responsible for your time. You should share it generously with people who want to put it towards something productive, but you should also push back when people want to waste it.
Internal competition can be good and bad, just like any other management principle. But at the end of the day, an organization needs consensus or it’ll implode, and some people are required to help build that consensus, amongst other duties that extend well beyond product. This is as true for business as it is in any other group dynamic.
You need consensus, sure. You don't time estimates from engineering estimates for it, and even if you did, badgering engineers to make their numbers smaller wouldn't make getting consensus any easier.
You do need estimates to unlock capital, plan budgets, plan for staffing. And badgering engineers to make their numbers smaller is often the result of engineers bullshitting their numbers, as I mentioned before. Engineering departments aren’t free from the same errors or fallacies or biases or mistakes that other humans make.
> You do need estimates to unlock capital, plan budgets, plan for staffing.
You might need some amount of estimation. You don't need a full schedule of every task, and producing one just in case is immensely wasteful. In my experience engineers are very happy to help answer questions like "should we be hiring more people for this project" when there is a real need and businesspeople trust enough to share that context.
> badgering engineers to make their numbers smaller is often the result of engineers bullshitting their numbers, as I mentioned before
Pretty sure the causation goes in the opposite direction. Most engineers are honest to a fault; the ones who pad their estimates are the ones who've spent too long working with crappy business people who do things like cutting time off estimates.
This is not something I'd bet millions of my own or investor's money on. The sooner engineers realize this – that their honesty simply isn't germane to the discussion at hand – the sooner this endless argument ends.
There's plenty of grown-up engineers who get this by the way.
> The sooner engineers realize this – that their honesty simply isn't germane to the discussion at hand – the sooner this endless argument ends.
Yeah, no. The sooner business people realise that honesty matters and deceit is deceit no matter how much sophistry you surround it with, the sooner the argument ends. There are plenty of grown-up businesspeople who get this.
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?