Most of the time, yeah that's how it plays out; it's easy to start from a blank slate. But where I differ is that I'd claim that most early startups don't even have much velocity. They don't actually move with speed, but with haste. All possible corners are cut. As the team scales, the debt comes due and forward progress stalls. What strikes me about this article is the forethought that was put into the engineering from the start - this is a company that really does have velocity and wants to maintain as much of it as possible.
> They don't actually move with speed, but with haste. All possible corners are cut.
This sentence strikes me at my trauma center.
The company I'm in is at the critical phase of startup. 4 years down the road of hypergrowth, the knowledge gap and quality gap is apparent. But then I realize that corners are cut because of a lack of expert in the area whose authority is recognized.
Most experts and brilliant minds have the same idea about the corner cutting. When foundations are designed to be reliable, velocity may jump exponentially, they know. Reliable isolation, version gating, and enablement over service is how they should move, they know. Product design and physical constraint has at least one coupling string, they know.
But these people aren't given the authority, not invited into the room where the decisions are made. In the end, those who bring the immediate money prevail over those who bring mere potential of 10x more money.
As the article said, hire the best engineers. But what the article miss is to hire the best engineers who is invested, can thrive in the politics of startups and use the attained power to bring everyone to success.
One thing I think can really help is to have two different modes within the same team. You move fast and cut all corners and rapidly iterate when you have an idea by building a prototype, with the only goal being maximizing the speed at which you're learning if/what works and what does. Then you basically throw away all that prototype code and build the feature properly with careful attention to code quality and complexity, testing (++) - since now you actually know what you're building and that it's likely a good idea.
Rinse and repeat, so that you only have prototype code where you're actively learning, to be immediately replaced by properly engineered solutions or wiped away (with the same haste you used to create it initially - no "rarely used, badly engineered" features should stay in your codebase due to priority / resources / attention constraints).
The biggest challenge I've had with this approach has been building and fostering the trust and culture needed to have everyone truly go "all in" for both aspects/modes of working. This breaks down quickly if you have managers or PMs drive engineering to keep the prototype code in for longer, or if engineering insists on not cutting corners during the exploration/prototyping phase...
England's King Charles II chartered the Hudson's Bay Company in 1670. It is considered by many to be the world's oldest continuing commercial enterprise. The company outfitted fur traders for expeditions out of Hudson Bay in Canada. In this part of Canada, referred to as "north of summer," having the right supplies in the correct amounts was literally a matter of survival. And, of course, the company's survival also depended on productive—and completed—expeditions. So the company provisioned the expedition's canoes with the necessary supplies for the trip. Then they sent the expedition team a short distance in their canoes to camp overnight. This was a test. The first camp was merely a "pull out," commonly called for many years a "Hudson's Bay Start" (HBS). Said Sir Samuel Benfield Steele in 1874, "[This was] very necessary so that before finally launching into the unknown one could see that nothing has been forgotten, or that if one had taken too much, being so near to the base, the mistake could be easily corrected." This risk reduction technique was not free. It cost the team precious time in a short trading season. They had shipping deadlines to meet. I can imagine them saying "Yes, but we really have to be on our way or we'll miss our shipping schedule."
This sounds great on paper but I have a hard enough time getting buy-in to finish the prototype. I've never seen anyone throw away the prototype and rebuild from the ground up before waiting years and then calling it "V2"
An alternative way to deal with an unreliable prototype is to make a reliable wrapper around it.
Such as paying time in exchange for reliability (e.g. TCP/IP, retry and backoff), disclaimer for unreliable behavior and law-related issues, version gating for file formats/protocols, redundant storages, and killswitches for going rogue-prone machineries.
