5 ms·

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 th

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.

osigurdson 4y ago
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.
- mlhpdx 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - F_J_H 4y ago
    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...
    - doctor_eval 4y ago
      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.
    - robertlagrant 4y ago
      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.
jimmySixDOF 4y ago
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.
alkonaut 4y ago
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).
- martyvis 4y ago
  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?
- peteradio 4y ago
  I doubt a CTO would want to document that they are lying to customers on estimates.
  - Jensson 4y ago
    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.
    - 4y ago
robertlagrant 4y ago
> 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.
- KyeRussell 4y ago
  Your comment amounts to “you’re wrong!”, which is really hard to engage with.
Delphiza 4y ago
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.
chancer 4y ago
Totally agree.
mnw21cam 4y ago
This is a massively insightful comment, thanks. It also describes a world I never want to live in.
- commandlinefan 4y ago
  > a world I never want to live in I have bad news for you, OP...
denton-scratch 4y ago
> 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.
silvestrov 4y ago
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.

osigurdson 4y ago

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.

mlhpdx 4y ago
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.
- deleted 4y ago
  [deleted]
- F_J_H 4y ago
  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...
  - doctor_eval 4y ago
    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.
  - robertlagrant 4y ago
    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.

jimmySixDOF 4y ago

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.

alkonaut 4y ago

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).

martyvis 4y ago
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?
peteradio 4y ago
I doubt a CTO would want to document that they are lying to customers on estimates.
- Jensson 4y ago
  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.
  - 4y ago

robertlagrant 4y ago

> 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.

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

Delphiza 4y ago

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.

chancer 4y ago

Totally agree.

mnw21cam 4y ago

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

commandlinefan 4y ago
> a world I never want to live in I have bad news for you, OP...

denton-scratch 4y ago

> 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.

silvestrov 4y ago

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.