Hacker News Reader

Comment by 2d8a875f-39a2-4 | Hacker News Reader

The CTO and CPO weren't estimating the time to build the feature, they were estimating the number they needed to win the business. Successfully - job done by the C-suite.

The job of the author wasn't to build the feature in the X weeks, it was to manage the customer while the project completed in whatever time it took. He was successful too, even though he doesn't seem to realise that was his primary value-add.

The customer didn't want or expect an X week delivery of specific scope, they wanted to sign on vague requirements that they could change as the project went along while keeping the vendor under pressure to deliver whatever thing they eventually found out that they wanted.

All of the hand-wringing in the article about estimation misses the point entirely.

View on HN

They didn't seem to communicate to the author the critical bit of information then (i.e. "we have no intent of actually building this to these requirements in 12 weeks"). I get that there may be a business charade going on where impossible requirements and deadlines are juggled, but the key for the CTO here is not to simply pass that down to the team delivering, no matter how tempting that may be. His job is not only to get the deal, it's also to protect a functioning team.

The result of failing to do so is a team fighting uphill to deliver an impossible goal. So long as the CTO's actual plan is delivered to me, I have no problem with it. But too often the project evolves into negative pressure and "crunch time" to meet the impossible goal. Differences between actual goals and "paper goals" are blurred. If that's what's going to happen, I'd want no part of it. In fact, if the goals are sufficiently unrealistic I'd tell the CTO to clearly communicate with the customer what's realistically achievable in 12 weeks, or find another developer (Yes this has been a successful approach for 20 years and counting).

I doubt a CTO would want to document that they are lying to customers on estimates.

Yeah, instead they just say "software estimates are totally impossible to make! We can't help it!".

It is easy to make relatively accurate estimates if you want them, but there is very little demand for accurate estimates, managers wants overly optimistic estimates because those are easier to sell.

Estimation is doable statistically. You can estimate 100 small things with reasonable accuracy, if you work in familiar terrain. That's why scrum an similar tend to work reasonably well for seeing if you are going to hit some iteration deadline etc.

BUT you can't estimate a huge software project up front, because you can't break it into 100 small things up front and it's not usually not familiar terrain before it started. You might be forced to give an estimate up front in order to get a deal, but it's all business theater.

Then I'd be fine with clear communication among all senior executives, so that HIS boss in turn doesn't believe the team is going to deliver the paper goal, and later gold the CTO to it. If there are two different sets of requirements (Paper requirements and actual requirements) then it's pretty important that the whole C-suite agrees what the team will be held to delivering. Otherwise you are going to see the CEO breathing down the neck of the CTO once the project fails to meet the paper goals. Next thing you know, it's "pizza night" for the team.

It would be interesting to see how the CTO and CPO dealt with the blowout in delivery time. As they pretty much gave a made-up commitment to the customer, did they also create fiction when reporting to the CEO or the board in how their team was doing at meeting delivery revenue and containing costs?

Yes, all very true; and in some cases you may extend the client role motivation down further into their own organization to fund the project in the first place through a fractal of self similar patterns. Looked at from deep enough in the client organization - the contractor CTO/CPO and the Client's own PMO are all just 'that project' and have the same commitment pressures.

Very well stated. My conclusion is the same: It may not have been comfortable or unambiguous every step of the way but basically all stakeholders win in this story.

Coming to “agreement” over a fiction isn’t okay. No amount of rationalization makes it “business”. More to the point, it is unnecessary. I hold there is harm here.

A different skillset is needed to negotiate from truth (“we need to confer with our building teams to estimate the full project timeline”) and still be persuasive. It’s not more difficult, and these these skills are not rare. They don’t get used in some environments (not many, certainly not most) because of culture, and at the ultimate expense of the leaders that set it.

Maybe the company won the deal because the CTO and CPO said "yep - we can do that in 12 weeks" whereas the competitor said "we need to confer with our building teams to estimate the full project timeline" and promptly lost the deal...

And maybe the company will lose the next deal, or the one after that, because the customer won’t give a reference; or because they took too many shortcuts and hosed the product; or they have so much technical debt the next project fails.

That’s the problem with this kind of kick-the-can-down-the-road thinking. At some point you get to the end of the road, at which point your competitors can come and kick you.

They'll win the next one as the cowboys' teams are tied up for a year, and all the ones after that as the cowboys lose their good employees.

Honestly, I didn't even pay attention to the list. The important part of the story is that the execs 'delivered' on a promise, made the deal, and kept the customer happy.

This is a massively insightful comment, thanks. It also describes a world I never want to live in.

> a world I never want to live in

I have bad news for you, OP...

> The CTO and CPO weren't estimating the time to build the feature, they were estimating the number they needed to win the business.

There is a school of estimating called "Guess the number in the boss's mind".

A salesman's "estimate" is a number for him to discuss with customers; and it might bear on the price he decides to charge. But it's unrelated to the amount of time it takes to do the work.

You also have to take into account that often a certain level of power play is going on: those developers need to be shown they are much lower in the hierarchy than the sales people.

Totally agree.

> The job of the author wasn't to build the feature in the X weeks, it was to manage the customer while the project completed in whatever time it took. He was successful too, even though he doesn't seem to realise that was his primary value-add.

This seems unlikely, given the story as written.

Edit based on subsequent comment: nowhere is it even hinted at that the C[ET]O was giving them this as their real job.

> All of the hand-wringing in the article about estimation misses the point entirely.

There's no hand-wringing.

Your comment amounts to “you’re wrong!”, which is really hard to engage with.

Reply on news.ycombinator.com