> All else being equal, the fastest company in any market will win.

All else is never equal when speed is the driving factor. I have never seen a company execute well while pressuring for speed.

It's significantly more important to think about systems. What is the cooperative source of your speed? What are the barriers to making good product quickly? What allows us to make faster decisions?

Invariably, without fail, unequivocally, the answers to these questions—which are sources of speed, quality, and market fit—lie in the systems that compose a company. Not systems as in slow methodical heavy processes, but systems as in a clear understanding of how things are connected and how to continually improve how they work.

Start with systems, then you can go fast. It's ludicrously dangerous to put the cart before the horse. Granted, much of this article dives into detail on how to make things run smoother in order to go fast—that's great, but if you make it the primary focus, imagine how fast you could go.

Speed... a noble goal, but as W. Edwards Deming said, "By what method?"

What's being said isn't necessarily wrong - but it's a moot statement; all else being equal, the best governed company in any market will win.

This reminds me of a t-shirt I have. It has a version of The Tortoise and the Hare story on it. The tortoise has an arsenal of weapons on its shell and the hare is laying face down with smoke coming from the would-be holes that the tortoise caused using his weapons/tools.

In essence, speed isn't the top leading metric, it is having the proper tools and resources available and utilizing them as efficiently as possible - ergo, all else being equal, the most efficient company in any market will win.

In a market with rapid growth and technological change, sometimes it can even damage your prospects. For example, MySpace found themselves dominating the market while it was still small, and for whatever reason, wasted the opportunity. Facebook learned from their mistakes and took control of the market MySpace had helped to create.

Speed incites action, which accumulates knowledge.

I think that is what the article is getting at, if you were to boil it down into one blurb.

Not even close.

Apple was WAY late to the MP3 player party. AltaVista was way ahead of Google, but DEC marketing ("DEC has it now, but you can't have it.") couldn't sell water to a man dying of thirst in the Sahara. Android had far better and faster competitors, but it brushed them aside.

In addition it is well documented that the first company in a category takes all the arrows while the second company makes all the profit.

Things rarely need to be done that fast.

The other MP3 players couldn't copy Apple or market fast enough. Google has kept up their search dominance by iterating quickly; AltaVista felt as if search was a solved problem.

Difference is the starting point. You can start from any point, but you need to be fast.

If you think of the iPod as an MP3 player, sure. But I think Apple tapped a brand new market with the iPod: the "fashionable gadgets" market. Arguably, that's the main reason it was incredibly popular.

The iPod was popular because it was the first practical MP3 player. Take a look at the competition:

http://www.examiner.com/list/five-portable-mp3-players-that-...

You've got reasonably sized devices that could hold a few dozen megabytes, or impractical tanks that had real capacity. The iPod was the first to do both. It also had a user experience that was quite painless.

Eisenhower put Patton into play when a part of the operation needed speed and violent execution. Eisenhower took Patton out of play when it didn't.

LSG - https://en.wikipedia.org/wiki/Loss_of_Strength_Gradient

"Patton", the movie, shows it from Patton's perspective.

"You will not find it difficult to prove that battles, campaigns, and even wars have been won or lost primarily because of logistics." - General Dwight D. Eisenhower

More detail than you probably want - Gen. George C. Marshall's comments after the war.[1] See p. 8 of the transcript.

A more modern perspective - "Moving Mountains", a book by Gen. Gus Patronis, head of logistics for Desert Storm. How the U.S. Army built up a massive force in the middle of nowhere and then won a war in four days. This is a useful perspective on "speed". If you want to go fast, having massive resources available makes it work.

[1] http://marshallfoundation.org/library/wp-content/uploads/sit...

It's hard enough to get proper time for planning technical projects without this kind of crap.

Guess what, planning time does save time and lowers your cost of ownership. ROI-wise, planning time is the best gift you can give your project.

But... then someone is like, "Speed, I hear speed is good... move faster. Dependencies... fuck 'em... I don't understand 'em anyway so fuck 'em. Let's just go as fast as we can and we'll worry about everything we should have worried about up front over the next few years after all our devs quit because they're tired of working on shitty code that was rushed through."

