The art of speed
Speed is survival
Welcome to this exclusive, subscriber-only edition of TSV. Every week, I share a new entry from my bootstrapper diary along with the lessons I've learned. You can also catch more insights on the TSV Podcast.
Annual subscribers get access to special episodes in the future. I promise (even though I said don’t promise, only demo, I have no choices here)
A personal story
Back in 2019, when I was working at a bank as a researcher, I got called for an absurd mission. At that stage, I was no longer on the trading desk. I had been transferred to what they named the AI Lab of one of the largest French banks in New York. This was the time between my brief stint on trading floors and before I became an entrepreneur. A time when I understood what was a dysfunctional bureaucracy, and why a rogue team of anti-social programmers working in a dumpy office could run circles around corporate zombies.
My unfitness for the role of trading desk operator was second only to my unfitness as a researcher in the AI Lab. It was not about technical skills. I was technically competent, if far from great. The problem was my attitude: an absence of deference, a rejection of authority, and a no-bullshit manner that simply does not work in the corporate middle-office world. It took me years to realize the danger of becoming good at something you do not actually like. In my case, it took me about two and a half to three years. I was not exactly good, but I was not too bad. At some point, I could actually have slipped into the corporate mode.
One I told a friend my fear of staying at the bank forever. His answer: “Do not feel like you are a unique snowflake. You are going to eventually become exactly like the people you work with And they all looked the same because they all became the same”
That is the danger of the corporate world. It’s a twenty-plus years mold turning people into clones.
I earned good money, more than I had ever earned before (not too hard to accomplish). Yet I was asking myself where does money stop making you fulfilled? As a side note, at the time I was still forbidden to have a credit card in France because I was on the banned-list, but that is a story for another day.
Back to the absurd mission, the manager of the team gave me a task: use natural language processing models, the predecessors of modern LLMs before “attention” came into fashion, to clean up typos in manually written text.
The project was quite vanilla. Some operators overseas, often in India, would frequently mistype client tiers such as Gold, Platinum, or Silver. Sometimes you would get “Gaold” or “Platinuuam.” I had a database of thousands of such lines. My job was to standardize them so data analysts could run algorithms on clean data. The type of task that makes you question your whole existence and want to open a pizzeria in Latin America, which I eventually did.
I suggested the obvious solution: do not let people type freely. Just give them a dropdown menu with predefined tiers. Problem solved at the source. Not exactly rocket science.
Instead, they wanted me to build a real-time NLP algorithm that would normalize and correct as people typed. The algorithm itself was trivial, essentially fuzzy string matching. But the real problem was not the algorithm, it was the bank. For a startup, this would be a one-afternoon project. For a bank, it was a six-month to one-year odyssey. Every small change required authorization from multiple layers of bureaucracy. What should have been a two-person task suddenly involved 20 or 30 stakeholders. Among those people, most of them act like parasites who see any deviation from the standard corporate sloth mode as an existential threat.
I was not exactly thrilled wasting my time on such a trivial problem. I was already ready to leave, and no one at the bank was particularly keen to keep me around anyway. So I kindly suggested the upper management to fuck off with that project, knowing perfectly what it would mean for me. Their slowness to react worked in my favor. They did not fire me on the spot. They waited and waited, and in the end I left voluntarily. This is what happens when a big company wants to implement a small change. They cannot because they have to move too many parts. They have natural inertia. They are slow. They are zombies.
And that, dear reader, is the point of today’s piece: speed, and how to achieve it in your business.
Faster you survive, slower you die
I'm not interested in speed for its own sake. Many people go faster to nowhere. I’m interested in speed as a matter of survival. It means going faster because you're lighter and because you focus on the right things.
Let's dig in.
The lack of speed in big institutions is not because individuals are stupid (some are though), but because layers of authorization, committees, and processes trap them. As I moved through different roles, I saw many founders imitating these layers of bureaucracy. Small companies of less than 10 people behaving as if they were giant organisations. Drown in committees, never actually making impactful decisions. Many seed and series A startups are working like bureaucratic dinosaurs.
There are many consequences to slowness, but I think two of them are the most crucial.
The first consequence of slowness is obvious: nothing gets implemented. The second consequence is worse: if your idea is bad, you only realize it six months or a year later. By that time, it may be fatal.
Speed is survival because speed accelerates the feedback loop. It increases the velocity of iteration and improves the quality of processes. Speed is the difference between a company that wastes time solving the wrong problem and a company that quickly pivots to the right one.
Even if you start with the wrong idea, if you are fast, you can iterate toward the right one before a slower competitor.
Yet speed is badly misunderstood. It is not about rushing or cutting corners. It is about focusing on what matters and trimming away everything that does not. More often than not, achieving speed of iteration means going slower and spending more time on what really matters. Speed is more about focus than velocity. Going fast in a startup means finding the truth of your market as quickly as possible.
Once you find that truth, once you know people are willing to pay, you can then iterate, improve marketing, and deepen your presence in that market.
Let me give you an example. A few years ago, a shiny fintech wanted to add my humble accounting software to its suite. They had the right idea and the right distribution, but their development team was glacially slow. They had no feeling of urgency, just a bloated office culture that allowed people to do nothing for months in a row. Their competitors were not all equally slow. As a result, my potential acquirer lacked a real differentiator and was slowly turning obsolete.
As I was talking to the executive team, I realized the bottleneck was not insight but speed. They wanted to move and knew what had to be done, yet they were too slow. It’s still extremely disarming to see CEOs unable to shake up their own companies. My personal opinion is that they don’t really want to do it because they have no incentives. In this case, both executives I spoke to enjoy fat pay checks and company-paid apartments — not exactly a Hunger Games scenario that would force them to move faster.
For a big company, the way out is to create small, independent pirate teams. Give them autonomy. Remove layers. Speed comes from independence and total ownership.
Small bureaucracy
For a nascent business, it means not doing many things at day zero, and trimming the company processes down to the bone. It means every single motherf****r in your start-up must focus on impactful tasks, enjoy an unclogged calendar, and evaluate it success with a clear metrics.
Here is how we do it in my own company. Fasten your seatbelt, it’s going to sound extreme.
No meetings. None. No weekly stand-ups, no daily check-ins. Writing culture
Everyone has total ownership of one thing: a product feature, a service to a client, or a sales mission.
Every task must directly contribute to either building the product, serving clients, or bringing in new clients.
When you give people full ownership, you cut the bureaucracy. At the very beginning, going faster matters more than going further. Later, once you have product-market fit and stable revenues, then you can afford to slow down, bring in more people, and deepen execution.
But early on, speed is life. I even went so far as to prohibit voice messages. In Latin America, people often communicate problems using voice notes. I banned them. I thought they made us slower. It worked, but it also had consequences.
Here is an example of the message I sent.
Hi @channel – I was talking with one of your colleagues and she complained, in a completely incredible way, that I did not want to receive voice notes.
So I thought: if she complained, it must be because you are all sending each other voice notes. Otherwise, she would not have that habit with you, and she would not complain. And if I am wrong, well, you are still guilty, because that is just how it is.
Here are some arguments, and why you should not use this toxic tool if you want to actually optimize your tasks the way you should:
They do not let you structure the problem, because you are thinking while speaking.
They make you unable to quickly synthesize a problem and extract the essential part, which is always just 10 percent. If not less.
When you are the receiver. You waste three minutes listening to something that could be written in two lines.
They waste the time of the listener, but also of the sender, because the sender has to wait until the other person is motivated to listen, often several times. Response rates are low. You are wasting everyone’s time.
They eliminate the possibility of keeping a written message, easy to read quickly, and instead create repeated time losses over the long term. You lose traceability and the loss of time compounds terribly over days, weeks, months, years, centuries, until the cosmic death of the universe.
Long live Slack messages.
How to go faster
In my case, my company once peaked at almost 15 employees. Today we are six. And with six, we generate more revenue than before. Why? Because fewer resources force you to decide what really matters. We cut the development team from eight to two (plus me, so two and a half). And suddenly, we move much faster.
Concretely, it means abandoning long roadmaps and product requirements with unclear return on investment. A developer must work on a tool that optimizes the single most important metric of your business: in my case, the north star is time spent per book closure. If the development does not meet critical requirements or optimize the north star metric, then the development is useless and the originator should be called out publicly.
When it comes to sales, it means pruning your offer down to the minimum requirements and iterating fast until you find product–market fit. It means quickly moving price, scope, name, speech, and message without overthinking outcomes, and instead focusing on the gathered data.
If the company already has revenue and is no longer in an early stage, speed means making everyone focus on the single most important task. Usually this comes with removing, deleting, and trimming: remove meetings, delete useless features, and streamline processes down to critical actions that either accelerate building or increase sales.
Speed is not about doing more. Speed is about doing less of what does not matter.