Jiyeon Park · May 13, 2025
How a startup loses its spark
As someone who briefly dipped a toe into startups, in a not particularly important role, I thought this piece realistically captured the spirited beginning of a startup and the paths toward success or failure. In particular, compared with large companies, the startup-specific trait of enjoying the work felt deeply attractive. It also made me more curious about concrete ways to preserve the spark that only startups have, which the latter part of the piece discusses, for as long as possible.
How a startup loses its spark In a smoothly operating seed-stage startup, engineers often describe their work as addictive. In larger companies, however, enjoyable is usually the highest praise. Why does this happen? Is it inevitable?
Let's explore what makes a startup addictive. Engineers should spend most of their time inside the core loop below.
If necessary, talk to users and find out what their problems are.
Come up with ideas to scale.
If needed, discuss the ideas with colleagues.
Implement the idea.
Launch and hope for the best. Celebrate success or analyze why it failed. Then go back to step 1.
In groups of fewer than 10 people, this process can be fun.
You can contact users you care about directly, and even have a beer with them.
When you find an idea that is valuable to the company and interesting to you, you can drop everything and work only on that.
Most of your colleagues will be interested in discussing this idea with you because: a. They have a direct stake in you. If your idea is good, they benefit by encouraging you to start working on it. If your idea is bad, they benefit by explaining what is wrong. They may even be able to think of themselves as users. b. They may want to work on the idea with you. c. Because everyone is familiar with a substantial portion of the codebase, they may offer useful insights.
You can execute quickly. a. Without a security process, choose any tool you want. b. A small codebase lets you hold the whole thing in your head, making bold refactoring more comfortable. Fast hot reload also lets you try, fail, and debug quickly. c. Merge code changes quickly. There should be no tests in CI that take forever. Stable changes do not need a blocking PR process. Or push straight to the master branch. If the change is not stable, lightly ask your colleagues about the PR process. d. If you have few users, you can schedule maintenance windows and make large backend or database changes quickly.
Nothing is impossible! This is where you can create value. People may build on this feature years later, and you may appear in the history books as a visionary. You might be at a party and hear one of your users say, "You came up with this idea? Oh, it saved my life." Because everyone on this team has a stake in you, they are all deeply connected to you. Your minds are synchronized.
As the company grows, the fun gradually disappears from all of these steps. In groups of more than 100 people, the loop looks like this.
Talking to users is the PMs' job! You should just do what you are good at. Even if you communicate with users, what you get will only be a summary of user insights or a prioritized to-do list derived from it. At worst, you may misunderstand users, or a manager's selfish thinking may distort the to-do list, and no one will be able to explain why the work matters.
You cannot just do what you want; coordinating the work creates O(N^2) communication chaos. Your manager has a plan for you that accounts for everything else in progress. You will probably have to finish all of that before you can work on your own idea. Or maybe you can work on it secretly in your spare time.
You can talk with colleagues about your idea, but they will not be very interested. They do not really benefit from your success; in fact, they may be competing for promotions. They have long to-do lists, so they do not have time to leave their own work and work with you. And they probably do not remember much about the code you are writing.
Execution is slow. a. All the tools are already decided. There may be newer and better tools, but they will not be good enough to justify harming consistency. Do not try to harm consistency. If you want something new, email your manager or the security team. b. A massive codebase, code that is hard to touch mostly because of old history, and enormous code that no one understands anymore. Only thorough inspection can give you confidence that you are not breaking things. c. Even a small PR takes two weeks. You wait 20 minutes for CI to pass, and if a test fails, you run it again. Merge conflicts pile up while you wait for feedback from reviewers. Reviewers either lack enough context or have no willingness to offer substantive opinions, so they only leave nits. d. Changing infrastructure even slightly requires 14 steps, which prevents downtime or data loss for ten million users.
After working pretty hard for three months, you will ship something. You will demo it at the Friday meeting, your one chance to show the CEO what you have been working on. Only a few colleagues will pay attention; your work does not affect most of them much. At best, it is encouragement. Your manager tells you this demo will matter a lot in your performance review five months later. In the best case, you get a 20% raise and a title change. In the worst case, within four months there is a restructuring, a new manager arrives, or your project gets pushed back and canceled. You have to convince the new manager what you have done for the company.
Can this be prevented? I do not think so.
Looking more closely, all of these problems fundamentally arise for the following reasons:
Reduced direct stake, which weakens team cohesion
O(N^2) communication, which requires managers or specialists and narrows individual autonomy and learning
Slower progress to reduce risk
Items 1 and 2 are inevitable consequences of having more employees. Item 3 is an inevitable consequence of having more users, and in some respects of government regulation.
But there are things you can do to slow the loss of interest. First, do not accelerate it. Most startups accelerate their own corporatization by copying the processes of larger companies, usually by hiring managers from big companies and applying the old methods they used. For example, many startups use Jira simply because large companies use Jira. But do not use Jira. Y Combinator was the one that reminded the world that inspiration should flow in the opposite direction: large companies should operate like startups.
Also, the way large companies operate is not only for large companies; it is also not suited to today. As your startup scales, solutions will exist for the problems that arise during growth. So when you experience growing pains, solve them from first principles, or look for inspiration from startups of the same size that move faster.
You can structure the company like branches of individual startups. In fact, you should do this as much as you can; Rippling has pulled this off to some extent. But because the elements of your product are very tightly connected, and most individual elements do not generate revenue on their own, most companies will not be able to do much of this.
You can significantly slow factor 1 by designing incentives intelligently. I will cover this in detail in another blog post. But there is no better incentive than a large equity stake plus the ability to affect the value of that stake.
Beyond that, your best option is to hire less. I firmly believe most companies hire too quickly because of misaligned manager incentives, investors who pressure you with bad information to look like other fast-growing startups, and a failure to recognize the true value of one employee. And as tools, especially AI, continue to improve, the number of users a small team can support is increasing. I think future founders will not need to worry as much about these growing pains, and work will become more fun for everyone.