Big Tech vs Mid-Tier vs Startups

Which company type is best for you?

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

I am thrilled to share that we are a 1000+ members community now. Can’t express my gratitude enough to each one of you reading this newsletter. 🙏

---

I have worked in software companies of all sizes, from startups to Big Tech. I noticed some interesting aspects on how people think and build software.

Today I am sharing my key takeaways from working at companies of different sizes. These will be based on anecdotes of my experiences. I hope this will help you decide which company type is best for you.

1. Big Tech

Not all Big Tech companies are the same. I used to work in one such company and designed a technical solution involving distributed systems. It was roasted by other Senior and Principal Engineers in the review, to an unnecessary extent in the name of scale and safe rollout. It’s not uncommon at a few Big Tech companies.

They used to pick a lot of nitpicks and ask questions out of context. They looked forward to a 5-10-year vision, while the feature needs to be shipped “quickly” as per PMs’ timelines.

This loop of "improve the doc", misaligned expectations, and pushback from sister teams leads to churn and process-driven burnout. They add up to over-skepticism and slow down the company.

But there is a strong reason why they are forced to follow such a suit. They operate at a huge scale. A small hiccup can cause a loss of billions of dollars and of customer trust built over years. And that is the reason, Engineers are paid top-notch at Big Tech.

My key takeaways are:

1. You will learn many best practices and understand how to operate systems at scale.

2. When you land impact, it will touch millions of customers across the globe.

3. Your payscale is exceptional.

4. You often end up coding relatively less and get stuck in processes and approvals.

5. Safe practices come with burnout. You might end up waiting to see the impact of your work for months or years in some projects.

2. Mid-Tier Companies

To clear up this vague definition. I am referring ‘Mid-Tier’ to companies that are still on a growth trajectory. They also have a very high scale but not to the extent of Big Tech.

When I moved to mid-tier companies, I observed they move so fast and deliver results quickly by:

• making a small testable net-new logic module, possibly behind a feature gate.

• gathering early feedback by internal dogfooding and acceptance testing.

• iterating back, fixing stuff, adding more features, and repeating.

• avoiding unnecessary processes and consensus.

I had to unlearn many processes and coding practices. Most importantly, I had to unlearn 'asking for permission'. The autonomy and flexibility were great. They had the perfect blend of moving fast, showing impact quickly, and not overcomplicating. It positively blew my mind. On top of it, Engineers are paid really well.

But to enable teams to move fast, dedicated infrastructure teams build some abstractions. These hide the underlying concepts from product engineers. Systems could also go stale or become monolith pretty quickly.

My key takeaways are:

1. You will learn the art of a true 'Bias for Action' by coding the MVP quickly. This will deliver results faster and save the company's resources and money.

2. You seek consent over consensus.

3. Pay could be a little less than Big Tech, but mostly comparable.

4. You may slightly miss out a bit on best practices, processes, failure modes, and rollout experience at scale. System code becomes complex to manage relatively fast. But this is not always true.

5. Moving quickly without understanding the core dependencies could lead to shallow learning. This is especially true for some product-focused teams.

3. Startups

In between jobs, I also had an excellent opportunity to join a startup as Founding Engineer number #1. If done well, this role is sometimes matched to a CTO role.

I wrote the first set of APIs. I also implemented the build-and-deploy systems. I set a vision for the product and talked to potential customers. It was such a roller coaster ride. This journey was filled with a tremendous amount of learning in a short period. At the same time, the base pay was comparable to Big Tech but everything else was paper money.

But I was so burnt out after spending a major portion of my day and night contributing to the company. And I had some other personal commitments that I had to meet. I made a tough decision to part ways with the company.

My key takeaways are:

1. If you ever want to start your own company, working at an early-stage startup first is your best bet.

2. The surge of learning is incomparable. You learn deep tech in a short time. You also learn many different skills. This paves a path to C-suite leadership if you stick around.

3. The Gross Pay isn't great. But, it has a higher upside if you stay a long time and the company succeeds due to your deep contributions.

4. Your energy should match the commitments required at the startups. Also, the timing should suit your life. Otherwise, you won’t do the job or personal life justice.

5. Burnout at startups is real. Defining boundaries between personal and work life is hard. You should make a conscious, informed, and hard decision before joining a startup.

---

Shout-outs 🔊

1. Dumb Code Beats Smart Code - Don’t make the mistakes I made by

   Avneesh Sharma

2. Feedback is a gift only if it is received well by

   Omsai Jadhav

3. Design a Distributed Priority Queue by

   Eugene Shulga

4. The Role of a Technical Program Manager by

   Nicola Ballotta

5. Feature flags are ruining your codebase by

   Anton Zaides

6. Super Specific Feedback: How to give actionable feedback on work output by

   Wes Kao

7. 3+1 strategies to track your achievements by

   Fran Soto

---

Let’s Connect 🤝

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe