When I was in the early days of my career, IBM still held control in the business world. Open systems were just starting to take over, and local area networks were everywhere. Token ring networks, holdovers from terminal systems and other closed architectures, were still considered the best path forward. They were safe. Reliable. Slow.
Then came this crazy idea called Ethernet, a contention based arbitration method that seemed reckless by comparison. It was unreliable, full of errors, but fast. Guess which technology won? The fast one.
I have been thinking about that a lot lately. That pattern has repeated itself over and over again in the technology business. The safe choice gets studied and debated while the fast choice ships and learns. Speed creates its own kind of safety because it lets you correct course before the consequences compound. When you move slowly, you might avoid one class of mistake, but you guarantee another: the mistake of arriving too late.
This does not mean recklessness. I need guardrails. I need governance and security. Those things are critical, not optional. But I also need speed, and I need it just as much. Speed solves a lot of problems that caution cannot. It surfaces the real issues faster than any planning session. It builds momentum when uncertainty tries to freeze you in place. It keeps you in the game long enough to get good at playing it.
The tension is real. Every time I slow down to add another layer of process, I tell myself it is the responsible thing to do. And sometimes it is. But more often than not, I am just postponing the moment when I find out if the idea actually works. I am trading the discomfort of early failure for the much larger pain of late failure, the kind that comes after months of polish on something nobody wanted in the first place.
“Speed solves a lot of problems that caution cannot.”
Ethernet won because it got into the world and proved itself while token ring was still being perfected. It was not flawless, but it was there, working, improving in real environments with real feedback. The errors got fixed. The reliability came later. But speed came first, and speed made everything else possible.
So I am choosing speed again. Not speed instead of quality, but speed as the path to quality. Not speed without guardrails, but speed as the thing that tells me where the guardrails actually need to go. I will build, I will ship, I will learn. I will move fast enough that the mistakes stay small and the corrections stay cheap.
The next time I am tempted to add another gate, another review, another layer of safety that mostly just adds time, I will ask myself one question: what would Ethernet do? Then I will ship it.
