Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • The longer I spend in my career the more obvious this is to me. Unfortunately younger colleagues don't always have the maturity to have also realised this, which can be a problem if they end up above me in the management chain!

    I try to kickstart reflection on this by saying things like "Some of the biggest impact I've had has been the code I chose not to write."

  • Author, here. Thanks for sharing this!
  • Thanks for writing it! It was exactly what I needed to process my frustration with work today.
  • Ironic that parts of the article feel so AI written.

    load-bearing this load-bearing that

  • Reader here. Thanks for creating this. Totally resonates with my own thoughts, so if I'm wrong at least I have company :-)

    I do have a suggestion for those who object to this line of reasoning: Follow the 5 why's to try and get to the source of your own reasoning and see whether it still makes more sense - in the sense of whether you end up adding to the common good

  • Impossible to disagree with the author, and yet something seems missing in the discussion... Let me check:

    Ctrl-F, 'deadline'

    0 result.

    Oh, yeah, that's what missing from the discussion.

    And without any trolling, I'm curious about what the author would have to say about this matter.

    Not all "need for speed" comes from a vacuum. Is it always legit ? Should we push back ? Sure.

    Do we always meaningfully, practically, realistically have a choice anyway ?

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

  • Most deadlines are artificial and self-inflicted. The author is not advocating that if you have a literal fire consuming half your home that you should sit down on the floor, ponder your possibilities, schedule a few calls for discussion, then send a few messages on Slack to decide what to do; of course some things are more urgent than others. The author is calling out a “speed cult”; they’re not making an absolutist argument but the exact opposite, advocating for “the discipline of judgment”.
  • I think the author is having a kind of idealistic, relaxed view of work. Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.

    These are obvious lessons of agile management. Even if they are not absolute, maybe that post is meant as some kind of relative statement, in general, speed is a good thing. More speed than you are comfortable with.

  • This quote is gold: "Do not confuse motion and progress. A rocking horse keeps moving but does not make any progress.” — Alfred A. Montapert
  • Speed is not velocity. A person jumping off of a 100 floor building, will have a lot of speed, probably think they are flying!

    Velocity comes from being thoughtful. Thinking about thousands of dependencies and navigating towards the end goal.

    In big corporations, neither speed nor velocity matter. Its mostly garbage products. There will be deadlines and these are planned for Annual Performance Review. There will always be some success story (or the milestones changed) to show that the people favored by the leaders are 'delivering' on the right 'metrics' and they need to be richly rewarded. And also this 'success' is because of the excellent 'stewardship' by them, therefore they must also be rewarded.

  • We did a paper airplane test in 5th grade. We split into teams and made them like McDonnell Douglas, etc. First, we saw how many airplanes we could make and then how far they flew. Everyone was rushing to get the planes made, but I took my time and measured them to make sure every fold was done right. My planes flew the farthest, and our team won the government contract. The moral of the story was that haste makes waste.
  • There are anecdotes supporting almost any point.

    We've all heard about the "make 100 clay pots", or, sometimes it's photos group vs "make 1 perfect clay pot" group.

  • Your team won government contract for paper planes?
  • I realized early on that sometimes management thinks that if you don't look stressed than your not taking it seriously enough. Phrases like "I don't feel that you have a sense of urgency" really messed with my head back then.
  • They tend to be a bit anxious and get anxious that your not anxious. There are many that are not like that
  • I have had that exact same thing said to me. didn't so much mess with my head as make me think someone with such a poor grasp of appearance vs reality had no business being a CEO.
    by zem
  • Real management is about making decisions, most typically about how to apply limited resources amongst competing options.

    But a lot of Managers (and the managed) think it is about managing people. Their real role is “Overseer” not Manager, and in that role their real task is to ensure you’re working harder.

  • From an engineering perspective slow is smooth is fast, but from a sales perspective slow is smooth is slow. If you quote superior quality with 6 months later delivery your competitor will get to sign a contract that could very well last 5-10 years and comes up just so rarely. Missing out on that contract doesn't always mean you get to focus on other projects, it could mean you have to fire whole teams of people that you don't have anywhere to assign anymore.

    From my perspective a failure point is when companies do delegate time to make things correct, but demand results from the get go. Billing and tracking becomes weird for them if you work on infrastructure, design systems, component libraries, system design etc and you have nothing to show for after 6 months or a year. "But the future development will be super fast" doesn't fly past upper management unfortunately.

  • Sure, it seems true for a short period. But rushing something forward means you cut corners and that catches up with you over time. Anyone who has ever had a sales team asking for special features to be hacked into a product with little or no time for any proper architectural considerations or releasing before all the testing is complete in order to “get the big deal” has felt this. Yes, the other side may win a deal, but rarely the war.

    That said, I’ll very deliberately make the distinction between going slow in a thorough and responsible way from just being slow in an incompetent way. Market forces are real and a consistently slow team gets canceled. To put it another way, sometimes slow is smooth and smooth is fast, and sometimes slow is just slow. The trick is knowing the difference between.

  • Urgency can definitely be real, but you can't actually go faster by not planning. There are plenty of cases where just a few hours of planning could have made a huge difference, preventing weeks of thrashing and rework.
  • Use to work with a pretty jaded Army Colonel. He'd often say: "even periodic motion looks like progress on short enough time scales." And also, "Slow is smooth and smooth is fast."
  • >"Slow is smooth and smooth is fast."

    When I was in basic the instructors repeated this incessantly. About two thirds of the way through what Americans would call OCS they made us walk into "the gas hut" which is a concrete bunker-like building in the middle of a field near the rifle range.

    Inside the hut is a hot plate with an old shitty skillet. Inside the skillet are pellets that give off tear gas when heated. You walk into the hut and immediately get slapped in the face by what I might charitably describe as the worst onion-eyes you've ever experienced, multiplied by at least 100.

    But the training is fantastic because in that moment as I was standing there with my eyes scrunched and burning, I unconsciously whipped out the gas mask, put it on, did the proper drills with the filter and decon cream, and had no conscious recollection of having done so. The urge to rip off the mask and rub your eyes is overwhelming. The instructor told me "good drill" and sent me on my not-so-merry way.

    Same thing with mag drills. You slap that forward assist without even thinking. Anyways, slow really is smooth which really is fast.

  • I remember learning to race on the track.

    In the sharp turns, you feel like that's where you should try really hard to go fast. Because you're going so slow!

    But really, it makes more sense to slow down MORE, be smooth and controlled and get the turn right. And you'll get a better drive and be faster later. slow in, fast out.

    also, the math wins - going 1mph faster on the 1/4-mile straightaway works out better than going 1mph faster on the 100-foot slow turn.

    by m463
  • The religion of speed is the religion of VC investment backing, because VCs have set time horizons for delivering returns to their own investors. You can only get their interest if you can make them believe you can deliver 10x growth on their schedule.

    Committing to that schedule — and really believing in that commitment — is what turns someone into the sort of person who sets arbitrary project timelines that disregard technical practicality, and then kills projects when they fail per those arbitrary timelines.

  • It's not just technical practicality that's disregarded, it's nearly everything valuable about anything that's worth doing. It's why VC is a cancer on the world.
  • I like setting arbitrary project milestones or timelines. They don't have to kill the project, but it's good to cast efforts in relief against external developments.
  • If you want to feel real urgency, try working at a company attempting to bootstrap without VC funding. Unless your company is very lucky to strike gold early on, the pressure to deliver fast and get money coming in is even more real. Everyone wants to start getting paid real salaries instead of eating ramen noodles. Everyone wishes they could hire a few more people to spread the workload around.

    Startups are very hard, period. In my experience, the ones that get VC funding are a less stressful than those that don’t because you start with a generous buffer of money in the bank and you have investors who might backstop the company’s bank account if you run out. They do want returns, but bootstrapped companies also want returns too. That bootstrapped founder who sacrificed potential earnings for years to get their startup off the ground wants employees delivering fast, too.

    It’s not a religion or cult. It’s the reality of startups. Something is risked to start them and the people who risk it expect a larger reward than they would have received. For VCs, that larger reward has to be better averaged returns than investing in the stock market or other investments. For founders, that large reward needs to be larger wealth than what they could have gotten working for FAANG. The pressure comes either way.

  • Venture-backed companies is an extremely small subset companies when you look at this objectively.

    The alternative is debt financing, and let me tell you, there's a lot more deadlines and urgency in there.

  • These timelines are not arbitrary. They are dictated by the cost of money (for the VC). They have little to do with the target market situation, and totally don't care about technical considerations. They only care if your profits, or at least revenue, or at least market share grows fast enough. If it does not, they write off their losses and liquidate the company.

    This is the fear that dictates the damned speed™: either you go up insanely fast, or you die. If your goals do not align with this approach, do not take VC money. If you want to develop things without haste, only join a startup with a proven PMF and insanely goos sales team, which takes care of hockey- stick growth so that you can concentrate on quality.