Lessons from the startup world

10 min read Original article ↗
The Money vs Fun relationship and how it affects your experience at a VC-backed startup

It’s a tale as old as time: a young, corporate professional leaves their stable job for a sexy new startup. They are promised endless growth opportunities, an exciting product to work on, and the potential to make untold riches when the company IPOs. Most importantly, youth is on their side, so they can afford to take a gamble, right?

After living the startup life for the last 4 years, I’ve learnt that startups are an adventure with ups and downs. One minute, you are a rocket-ship company that has just raised a new round of funding; the next thing you know, you are stretching every dollar to extend the runway until the next funding round.

Regardless, it has been a great learning experience, and I truly believe that you should give the startup world a shot at some point in your career, so I wanted to share my five lessons.

In the corporate world, projects often die a slow death. This demise is usually caused by two things: endless bureaucracy and a general lack of enthusiasm. Everything seems to be gridlocked by countless, unsolved cross-team dependencies and the pervasive, soul-crushing attitude of, ‘that’s not in my job description, so it’s not my problem.’ What should take a week often gets stretched into months.

On the other hand, startups are the perfect environment for high-agency individuals who want to get shit done. Need to gather some feedback on a new feature idea? Set up a call with a customer and ask them yourself! Got an idea that will improve the product? Build it and start showing people! Need to make a change in a different team’s codebase? Make the change, open a PR, and jump on a call with them to review it together! And when your colleagues share the same mindset, it enables the organization to move fast.

For example, when it came to experimenting with machine learning models for event classification, we didn’t consider it solely an AI researcher’s problem. Though I was an engineer, I worked closely with them to try different model architectures, gathered the training data and labelling resources, built evaluation sets for testing, and eventually deployed the models into our production pipeline. I was always looking for ways to push things forward, even if it wasn’t in my “job description”.

In the fast-paced SaaS world, the pressure is on to serve customer needs, often leading teams to rush into development based on anecdotal evidence. We believe the key is to jump on as many calls as possible and gather ideas. But this is the trap: one-off calls are great for scoping the landscape, but they are also breeding grounds for false positive signals. It is easy to confuse a customer’s casual interest with an actual, purchase-backed need.

I learned this lesson the hard way. I’ve been on a team where we built a new product as a direct response to some “customer interest” coming from the sales team.

“Customers were willing to buy this new feature if only it existed in our product!”

With high excitement across the business, we spent months working on it, only for it to flop when it was released because no one bought it. What happened to all the potential customers? It turns out that it’s easy for a customer to say they are “interested” in a product when there is no commitment to buy anything.

Instead, it is essential to build feedback loops with customers early on in product development. Ideally, they have either already purchased the product or are a design partner. The important thing is that they are committed to helping you with the iteration process, which allows you to ship out new features as an “alpha” version and get feedback. No love for the feature? Kill it, quick.

Startups are a very dynamic environment; requirements can change quickly. A large customer might suddenly threaten to churn unless a specific feature they were promised gets built. Leadership may decide that they want the organization to focus on a new, emerging trend, and that they need it in the product yesterday.

As a result of changing priorities, it is not uncommon for projects to be killed and teams restructured. Depending on the startup’s maturity, this can happen over the course of several quarters or even over a few weeks. Oftentimes, the decision is out of your control.

I learned that it’s important not to get too attached to the projects I worked on. This can be difficult, especially if the project is “your baby” that you have put a lot of work into. You can try to turn things around or convince leadership that you need more time, but ultimately, it might be out of your control.

On the flip side, changing environments are an opportunity for you to step up and do more. You could be put in a team that recently lost a few members, and now you get to learn a new domain, perhaps it even comes with a promotion! The struggling product that you were working on finally gets sunsetted, freeing you up to move on to greener pastures and work on exciting new initiatives.

Ultimately, I think it’s best to reframe the situation entirely. Shut down the voice that says, “My company thinks I did a bad job.” Instead, embrace the positive lens: “This is a new opportunity to do something different.” That shift in perspective is the very definition of staying agile.

