Hot Take: Don'T provide incident resolution estimates
firehydrant.com
firehydrant.com
The author seems to be missing an (unwritten?) rule of train time estimates.
They are never about when a train is actually expected to arrive. They are always about the minimum possible time until the next train.
They are basically just taking the distance to the next train, and calculating how long it will take to arrive if it goes at normal speed.
The point is not to determine whether you'll get somewhere on time. Trains go slow for all sorts of reasons. Trains provide no guarantees.
The point is to look at your phone and think, if it takes me 4 minutes to get to the station and the train is 6 minutes away, am I guaranteed to make the train? In which case, the answer is yes, because the train will never come earlier than advertisted. You won't miss it. And if the next train isn't for 26 minutes (minimum), then how can I efficiently use that time and not waste time getting to the station early?
This concept is rarely clearly communicated, but it's good to be aware of it.
> The average delay for a Shinkansen train is around 20 seconds. For other trains operated by other railway companies, the average delay is around 50 seconds. In both cases, the average delay is less than a minute. But these average figures need to be tempered with the occasional incident.
And quite the opposite for charter vacation flights which can leave hours earlier than the stated departure time.
Maybe I'm way beyond my expertise, but isn't the train schedules when the train will leave, rather than when it arrives? I've arrived early at train stations many times with my train already being there, idling, and then it leaves on the scheduled time.
Except I guess during delays in the UK when they announce when the train arrives?
> the train will never come earlier than advertisted
This part kind of makes your comment sound like it's not about delays but about the schedules, which I feel like are the departure time, not the arrival time of the train.
It won't speed up to compensate for delays, and it's never going to wait at a station because it's running ahead.
So the countdown clocks don't report scheduled times, they are derived from the train's actual current distance.
Obviously medium- and long-distance rain is different.
The first part absolutely makes sense, but the second one I'm not so sure. They don't have any "Hold at station" or whatever it's called to get some even spacing if they're running ahead of schedule? Seems unnecessarily chaotic.
Doesn't that mean sometimes you end up with 2 or 3 trains coming right after each other?
Kind of -- you definitely can have that happen, but probably never because Train #2 is way ahead of schedule, as it's nearly impossible for any American mass transit system's best case scenario to be any better than "on time". When a parade of trains all at once happens, it's more typical that, if trains are theoretically supposed to stop here at 11:10, 11:20, 11:30, and so on, train #1 would be arriving 29 minutes late at 11:39, followed by Train #2 22 minutes late at 11:42, and Train #3 running 14 minutes late at 11:44. For instance, due to "police activity" or worse, when someone dies by suicide on the tracks (pretty sure those delays are much longer than the above example in that case).
One night, there’s a big storm. The power flickers and goes out. Pretty soon, I get a text from the power company telling me that they know it’s gone and they expect to have it fixed by noon tomorrow. About what I was hoping for.
Then they get it fixed around the time I’m going to bed. I am very happy, because not only was it fixed in a reasonable timeframe, it was fixed sooner than I was told to plan for.
Pad your estimates with plenty of time for there to be complications. If it turns out to be a five-minute fix, then great!
[0] https://scifi.stackexchange.com/questions/99114/source-of-sc...
You get to get rid of service level managers, one of the biggest threats to service availability in my industry experience, and you begin to hate downtime, not tolerate it, and the same for performance degradation, response jitter etc.
Once we deliver in this space, we intend to pivot into using gen-AI to estimate JIRA tick time and give the same realtime information to tasks by auto-generating update comments based on developer activity.
I would've preferred an order of magnitude estimate and confidence level.
Both trust and respect are important, and can be hot issues in public transit.
The NYC subway might be a great class equalizer for many, but much other public transit is firmly for lower classes.
One thing thing even more infuriating and humiliating than waiting for a bus that's 30 minutes late -- like your time and life aren't important, because the only people who ride this bus are those who have to -- is when the bus finally comes, 30 minutes late, and is overfull and not taking more passengers. Then, to the people a driver isn't letting onboard, drivers in some locales will say, "next one is right behind me", whether or not that's true.
Consistent with trust and respect, give the best information and confidence level you have, so people can act on that.
And respect them as equals, to also behave with dignity -- don't try to manipulate their sentiment, by misrepresenting or withholding information.
Withholding information is disrespectful, and is just as damaging to your customers' ability to make alternative choices that would benefit them as providing bad estimates.
The author's chosen example is quite cherrypicked. I can not imagine any scenario for public transit breakdown in which the actual delay would be "5 minutes." In fact, this is so short that there's no reason to even bother with that update if that were true. It's true that promising this completely unrealistic window was detrimental - but that's because it was such a poor estimate.
It's not hard to give expected-case (not best-case!) and worst-case estimates that are in the right order of magnitude, and to communicate in a way that these aren't seen as promises. "The next train will be here in 5 minutes" is the worst possible phrasing, presenting an absolute truth, and it's perfectly reasonable that customers and the response team treat it as such. Again, the solution is ~better~ communication, not ~witholding~ communication.
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.
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.
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.