>Rowers have a word for this frictionless state: swing... Recall the pure joy of riding on a backyard swing: an easy cycle of motion, the momentum coming from the swing itself. The swing carries us; we do not force it. We pump our legs to drive our arc higher, but gravity does most of the work. We are not so much swinging as being swung. The boat swings you. The shell wants to move fast: Speed sings in its lines and nature.

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

> * measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect

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?

Regarding "measurements tend to produce micro-improvements", not if you are the first to actually measure stuff in a codebase. There tend to be big fat low-hanging fruit.

> measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect

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

There are many different types of software customers. A company that contracts an iOS/Android developer to build them an app for an upcoming conference is different from a WalMart that hires developers to build them an e-commerce platform which is also different from a software developer who uses an AWS service who is different from the average Windows or iOS users. All are “software customers”. Yet

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

Of course! The article agrees with you

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

> Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas

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.

It seems as if you did not really read the article.

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 like this argument, but I don't think the article argues against taking urgency into consideration. Do you have anecdotes about companies or people that actually ignore urgency?

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.

Don't confuse urgency for FOMO.

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

> viable solution

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

>but the customer will almost certainly let you know when this happens

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

They tend to be a bit anxious and get anxious that your not anxious. There are many that are not like that

Your team won government contract for paper planes?

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.

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.

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

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

Ironic that parts of the article feel so AI written.

load-bearing this load-bearing that

Thanks for writing it! It was exactly what I needed to process my frustration with work today.

I’m in a similar boat. The one thing that seems to help is recognizing when the ask from leadership is genuine, and also sensible from a product point of view. Seize that moment to go fast, and give that your full attention.

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.

If quality isn't valued, then your only alternatives are to try to change that (good luck), accept it, or look for somewhere that does?

I have definitely worked on teams that hit their stride frequently. Definitely not every project or deliverable, but often enough that people got used to it. Unfortunately that was maybe 4 or 5 years ago and I haven't seen it since.

> I also wonder if this kind of workplace is a myth.

It’s not.

You're right and I'd argue that the approach I'm suggesting in this post gets your delivery schedule more aligned with weeks/months than with quarters/years.

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.

I agree with this. When people say speed, they often mean cycle time. How fast can I iterate towards a working solution to a problem? A low cycle time can hide many flaws in your staff and hiring. Experienced developers can go slower and be more deliberate because they know where they are generally headed, so they need fewer cycles to get there.

> I agree with all of this, but the inverse is just as bad.

The inverse would be "The Religion of Slow".

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

Have you?

>If anything, you win by being a good second.

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

I can't think of very many first movers that really had an advantage. Maybe if you get a lot of essential patents. Or you get very lucky with timing and capture a large market nobody noticed wasn't serviced.

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

Not sure that this is universally true. Youtube, Uber, Airbnb and others all have massive first-mover advantages.

I would, yes, given how unsustainable the whole AI industry looks like. It would be way, way better if they could figure out their things out before pushing so hard for the whole software world to adopt their experimental tech

I'm the author.

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.

Thank you for the recommendation!

Surely there is a middle ground between speed being the overriding concern and stagnation. Also there is a question of what makes for better life/work balance and healthier working environment. I guess those things don't matter so much to the ambitious. You can sleep when you die and other mantras guaranteed to cause serious health concerns on down the line.

I agree but I believe it is still well thought out and worth a read, which is rare.

I think the desire for longer term planning is to smooth out the variance.

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