This article so rubs me the wrong way. "Technical debt? What's that?!"

Anything worth doing, is worth doing right. To the best of your ability. Doing things right takes time. Take your time, do things right.

This is someone who has either not only drunk the kool aid, but is already on their way back from the store with another carful of it, or someone with very limited experience of business. I have worked for many, many businesses whose competitive advantage is not being fast, but in this author's view, being fast is the only advantage there is. Competence, cost, quality, reliability? Just fairy tales.

However, part way through this breathless look-at-me, the author clearly describes the advantage of a simple price scheme (We offered one price of $50 per employee per year... We just wanted to be able to tell people, “We may not be free, but we’ll be the simplest decision you ever made.”). This actual advantage is then smothered under the breathless fact that it was decided quickly; he made a good decision quickly, and that it was done quickly is apparently more important than being right. What a mess of text, and a mess of self-contradiction. Clearly, someone has decided the correct answer, "speed", and is now trying to mash evidence to fit.

I enjoyed the 'GM is slow' comment. While that may be true in terms of innovation, it is the opposite when it comes to manufacturing. I've worked in those plants where the 'speed above all else' sentiment is eerily similar to this article, and is largely the reason I chose a different career path.

The one thing I take away from this is the accountability perspective. It's ok to ask why things will take the amount of time projected. Things often do get tacked on that don't need to be.

> All else being equal, the fastest company in any market will win.

So, that's why we all still use AOL? And why Microsoft never had to worry since it built Office? Why PayPal squashed Venmo? The point is really that all else are never equal. Speed to market is A factor, but it's not the only factor, or even the most important factor today. Look at Box, vs. Dropbox, vs. Copy, vs... The market is big enough for multiple identical services. Users pick the one that works the best for them.

And I certainly agree asking questions is a GREAT way to start documenting all the stuff that has to go into a project. I'd add a bullet point, "Way more hours than I want for... explaining why setting up Vagrant is important... explaining why unit tests save time, for the 900th time... explaining why QA is needed..."

Things don't often get tracked that ought to be, but PLEASE do not send more meeting requests to your entire dev team asking them to justify to marketing or sales why we need the basic steps we ask for.

(This article hits a bit close to home today, as I'm literally in a meeting with 15 people where only 2 people are talking and I literally just had to defend QA marketing guy who clearly doesn't get it. And the topic... "How we can organize our team to be more efficient.")

AOL might have been first but then they just seem to have quit. They didn't keep up with the times. Their whole paradigm was terrible out of date. They were in the ISP market but extremely slow and it killed them.

Lotus 1-2-3 was before Excel but Lotus took a long time to release new versions while Office did not. You'll notice that MS isn't super quick with releases now, but they do churn out new versions with some regularity.

Business doesn't have a finish line so companies have to start and stay fast. This is why technical debt is a problem; sometimes you need technical debt to get something out the door fast, but it will slow down future releases so you need to get it under control.

There are many ways to get ahead. Bureaucracy sucks.

But just saying, "Speed man, speed... that's the good stuff..." It's only true when it's paired with customer demand, high quality, and all the other things users demand.

ICQ vs. AIM? I can't actually think of a single example of a product being first to market and that making them better than the challengers. Getting to market... no question, that's great. Blowing away what exists in the market... that's what gets you customers. So inherently being first isn't advantageous since you're opening the door to others taking your idea and improving on it.

I'll say again, build the best thing you know how to build... if you don't build it great, people will notice. Nobody wants a quick and dirty solution once they see the well-designed, delightful, secure, improved, etc. solution.

Facebook > MySpace

Instagram > Facebook

Reddit > Digg

Any modern software language... nobody is like, "Man, give me some ASP VB, that came out before Rails or Node... it must be better." We evolve. Speed, it may be a factor. But what you build has to survive past launch. Do your best to give it the legs it needs... and maintain it as vigorously as you can. ROI is in planning.

