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" ...
> 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.
Yet - not planning effectively is also a huge problem.
Not arguing against speed, just poorly-executed speed.
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.
Here it is. It is done.
Great, now we put it on a shelf and ignore it for 6 months.
From my perspective, every time.
Edit: the last time this happened to me, they later revealed that it was going to be shelved for a year.
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”
> 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.
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.
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.