A common reason people join the startup world is the promise of less bureaucracy. No more waiting for an endless chain of approvals to do things; you can focus on getting things done, no permission needed! But the reality is inefficiencies still exist, just in a different form.

For example, that corporate system where you request approval? That doesn’t exist; instead, you have to gather everyone in a room together and get them to approve in person. And if there is no clear decision-maker, the decision usually falls straight to the founders or the CEO. Since they are pulled in a thousand directions, they inadvertently become a bottleneck simply due to a lack of bandwidth.

On top of that, startups are often early adopters of the latest tech, and while it is fun to try new things, you really don’t need 3 different tools that do the same thing. Let’s take the example of a wiki to store documentation. There might be an organization-level wiki, but if it’s outdated or clunky, engineers will spin up their own wiki. Some teams use canvases on Slack. Other teams might use a pricey project management tool. The lack of standardization means no one knows where information should be shared, and now you have to waste time updating things in multiple places.

Consequently, knowledge bottlenecks are a form of operational inefficiency in startups. The lack of a centralized source of knowledge requires you to search across multiple tools to find the right documentation. On top of that, organizations without a “documentation culture” end up with a lot of tribal knowledge. Usually, the knowledge lives in the heads of long-tenured team members; they might even have been there when the system was first built! This creates a dangerous single point of failure and a mad dash to share knowledge if they suddenly leave.

The promise of less bureaucracy is seductive, but the reality is just a swap. You trade the structured red tape for volatile, unwritten red tape. The immense growth and speed of startup life is the payoff, but the true price is accepting that the freedom to build comes with the responsibility to maintain the chaos.

Growth at any cost was the standard VC-backed startup playbook a few years ago. Investors were willing to throw vast sums of money at promising startups to help them scale, and we would use the money to hire more people to build more stuff. Then customers would buy the new things that we built, and it would balance out the cost of hiring all those new people. But what if your new products don’t take off?

Not all products are an immediate hit; maybe it will take time for customers to see the value. You still have plenty of VC money, so you keep the team, giving them time to get feedback and iterate. But over time, it becomes clear that the market is not ready for that product, and iterating is a waste of time, so you kill the project. What do you do with all the people you hired?

Ideally, when a big project gets killed, you could keep the team and find new work for them. However, during my time in the startup world, the market shifted fast. Zero percent interest rates disappeared, and every investor suddenly demanded profitability. The people we hired for ‘growth at any cost’ quickly became an unsustainable cost. When that happens, the tough reality is that leadership is often forced to make redundancies.

Redundancies aren’t just a headcount problem; they are also a morale problem. This instability creates an environment of uncertainty, and the general mood goes down. People worry that they might be next, and it can trigger a vicious cycle, where high-performing employees start to leave voluntarily. This puts more strain on the remaining team, who now have to carry the load.

This was the hardest part of the startup journey. The company's goals shift from growth to extending the runway long enough to reach profitability or raise the next funding round. For the team that remains, the work doesn’t stop, but the resources do. You are forced to be more ruthless with prioritization in an attempt to do more with less.

It is in this environment that you need to ask yourself honestly:

“Do I still believe in the long-term mission? And am I still learning and growing in this role?”

If the answer is “no”, then there is no shame in leaving; staying would just add to the morale drain. But if the answer is “yes”, then you have to commit fully. Bite down on the gumshield, ignore the noise, and persevere. The people who stick around through the “bad times”, the ones who solve the hard problems when resources are scarce, forge a resilience that cannot be taught in a stable environment. Whether you stay for the next chapter or eventually move on, that ability to execute through the storm is a skill you keep forever.

Looking back, I’m incredibly thankful that I got to be part of this journey. The highlight was undoubtedly the people; I worked alongside so many smart, driven individuals and learned more from them than I ever expected.

Being surrounded by high performers in such a chaotic setting acts as a catalyst for professional growth. It creates a specific type of operator: someone who doesn’t wait for permission to fix problems and has the resilience to execute even when the odds are stacked against them.

So, if you are looking for someone to maintain the status quo, look elsewhere. But if you need someone to drive results and shake things up, don’t be afraid to hire an ex-startup operator.

Discussion about this post

Ready for more?