tl;dr version: There is an opportunity cost for the time you spend in decisions. If the decision is really the most valuable use of that time, take the time to make the decision. If not, make the best decision you can in the next 10 minutes, and move on.

A startup is a system for turning technical debt into financial equity. So long as the founders and VCs make their exit event, it doesn't matter what happens after that.

First mover just means you are first to a new market. Hypothetically, there could have been 10 years of product development behind your first mover advantage.

Moving fast, as I see it, is not becoming that huge, slow organization (think GE), that has so much bureaucracy baked-in nothing ever gets done.

Most decisions really don't require the level of debate they're given. The author is pointing out that a lot of the decision making process is influenced by shit that doesn't have anything to do with the actual decision.

Also it should be considered that if a small business makes a lot of ill-considered, fast decisions, chances are they're no longer in business.

The main difference that was causing problems for American pilots was that the planes they were fighting against were more maneuverable. It turns out that greater maneuverability naturally led to a faster and more responsive cadence in combat, leading to MiG pilots gaining the upper hand in encounters.

The two theories that came out of this study were Energy-Maneuverability Theory and the idea of the "OODA loop". As it happens, OODA loop theory is generally applicable in many situations outside of aerial combat.

OODA is an initialism standing for: Observe, Orient, Decide, Act. It is the fundamental event processing loop for "doing stuff" in almost any situation. The faster one's OODA loop the faster one can respond to changing situations, which translates into huge practical advantages. And the amazing thing is that this is somewhat independent of maneuverability.

OODA loop theory should be well understood by anyone in the tech industry. It's a critical element for the competitive advantages of small startups over big, entrenched competitors. And it's the reason why agile methodologies are so often advantageous.

"Speed" is a crude substitute for understanding the value of feedback-based iteration and the competitive advantage of tighter OODA loop cycles.

P.S. Raw speed is not a substitute for good design, thoughtful engineering, or keeping technical debt under control. It is quite possible to speed yourself right into a wall where you lose agility because of excessive technical debt. Also consider the relative merits of building on good foundations, increasing value exponentially over time versus constantly tearing down and rebuilding disposable structures. Don't confuse busy work with craftsmanship, value doesn't scale linearly with effort.

"Maneuverability" is not the end all and be all of air combat, else we wouldn't have, for example won the air war in the Pacific in WWII. Energy from position (being above the enemy, or diving to gain speed) and from energy–maneuverability theory (thrust to weight ratio plus drag), see also the linked https://en.wikipedia.org/wiki/Aircraft_specific_energy when combined with proper tactics can beat pure maneuverability, especially if the latter is gained at the cost of things like pilot armor and self-sealing gas tanks (Japanese Navy planes were optimized first for range, and then for maneuverability, and were crippled by nonavailability of better engines). The classic tactic for attack is called boom and zoom; per this gaming wiki entry (http://wiki.warthunder.com/index.php?title=Boom_and_Zoom): "Boom and Zoom (also known as BnZ) is the name of a play style that aims to take advantage of a high energy state to bounce the enemy, avoiding any prolonged fighting in order to conserve speed and/or altitude."

Once you factor that in, the only bad match of the war was the F-105 and the Mig-21. The F-105 was designed and used for ground attack, so if Migs were allowed to get at the bomb laden F-105s the results were frequently not pretty.

That happened a lot for a bunch of reasons, e.g. because the Air Force's F-4s were still using a WWII era flying formation, which reduced their fighting power to 1/4 of the Navy's. F-4s were for a long time only equipped with missiles, which was very bad because the Air Force's models of them were particularly unreliable in the field, the fact that almost all the planes in the air were ours meant visual recognition was almost always mandatory, so the intended scheme for Sparrows couldn't be used. Their pilots were in a 1 year rotation schedule, replacements were poorly trained, and didn't have the floor in competence the Navy required for carrier landings.

By comparison, the Navy's Sidewinders were better (both it and the Sparrow were Navy missiles, ditto the F-4, the Air Force really didn't like this and that's supposed to be one of the reasons they kept with their WWII formation, couldn't admit the Navy was also right about that), they started out with guns + Sidewinder pure dogfighter in the F-8 Crusader, they trained for air combat (e.g. the famous Top Gun school).

