Use This Mantra to Decide whether You Want to go to Big Tech or a Startup

When I left Disney Streaming Service to pursue another opportunity, my colleagues asked, “where are you going next?” I told him about a company that wasn’t as big as Disney. They responded with a joke saying, “I bet it is easier to solve the problem over there than it was here,” with a wink.

The truth is that it is not much easier.

It is just a different problem that I am solving. Therefore, these are three main differences between a startup and a Big Company that will help you decide where you want to pursue your next career journey.

Scalability vs. Product Market Fit

Many of the products are well-established when you work at big tech companies - everyone knows that the product has found the product-market fit.

So what happens when a company reaches this stage?

They start to scale.

They have started improving their infrastructure and want to create a better user experience, so they are investing a lot more resources to make the system reliable.

As an engineer, the company requires someone to dive deep into scalability issues—knowing the internal working on a library or infrastructure to make it better and faster. In other words, they are looking for a perfect solution for the system. Thus, they are also looking for people with a laser focus on scalability.

On the other hand, startups need to solve a different problem than Big Companies. Startups are always evaluating their product to see if they are solving the critical user pain points.

"Are we solving the right problem or not? And is there any traction to the problem that we solve"

Engineers in startups need to be close to the product and evaluate the product to make feature recommendations. They may think about mocking the backend and creating the UI for the sake of seeing if they should go all-in on the feature. They look for the right metrics to see if they solve the problems.

When you think about creating a Food Delivery App such as Doordash, you may think that there are a hundred orders a day, managing driver networks, scaling payment systems to accommodate multiple users.

As an engineer, you may start thinking of scaling the systems to accommodate a high amount of load. However, the way the founder got started, they delivered themselves. They code out some prototype, probably in some language they are most familiar with, such as Python or JavaScript.

They didn’t think about how network effect, managing multiple drivers efficiently, and payment systems for multiple users. They are grateful if users ARE using their app. If some miracle happens on the first day of launch, Tony Xu will go to the restaurant, pick up the food, and deliver it themselves. The first thing you don’t want to think about as a founding engineer in Doordash is Scalability.

They may copy and paste many things and work backward to test a simple prototype in the codebase. In other words, you will need to build a hacky system. Lots of the practice in the startup may frown upon other engineers. However, the last thing that they need to do is scalability.

On the other hand, engineers in Doordash now need to know how to scale a payment system to accommodate multiple users. They also need to make their system language agnostic as they scale internationally.

If you love scalability problems, you should go to Big Tech. They have enough resources to help you research the topic of making the system as available as possible. On the other hand, if you want to understand how the product decision is made and become closer to the product, you have a better chance to be in a Startup. Although you may need to sacrifice doing things in the right way, you gain the ability to use tech to find product-market fit.

Working on Specific Parts vs. Working on multiple parts

When I was in Disney Streaming Service, I got assigned to a specific part of the payment system - more specifically, a repository. They told me not to worry about other domains and focus on the Payment domain. However, there is not much time to slowly understand the domain in a startup, and I got to touch ten different repositories to build a feature that worked end to end.

If you work for a Big Tech Company, you may be assigned to a specific domain. Your role is to make the domain better and faster. Therefore, you may have known less about other domains and your neighbor services’ code base code because other teams maintain that domain.

If you want to change the contract between neighboring services or add new features to the current domain, you need to meet with other teams that interact with your service and discuss it. They will make changes on their end to not impact their service. These steps may include multiple meetings with the team, the PM of your team, and the PM before you can change the contract.

In a startup, you may touch on multiple codebases and be on many hats. For instance, you may be the one that needs to discuss with the vendor or find the right team to talk to for specific features that you are trying to test.

You may need to understand which repository is the right place for the new feature that you are trying to ship. Further, you need to communicate with the repository owner to make changes to the repository. You have to be able to articulate your thought on whether the product that PM was requesting is feasible and give insights on which part of the system needs to fix.

When the project is not going as expected, you will need to ping the right person or team to push the project further. In other words, the ability to chase after people because you are the person who gives ideas. Thus, you are also the person who is accountable for the project’s outcome.

Since everyone is busy with their roadmap, you have to communicate and ensure that your execution strategy is clear by clarifying all the questions to all stakeholders and PM as early as possible.

Although your title is a software engineer, you may do some project management, product management, and even a QE role sometimes because your responsibility is to ensure this feature is shipped properly.

Structured Organization vs. Flat Organization

This happens because of the notion of a startup. As a company grows and more and more people are hired, the organization will transform from a flat to a more structured organization.

In a big company, that means a lot more ceremony and team rituals.

When team A needs to do a contract change, team A PM may need to schedule time with team BPM to discuss. Team A PM needs to see if team B can squeeze these changes into their current roadmap. If all goes well, both teams discuss when this change should take effect, etc.

In a startup, engineers can message a director and ask questions regarding the domain they solve. The director will explain the domain for the engineers to further their research on the new feature they are pushing.

If there is an arrow on how the communication flows in an organization, in a big company, it will be PM to engineers or engineer manager to engineer. In a startup, it will be across all directions.


The problem you are solving in a startup is different from that of each employee working in a big company.

When I was in a big company, we solved scalability problems. There is already a product-market fit, and we need to figure out how our system doesn’t break and make it scalable and reliable.

In a startup, the problem that you are learning is cross-functional. You will be working on enabling certain features and seeing if that feature is deemed good enough even to go further.

You may be responsible for a single domain in a big company. Thus, you can be the subject matter expert in that domain. Thus, you only work on a couple of repositories, but your knowledge of a specific topic is deep.

In a startup, you need to understand how the user is interacting with your application and see if the feature you build can help increase conversion. You may be working from the front-end’s interaction to the payment service. Although you get to see how all services are wired together, you don’t go deep on that service.

The challenge in the startup is not about technology and scalability but more about how to ship your product successfully. You need to get everyone together to make this project going forward. In other words, a lot of project and product management work. You get to see if the product either works or fails.

This requires an engineer to be pragmatic and hacky.

Lastly, the organizational structure between a startup and a big company is also different. Your title is not clearly defined in a startup. Communicating in a big tech company may not be as flexible as a Startup.

If you want to keep pushing yourself and your career as an engineer to the edge, you should consider going to a Startup.

If you want to become a subject matter expert in a specific domain and specific field, go for Big Tech. If you want to start your company one day and be close to the company vision and product as much as possible, go for a startup.

Either big tech or a startup, you get to learn a different skill set and be a more well-rounded software engineer. As long as it pushes you forward to the ideal career you want, go for it!

Like this Article?

Sign up for my newsletter to get notified for new articles!

Related Posts

My Journey Through Burnout

Will the Newest Generation of Programmers End Up Taking Older Software Engineers Jobs since they are Younger and know the Latest Technology

Will I lose my Job To the Younger Generation if I am not Passionate about Technology

This is How 1:1 should be Utilized To Maximize Career Growth

No.1 Pursue awkward Topic

Does Seniority Title Really Matters in Tech

The answer is always - depends

An Interview Question that Truly Tests your Experience as a Software Engineer

questions that is not based on Leetcode