Hacker News new | ask | show | jobs
by rglover 1 day ago
I'm the author.

Deadlines are artificial constraints (typically, some deadlines are unshakable—eg "we have to launch the payload when conditions are clear") that, imo, distract from the actual goal or task at hand.

Sadly, a deadline is more often used as an excuse to rush, and not because the deadline itself is of material consequence (e.g., meeting a vendor's production deadline is unshakable).

Instead, the more common reality is that someone in a position of limited agency uses the deadline as a sort of mental whip. This may get a result faster, but rarely is the work that was rushed solely to meet a deadline the best the team/individual was capable of. More often, you get a broken mess that now necessitates wasting more time later cleaning it up (this is the part I think traps a lot of people; it's a stealing from Peter to pay Paul situation).

When I've discussed this in the past, most misinterpret my point through too binary a lens. This isn't some hippie dippie idealist "just, like, do whatever maaan" kind of take.

Instead, it's a suggestion for those in an environment that's always "moving fast" but rarely if ever hitting the mark. This leads to papering over the obvious problem: the team or individual responsible for the bad work is rarely someone of pure incompetence and more often is just under completely imagined pressure that doesn't exist (beyond the confines of the minds involved).

I'm not naive, of course you can't blanket apply this line of thought to every situation (especially in corporate America). I'm more so angling at "have you considered that rushing is the reason everything you ship falls apart and doesn't meet its goals?"

Case in point: FedEx deployed some new dashboard software for their employees doing package handling. I came in to drop off a MacBook I was sending in for repair. While scanning it in, the system just broke (in the "it ain't doing the thing no more, ma" sense). The clerk was able to manually scan it, so skipped the system and gave me a receipt. A week later, Apple never got the laptop. I start calling around frantically, now having to do work I shouldn't be doing. It was determined that the label printed (the one I got a receipt for) wasn't the "correct" label to scan (that was hidden under another label already on the box). This led to weeks of unnecessary phone calls re-explaining the situation to various employees, now arguing with me about a mistake FedEx made.

Eventually, Apple called it a mulligan after a month and sent me a new laptop.

My point: whatever caused the FedEx team to rush had a ripple effect of wasting inordinate amounts of time and costing Apple $5K. Why? Because whoever built that dashboard software rushed and made an otherwise simple idea into a half-working, frustrating mess. This is the type of situation I have in mind when I tell others "we need to slow down."

Like I alluded to in the post, it's not about moving slow as a matter of psychological comfort, but as a means to avoid creating messes in the present (and future) in service of an arbitrary deadline that's less rooted in necessity and more so in fulfilling the ego of whoever is in charge. That's a tough pill to swallow, I get it, but like most things, the actual problem isn't the process or reality, it's the human mind convincing itself of things that just aren't true.

1 comments

Fedex Returns is just about the least competent product technology entity I've ever encountered and this migration was a garbage fire even by their low standards. I doubt if they could have gotten it right if they spent 10 years on it, and its entirely possible they did do that.