Rendered at 08:04:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
bob1029 1 hours ago [-]
You can fail a project not because you were technically wrong about anything, but because you burned your customer out by taking 6 months instead of 6 weeks to find a viable solution to their problem. Speed is a feature from the perspective of your customers. There is economic value associated with it.
Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas. This is how a lot of business leaders feel every day. Speed is the best way to meet uncertainty in complex domains. Unless you are fairly sure you can one shot the problem with a single commit, having a process to iterate with some expediency is important to success.
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.
eddythompson80 1 minutes ago [-]
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.
MobiusHorizons 30 minutes ago [-]
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.
ppalata 11 minutes ago [-]
Depends on the organisation as I've seen the opposite (excessive planning without taking action) too. I'm on the speed side of things nowadays because I was usually wrong when I thought that the "work is understood and the constraints are clear".
Thanemate 8 minutes ago [-]
>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.
baliex 4 minutes ago [-]
> The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break
This is what the GP meant. They won’t spoon feed you the “you’re going too fast”, but they will give you other signals that you can, and would benefit from, interpreting as “you’re going too fast”
weiliddat 22 minutes ago [-]
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.
creshal 15 minutes ago [-]
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.
abrookewood 24 minutes ago [-]
This quote is gold: "Do not confuse motion and progress. A rocking horse keeps moving but does not make any progress.”
— Alfred A. Montapert
derefr 3 hours ago [-]
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.
nine_k 1 hours ago [-]
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.
21asdffdsa12 8 minutes ago [-]
The rocket equation of a turtle egg..
derefr 59 minutes ago [-]
I never said the VC's timeline is arbitrary! They're ultimately based in loan interest rates / bond yields / etc — as you say, the "cost of money."
But the timelines that founders and CEOs can end up coming up with for the arbitrary subprojects/efforts they choose to pursue to try to get the company closer to giving those VCs the hockey-stick growth they demand, are much more arbitrary. Mostly in the sense that such subprojects/efforts can often be selected/pursued with no thought to the fact that either the goal is technically impossible within the chosen time budget; or, even if possible, that the effort won't demonstrate results within the chosen time budget, and so will be given up on whether or not it's working (because founders interpret absence of metrics as metrics relaying absence.)
Which is to say: if you can guarantee from before you start that a given subproject or effort will be considered "a failed experiment" — then you'd think it would be obvious that you shouldn't do that one. That you should put it on the backlog of things you can try after PMF + hockey-stick growth, when you have time to evaluate things thoroughly.
But that doesn't seem to be obvious to a lot of founders and CEOs. Many of them spend a lot of their and their employees' time setting off on efforts that everyone in the room basically already knows they'll be cancelling two weeks later, before said effort has had a chance to either succeed or fail on its merits.
gavmor 2 hours ago [-]
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.
eluusive 4 hours ago [-]
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."
m463 3 hours ago [-]
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.
lelanthran 2 hours ago [-]
With racing, in particular, the high accident zones are the corners so that's where extra care is required.
Hence, in racing, the common advice to newbies is "to finish first, first you must finish".
IOW, make fewer mistakes before you try to go faster.
soltanov 44 minutes ago [-]
Being fast is good, if there is not any obstacle on the way)
stackghost 3 hours ago [-]
>"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.
swader999 11 minutes ago [-]
There's decision speed and execution speed. You want to sometimes slow down decision speed and get this right. But then develop fast once the target is selected. Chopping wood - you don't slow down the axe swing - but you better be careful where you aim.
pmg101 19 minutes ago [-]
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."
rglover 4 hours ago [-]
Author, here. Thanks for sharing this!
placebo 29 minutes ago [-]
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
MobiusHorizons 26 minutes ago [-]
Thanks for writing it! It was exactly what I needed to process my frustration with work today.
Zacharias030 1 hours ago [-]
Ironic that parts of the article feel so AI written.
load-bearing this load-bearing that
placebo 12 minutes ago [-]
They don't seem that way to me. I should also note that AI generated content can at times be better than some human generated content
hateful 3 hours ago [-]
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.
aryehof 2 hours ago [-]
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.
novok 1 hours ago [-]
They tend to be a bit anxious and get anxious that your not anxious. There are many that are not like that
baxtr 2 hours ago [-]
A while back, I read that as you age, you tend to slow down not because of your age itself, but because you incorporate all the experience you’ve accumulated over the years into your thinking process. I wish I still had the link or something...
But on the flip side let's not pretend there is no benefit at all in being fast.
For example, there are certain situations where slowing down will only push out decisions you would take anyway. Or: You develop a fully fledged product just to find out you could have found out that no one needs it with a simple mock-up. It's good to know when it's appropriate to be fast and when not.
thearrow 5 hours ago [-]
Felt this in my bones. It’s painful how accurately this describes my current work situation. The pressure comes from the top - leaders that have no idea what they want but they want _something_ to happen NOW. This has only gotten worse with the recent AI thoughtleadering because now the expectation has been seeded that every random brainwave should take at most one hour to implement (given enough tokens).
What can an IC do in an environment like this? If you slow down and attempt to find any clarity, you’re labeled as slow and ineffective. If you cave to the pressure and start slinging slop with the rest of them, you’re just perpetuating the spiral. Genuinely asking - how do others thread this needle?
stephantul 58 minutes ago [-]
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.
aryehof 2 hours ago [-]
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?
nateroling 5 hours ago [-]
I really love the ideas here.
I also wonder if this kind of workplace is a myth. Maybe every business really is a disaster if you look close enough. Or maybe it does happen, once in a while, where a company really hits their stride, but it’s essentially random when they do.
Or, maybe I’ve just been working in disasters too long and I’m cynical, hard to say.
MobiusHorizons 24 minutes ago [-]
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.
latexr 9 minutes ago [-]
> I also wonder if this kind of workplace is a myth.
It’s not.
jongjong 13 minutes ago [-]
This article highlight a huge problem which permeates every aspect of society.
The entire education system is built around the assumption that speed = merit. Any time a person has to sit a test under time constraints, the most significant factor being measured is thinking speed. Not reliability, not creativity; just speed.
I have similar thoughts about 'short term thinking'; this is another religion which has quietly taken over nearly every aspect of the modern human experience.
45 minutes ago [-]
nikhilisvalid 5 hours ago [-]
The rocking horse quote is new to me, but coincidentally enough I've often described the same behavior as a skittish horse. Still very valuable to not confuse motion with progress.
sysfiend 8 hours ago [-]
This honestly applies to current society, not just work.
Even the fun bits of life have been infected with the "speed" thing. We want things, and we want them NOW!
But movements like this come and go, what actually stays are the real things, the ones made with time, passion and love. The rest is just waiting to be forever forgotten.
donatj 5 hours ago [-]
The biggest joke of the entire things is that no one wins by being first anymore. It is not the 1990s.
If anything, you win by being a good second. Facebook won because it watched MySpace mistakes and fixed them.
There is even less value in being first with this AI-driven nonsense. The first mover just creates the template everyone else feeds into an LLM. You do the hard work. Someone else collects the reward.
ChiMan 4 hours ago [-]
>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.
kalb_almas 3 hours ago [-]
Google didn't win because it was last. It was last because it won!
Seattle3503 3 hours ago [-]
It's always in the last place you look.
kreyenborgi 3 hours ago [-]
Xerox to Apple
abrookewood 24 minutes ago [-]
Not sure that this is universally true. Youtube, Uber, Airbnb and others all have massive first-mover advantages.
latexr 6 minutes ago [-]
Google Video, with the might of Google behind it, launched three months before YouTube.
toast0 5 hours ago [-]
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.
endorphine 4 hours ago [-]
A very relevant book that goes beyond the workplace (but also includes it): Alienation and Acceleration: Towards a Critical Theory of Late-Modern Temporality by Hartmut Rosa
yls 1 hours ago [-]
Thank you for the recommendation!
orionblastar 8 hours ago [-]
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.
tdrgabi 2 hours ago [-]
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.
el_io 3 hours ago [-]
Your team won government contract for paper planes?
kfarr 2 hours ago [-]
They measured really really well
simianwords 1 hours ago [-]
If you don’t go fast you deprive your consumers of your product. It’s not clear why that tradeoff is good?
There was a recent petition signed by all major AI labs to slow down AI development. Would this author or you guys agree it’s a good thing?
dgellow 1 hours ago [-]
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
simianwords 48 minutes ago [-]
if they took their time then billions of people wouldn't have access to it for years and decades.
its now super clear that AI is a step improvement in coding, mathematics and other domains. the push for AI has worked out in hindsight.
there will always be people who will parrot the METR study and claim productivity didn't increase but its best to ignore them.
dgellow 42 minutes ago [-]
I don’t see the problem with the technology not being available widely for way longer as it improves. If you think the current situation is a good one you’re not paying attention to how ridiculous the spending has been on the AI bet. What exists now is not sustainable at all, and is already the cause of a massive worldwide inflation. And so far no proof of improving companies ROI.
The AI push is going to damage our societies for a long time
simianwords 30 minutes ago [-]
Why do you think the spending is ridiculous? Do you not agree that we've had a step improvement in coding, mathematics, search/retrieval?
dartharva 2 hours ago [-]
> It’s treated like proof of seriousness. If you’re moving fast, you’re ambitious. If you’re cautious, you’re scared. If you ask to slow down and think, you’re blocking momentum. If you point out that the current plan has all the structural integrity of wet cardboard, you’re being negative.
For a significant portion of corpo office work, this actually holds. Not all work critically needs perfection, most just needs to be done. The trick is to be able to discern immediately which work does not fall into that category and actually needs to be done slowly and carefully.
Barrin92 2 hours ago [-]
"The better work is usually calmer than people expect. It still moves[...] It does not worship motion for its own sake."
There's two architects, Reiser and Umemoto who wrote a book called The Atlas of Novel Tectonics about maybe 20 years ago and a sentence that always stuck with me was "in a moving world the nomad is the one standing still".
The whole cult of speed irony, like digital nomads who only ever seem to camp out in Starbucks, is that they're the most homogenous, like-minded, incapable of independent thought people you will ever meet. They'll tell you they've done 50 things and stayed in 50 countries and somehow seem less travelled than someone who just stood still. Same with the whole productivity software velocity, ship this or that crowd. They always have 20 projects but seemingly never actually do anything, or do the same thing everyone else does.
hotelsacher 23 minutes ago [-]
[dead]
sublinear 6 hours ago [-]
I agree with all of this, but the inverse is just as bad.
Incompetent people will always find a hiding spot through imitation. They will bikeshed and posture like they know what they're talking about. Then they rush anyway at the last minute and still make a mess, or they delegate to someone who will do the same.
The actual problem starts at the top of the organization. All it takes is one bad link in the chain and oversight is lost.
Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas. This is how a lot of business leaders feel every day. Speed is the best way to meet uncertainty in complex domains. Unless you are fairly sure you can one shot the problem with a single commit, having a process to iterate with some expediency is important to success.
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.
> 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.
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 what the GP meant. They won’t spoon feed you the “you’re going too fast”, but they will give you other signals that you can, and would benefit from, interpreting as “you’re going too fast”
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.
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.
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.
But the timelines that founders and CEOs can end up coming up with for the arbitrary subprojects/efforts they choose to pursue to try to get the company closer to giving those VCs the hockey-stick growth they demand, are much more arbitrary. Mostly in the sense that such subprojects/efforts can often be selected/pursued with no thought to the fact that either the goal is technically impossible within the chosen time budget; or, even if possible, that the effort won't demonstrate results within the chosen time budget, and so will be given up on whether or not it's working (because founders interpret absence of metrics as metrics relaying absence.)
Which is to say: if you can guarantee from before you start that a given subproject or effort will be considered "a failed experiment" — then you'd think it would be obvious that you shouldn't do that one. That you should put it on the backlog of things you can try after PMF + hockey-stick growth, when you have time to evaluate things thoroughly.
But that doesn't seem to be obvious to a lot of founders and CEOs. Many of them spend a lot of their and their employees' time setting off on efforts that everyone in the room basically already knows they'll be cancelling two weeks later, before said effort has had a chance to either succeed or fail on its merits.
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.
Hence, in racing, the common advice to newbies is "to finish first, first you must finish".
IOW, make fewer mistakes before you try to go faster.
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 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."
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
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.
But on the flip side let's not pretend there is no benefit at all in being fast.
For example, there are certain situations where slowing down will only push out decisions you would take anyway. Or: You develop a fully fledged product just to find out you could have found out that no one needs it with a simple mock-up. It's good to know when it's appropriate to be fast and when not.
What can an IC do in an environment like this? If you slow down and attempt to find any clarity, you’re labeled as slow and ineffective. If you cave to the pressure and start slinging slop with the rest of them, you’re just perpetuating the spiral. Genuinely asking - how do others thread this needle?
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.
I also wonder if this kind of workplace is a myth. Maybe every business really is a disaster if you look close enough. Or maybe it does happen, once in a while, where a company really hits their stride, but it’s essentially random when they do.
Or, maybe I’ve just been working in disasters too long and I’m cynical, hard to say.
It’s not.
The entire education system is built around the assumption that speed = merit. Any time a person has to sit a test under time constraints, the most significant factor being measured is thinking speed. Not reliability, not creativity; just speed.
I have similar thoughts about 'short term thinking'; this is another religion which has quietly taken over nearly every aspect of the modern human experience.
If anything, you win by being a good second. Facebook won because it watched MySpace mistakes and fixed them.
There is even less value in being first with this AI-driven nonsense. The first mover just creates the template everyone else feeds into an LLM. You do the hard work. Someone else collects the reward.
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.
We've all heard about the "make 100 clay pots", or, sometimes it's photos group vs "make 1 perfect clay pot" group.
There was a recent petition signed by all major AI labs to slow down AI development. Would this author or you guys agree it’s a good thing?
its now super clear that AI is a step improvement in coding, mathematics and other domains. the push for AI has worked out in hindsight.
there will always be people who will parrot the METR study and claim productivity didn't increase but its best to ignore them.
The AI push is going to damage our societies for a long time
For a significant portion of corpo office work, this actually holds. Not all work critically needs perfection, most just needs to be done. The trick is to be able to discern immediately which work does not fall into that category and actually needs to be done slowly and carefully.
There's two architects, Reiser and Umemoto who wrote a book called The Atlas of Novel Tectonics about maybe 20 years ago and a sentence that always stuck with me was "in a moving world the nomad is the one standing still".
The whole cult of speed irony, like digital nomads who only ever seem to camp out in Starbucks, is that they're the most homogenous, like-minded, incapable of independent thought people you will ever meet. They'll tell you they've done 50 things and stayed in 50 countries and somehow seem less travelled than someone who just stood still. Same with the whole productivity software velocity, ship this or that crowd. They always have 20 projects but seemingly never actually do anything, or do the same thing everyone else does.
Incompetent people will always find a hiding spot through imitation. They will bikeshed and posture like they know what they're talking about. Then they rush anyway at the last minute and still make a mess, or they delegate to someone who will do the same.
The actual problem starts at the top of the organization. All it takes is one bad link in the chain and oversight is lost.