By comparison the North Vietnamese tended to follow Soviet doctrine, which depended on precise control from the ground (which they had, since this combat fought over North Vietnam), the Mig-21 in particular was iffy for dog fighting due to terrible visibility from the cockpit (some NVAF pilots in fact preferred earlier Mig models), and they used two general tactics: for offense, hit and run, trying to get bomb carrying planes, for causing them to drop their bombs so they could maneuver was a win, and a defensive one where they flew in a wheel which was very dangerous to attack.

To finish, for air combat, getting in an tight dogfighting OODA loop represents a failure of some sort in the first place, Energy-Maneuverability Theory was an implicit thing going back to at least WWII, and unlike the Air Force, given all the limitations in place the Navy did rather well, although it tended to burn out its pilots because they didn't have enough to rotate them, and the carrier landing requirement strictly limited getting replacements. And OODA loops don't matter for two very common and important types of "dogfights", where either the target never realizes it's under attack before being fatally wounded, or the attack forces it to abandon its mission and flee.

That's not to say the article isn't right. Maybe speed really does win. But if that's true, we might be stuck with terrible software forever.

Most people can't tell the difference here, and failing to do that is deadly. You can lose a lot of good engineers by forcing too much crunch, and that can kill or significantly delay projects.

This happens not rarely in game development.

"I’ve long believed that speed is the ultimate weapon in business. All else being equal, the fastest company in any market will win.". The irony that the authors two previous employers were Google and Apple. Both of which are massive companies that were (and are) famously never first to market with anything.

"All things being equal": it's the company with the deepest pockets and the best PR. Which is not equal.

All else being equal, the best-funded company will win. All else being equal, the company with the catchiest name will win. All else being equal, the company with the best product will win. All else being equal, the company with the best-advertised product will win. All else being equal, the company with the most stories being written about it will win. All else being equal, the company with the better cafeteria will win. etc.

all true statements. don't mean much though...

Yea, no doubt. Don't even need an MBA to see that. If you have two equal competitors, the first one to market has a useful head start.

I think this article is what I would call aggressive trolling; scoring points by 'thinking different'. But essentially this is not more than standard knowledge, repackaged as a hype laden pseudo-intellectual conversation meant to score points.

I'm not necessarily an evangelist of "Move fast and break things" but it's a good mentality to speed up the feedback loop and avoid sinking a lot of time into stuff people don't want (even if it's really well engineered).

Now compare that to the the number of products that fail because a competitor released a more stable and usable version. IMO that is far more common.

Not to mention there are many techniques to speed up the feedback loop. You don't have to do a full release to get feedback.

Also a commonly cited zen story:

Eager Student asked: “How long will it take me to be enlightened?”

“Ten years” said the master.

“What if I work twice as hard?”

“Twenty years” said the master.

The zen story also sounds like complete hogwash. All else equal, if you work harder, you will improve faster.

Quick! I need a vast majority detector.

Setting a deadline for deciding something sounds good to me, but the above is some kind of puzzle.

In the question "which ones?", don't miss the point of the article - that we spend far too much time making most decisions.

I'm currently on a two-week deployment cycle. It's not only annoying to wait but it's also dangerous. There have been several incidents where the code that broke something was committed a whole week or two weeks before! Worse still is that we're deploying two systems at once and usually we're patching the systems at the same time. So you have a perfect storm of bad things that can happen with multiple causes. Faster means you see the problems sooner.

Yes, there is: https://en.wikipedia.org/wiki/Project_management_triangle, and to have both requires more money (resources).

This article also doesn't seem to have been written by an engineer. I'd love to get a more technical perspective on how to move fast.

In short, you need to know what you are doing and why.

Speed is important. Patience is important. Stepping back and smelling the flowers is important. It's not about fast or slow. It's about right, and you can't be right all the time if you're stuck in the habit of zooming along all the time.