The Religion of Speed

Our job is simply to work with the shell, to stop holding it back with our thrashing struggles to go faster. Trying too hard sabotages boat speed. Trying becomes striving and striving undoes itself. Social climbers strive to be aristocrats but their efforts prove them no such thing. Aristocrats do not strive; they have already arrived. Swing is a state of arrival.

—Houghton Mifflin, Mind Over Water

I don't understand what you're trying to say. What are the reasons some people can't introspect? Is it even true that some people can't introspect?

you can't measure everything, and choosing what to measure is an editorial decision that introduces bias.

> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.

I don’t really now what customer type that would even be. Is the customer the one controlling the quality or reliability or driving the solution? How would the customer even know you’re “going too fast”? They can’t. They’ll just tell you “everything is half broken all the time, wth?” Is that how they tell you you’re going too fast?

Calling an HVAC tech to fix a broken AC is like an engineer doing a hotfix to alleviate a problem. No one is saying that should take 6 month. A better analogy is expecting the your home builder to build you the house in few days because it’s Texas in August and the sun is too hot outside. Then spending the next 6 years fixing “issues” in the house that was built in a week. Yeah, they didn’t put insulation. Yeah, they run the electrical wiring on the outside. Yeah, the walls aren’t anchored, and plumbing just dumps everything under the house. But at least you’re not in the hot sun.

> Real speed exists. Real speed is what happens when the work is understood, the constraints are clear, the people involved know what they’re doing, and the decisions have been made cleanly enough that execution can happen without constant re-litigation.

I think the article is arguing against speed preventing the kind of planning and alignment that makes smooth delivery possible. Rushing is probably the easiest way to make mistakes that ultimately kill projects, credibility, or at least increase the costs in relational capitol, time and morale. Defaulting to a panicked frenzied state of mind is a perfect way to fail at delivering expedient results.

And consider your state of mind after the tech came over 6 times in a week, each time claiming to have fixed your HVAC but it keeps breaking.

The piece is titled "Religion of Speed" -- in other words speed (or apparent speed) as the guiding principle over anything else.

It says nothing even remotely like "you should take 6 months to do something that can be accomplished in 6 weeks."

And this statement:

"There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast"

is baffling to me.

In my experience (40+ years in software development) I have never had a customer/client that would be in a position to have the proper situational awareness + technical depth to make this judgement call.

And even worse I would guess that if even this was not the case that 95% of the time they would not say you're going too fast, instead they would ask to go faster.

I've experienced enough business-critical incidents (or requests) where people across all seniority are just randomly trying stuff, making a mess, without taking time to coordinate, understand the problem, and solve it. It almost always resulted in more overall time and bigger blast radius than if we did it not out of panick.

OTOH my "slow" (I still did things fast, just not purely for the sake of looking fast) and steady approach always took me less time overall to find a proper fix. I also became known as the person who could always find the best possible fix when there's an incident/time constraint, but I also thought that was systematically bad instead of fixing the culture/process.

It's still faster to take a minute (and deep breath), understand the whole problem (incl. urgency and how that affects your solutions), and then solve it. It doesn't mean you can't keep your customers in the loop and assuage their concerns.

> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens.

Usually by stopping doing business with you forever.

Please define viable solution. It's like a piece of string: how long is it? It's a very subjective statement "6 weeks to find a viable solution" - could just as well be 6 months.

Sure you can deliver something that might seem viable and the customer might also a cycle of updates as the viable solution becomes the solution - but how many updates are tolerated and how bad are the problems in the seventh week?

Sure we dumped waterfall for agile and now we live in a constantly updating world of "viable solutions" ...

The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break. On top of that, because the rate of shipping new features doesn't necessarily match with the rate of usage of said features the moment you'll find out about it will not happen ASAP but probably sometime later, making it even harder to truly know if going fast is the right thing to do in the moment.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

load-bearing this load-bearing that

The other project will either peter out, because they made no sense from a product point of view or because leadership lost interest. If they’re simple, can likely be done quickly with the help of AI.

It’s not a pretty answer, but AI has helped me cope with this kind of situation much better than in the past.

It’s not.

What we have now produces quarters/years delays (and in a lot of cases, an inevitable throwing up of the hands to move on to the next disaster/panic). It's paradoxical, certainly, but the Tortoise and the Hare is one of the most accurate fables ever written (why I keep a little tortoise figurine on my desk).

Older generations understood this and go figure, the world was far more stable. We sold that out in favor of speed and quick profit and now we're in for a serious roller coaster ride. And for what? The illusion of having moved faster in the present at the expense of stability in the future.

The inverse would be "The Religion of Slow".

I have never seen or experienced anything remotely like this in the real world.

Have you?

More specifically, winning often means being last. Case in point: Lycos, AltaVista, Yahoo!, Infoseek... then Google. Let others rush around doing your prototyping.

But so many of today's market leaders were late entrants. Sometimes many years late.

If you do go fast and don't deprive your customers of your product but the product breaks and doesn't deliver its intended value, is that a better tradeoff?

Re: AI development, I'd say it's foolish to slow down research, but worthwhile for rollouts to the market. The time that should have been used for preparing people/businesses was wasted on fearmongering campaigns. Now we have a fire hose of slop that's out of control.

Why? Rushing.

Yes, frequent base touching, to ensure alignment on the broad contours is right, but I find yeeting a significant project with one day of planning has a tendency to turn up either requirement gaps, cross team coordination problems, or wildly inaccurate effort estimates (the classic "20 minute adventure" taking a month or two).

Now this can be fine, and in my experience management loves this approach _provided nothing unexpected happens_, but totally loses their shit when your two week effort turns into a 6 week slog with a "not sure boss" estimate for a completion date because the scope and methods are so ill defined