4 ms·

> Hot Take: Cater to the lowest common denominator of customer I disagree. You can either cater to the lowest common denominator, or you can cater to professi

> Hot Take: Cater to the lowest common denominator of customer I disagree. You can either cater to the lowest common denominator, or you can cater to professionals that understand what the word estimate means. If you can't provide an estimate, I'm going to reasonably read that as you not have a good understanding of the issue and are not confident in whatever you are doing. Basically, you are incompetent. Rather than simply not providing estimates, be honest. 1. Provide estimates when you can make them. 2. Provide updates at regular intervals even if nothing has changed. 3. Communicate clearly so people waiting can take appropriate action. An estimate of 2-3 hours is different from an estimate of tomorrow. The number of times power has gone out, knowing this made a big difference. Even when the estimate wasn't accurate, it helped make things more comfortable. And I appreciated every time having that estimate.

sjsdaiuasgdia 2y ago
This is the way to real trust between customer and provider. Enabling your customers with real info that can drive their decision making tells them you care more about how they're feeling the impact than how your reputation might be hurt.
xp84 2y ago
> 1. Provide estimates when you can make them. When one is super confident, for instance, if someone screwed up DNS and you know everything will be resolved exactly 300 seconds from the time it was corrected, because that was the TTL on the bad record... That's when I'd be happy saying "Service will be restored to normal at 3:15PM." When you're not sure if a fix you're trying will succeed or not, that's not the time to say "It'll be resolved in 15 minutes." That assumes that the current plan will fix it, and now you're just setting up 'future you' to look foolish when they have to post again to retract that promise (and worse, possibly make up another estimate that may also be wrong). As a general rule I'd say not pretending to have knowledge of the future is humility. > I'm going to reasonably read that as you not have a good understanding of the issue and are not confident in whatever you are doing. Basically, you are incompetent. I envy the person who has always understood exactly what course of action they should take -- and exactly how long that fix will take -- before they've had even a few minutes to investigate the problem! What a perfect tech stack and perfect knowledge that person must have. They probably don't have any downtime in the first place though, since they know every bit of their application's state at all times anyway.
- jasonlotito 2y ago
  > When you're not sure if a fix you're trying will succeed or not, that's not the time to say "It'll be resolved in 15 minutes." Yes. That's what I said: Provide estimates when you can make them. > As a general rule I'd say not pretending to have knowledge of the future is humility. Yep, never suggested otherwise. Which is why I would never have said what you said above. > Service will be restored to normal at 3:15PM We expect service to be restored by 3:15PM. > It'll be resolved in 15 minutes. We'll have an update in 15 to 20 minutes. Both of your statements lacked that humility. > I envy the person who has always understood exactly what course of action they should take -- and exactly how long that fix will take -- before they've had even a few minutes to investigate the problem! What a perfect tech stack and perfect knowledge that person must have. They probably don't have any downtime in the first place though, since they know every bit of their application's state at all times anyway. Your envy is appreciated. I've never needed the knowledge you think I need to provide estimates on either when I think it will be fixed, or when I'll have an update. That you think that's required is a bit troubling. But hey, you don't have to provide updates, estimates, and can continue to only provide 100% assurance with second level accuracy all while ignoring customers needs.

sjsdaiuasgdia 2y ago

This is the way to real trust between customer and provider. Enabling your customers with real info that can drive their decision making tells them you care more about how they're feeling the impact than how your reputation might be hurt.

xp84 2y ago

> 1. Provide estimates when you can make them. When one is super confident, for instance, if someone screwed up DNS and you know everything will be resolved exactly 300 seconds from the time it was corrected, because that was the TTL on the bad record... That's when I'd be happy saying "Service will be restored to normal at 3:15PM." When you're not sure if a fix you're trying will succeed or not, that's not the time to say "It'll be resolved in 15 minutes." That assumes that the current plan will fix it, and now you're just setting up 'future you' to look foolish when they have to post again to retract that promise (and worse, possibly make up another estimate that may also be wrong). As a general rule I'd say not pretending to have knowledge of the future is humility. > I'm going to reasonably read that as you not have a good understanding of the issue and are not confident in whatever you are doing. Basically, you are incompetent. I envy the person who has always understood exactly what course of action they should take -- and exactly how long that fix will take -- before they've had even a few minutes to investigate the problem! What a perfect tech stack and perfect knowledge that person must have. They probably don't have any downtime in the first place though, since they know every bit of their application's state at all times anyway.

jasonlotito 2y ago
> When you're not sure if a fix you're trying will succeed or not, that's not the time to say "It'll be resolved in 15 minutes." Yes. That's what I said: Provide estimates when you can make them. > As a general rule I'd say not pretending to have knowledge of the future is humility. Yep, never suggested otherwise. Which is why I would never have said what you said above. > Service will be restored to normal at 3:15PM We expect service to be restored by 3:15PM. > It'll be resolved in 15 minutes. We'll have an update in 15 to 20 minutes. Both of your statements lacked that humility. > I envy the person who has always understood exactly what course of action they should take -- and exactly how long that fix will take -- before they've had even a few minutes to investigate the problem! What a perfect tech stack and perfect knowledge that person must have. They probably don't have any downtime in the first place though, since they know every bit of their application's state at all times anyway. Your envy is appreciated. I've never needed the knowledge you think I need to provide estimates on either when I think it will be fixed, or when I'll have an update. That you think that's required is a bit troubling. But hey, you don't have to provide updates, estimates, and can continue to only provide 100% assurance with second level accuracy all while ignoring customers needs.