FAANG is overrated, unless you know your career ladder inside out.

FAANG or MAANG or MANGA, whatever the name you like, but in my opinion can do more harm than good to your career if you are not aware.

This is controversial topic for me especially when I was part of FAANG companies just about a month ago. But now that I have taken a leap, it is easy for me to see the two sides of coin.

Lets start with what does these companies offer for your career

Brand reputation

Great brand on your resume, working at one of these companies establishes the fact that you know your job as an engineer or engineering leader.

Great compensation

Best in industry compensation, backed by stock based compensation which in long term can create wealth for you.

Leadership skills

When I first joined mega company, I felt like religion change. These companies have set mechanisms which brings standardization in operations and helps to run thousands of teams with common philosophical strategy. Amazon, Google, Microsoft all these companies have set of principals which you will hear all of their employees saying in meetings, 1:1s, onboarding, documentations etc. It is great experience to understand the aspects of high bar and performing well on these guiding principals.

Learning scale

Thinking elegant solutions at scale, identifying bottlenecks in design, clarifying cost impact with different approaches, operational excellence and so on.

Exposure to operate in global setting

You get to learn from people across the globe about their work ethics, culture, backgrounds and niche skills they learned over time.

Tooling and processes

Operating at scale needs sophisticated systems and processes (in Amazon we like to call them mechanisms). Build tools, deployment tools, load testing, A/B testing tools, block days, essentially all the in-house infrastructure to enhance developer productivity is the best in class.

Mega companies must be appreciated for the tools and processes they have put in place to operate at global scale. Be it yearly planning process (read more at newsletter post), day to day operations, people management, employee promotions, high design bar, setting documentation culture and so on.

Documentation, High standards

Communicating across timezones and stakeholders is hard, so you must be great at putting your thoughts into words that folks can understand and take decision with fewer iterations or back and forth over meetings.

Fun fact:

Before Amazon, all the companies I worked with had 3 months notice period but Amazon only had 1 month. and in last 1 month, I did not do a lot w.r.t knowledge transfers Reason? 1) My team was on autopilot (:pat on the back) and 2) The culture of maintaining documentation for everything. Whatever ideas, project updates, team performance assessment notes I had, was documented under a single folder. Before leaving, I just assigned the permissions of that folder to my manager, made them aware about the documents on high level in 2-3 meetings and thats all!

Khallas :)

Okay, so far so good. Then why am I saying that FAANG is overrated?

Note - There are some career drawbacks of working with FAANG and it boils down to your personal career aspirations. Do not assume that practices followed by these companies are not correct. You will understand more further in the document.

Note - Do not assume this is only about Amazon. I have friends in other FAANG companies and the below points are mostly common at companies with global scale.

Now, Lets dive deep into the controversial part.

High standards, slow speed

Speed to churn out features is slower than other companies. The mechanisms needed at global scale, but often turns into bureaucratic layers of working. While this ensures high standards as the proposal/project/document goes through multiple reviews. But do we really need those many reviews.

Fear of failure or taking risks is very high which leads to everyone saving their asses. You will be lucky if your boss is one of those who believes in you and ask you to go ahead and build something. Mostly you will find people you will recommend more reviews, even if they feel this is good. Your manager will ask for Stakeholder review, then sr manager review, sr manager will ask to review with few principals or sr engineers, again no one would take a call. Then this goes to director level review, where you would not know who will be on your side in the review. This is the reason for slow speed, because everyone is trying to clear their side. So mostly the review meetings will go towards the direction for the first 5-10 mins of review.

In my experience, Rarely I have seen people turn around the conversation and informed the high influencing leader to change his mind/opinion.

Jeff Bezos shared few great tips for this situation, which became my guiding principles while taking decisions, atleast the ones which I can take bet on without additional approvals.

• While taking decision, do not spend lot of time on two way door decisions (youtube video explaining this). If it is one way door decision, then
• Jeff Bezon's 70% rule - If you have 70% information, make the decision.

"Most decisions should probably be made with somewhere around 70 percent of the information you wish you had…if you wait for 90 percent, in most cases, you’re probably being slow." – Jeff Bezos

How is it bad for my career?

This leads to complacency with the daily operations and eventually you will fall behind the industry trends, expectations from engineers at your role, level, tenure. I personally saw few longtime FAANG engineers not able to solve easy leet code questions. They are great at driving conversations, writing design documents, but problem solving gets rusty if you are only busy polishing your document so that somebody approves your design.

If you are truly an engineer, you would want to do problem solving 70% of the time and other glue work remaining 30% of the time.

Solved problems for you

In order to scale engineering teams, FAANG companies have dedicated teams building development tools. This makes your work lot faster. You will have access to out of the box frameworks, build tools, deployment pipelines, monitoring stack etc. This is great when you want to solve a problem, you simply create a project and start contributing. You focus on the business logic, while the company takes care of project infrastructure and failsafe deployments.

How is it bad for my career?

This kind of setup makes you handicapped as engineer, unless you make conscious efforts of diving deep into frameworks to learn the barebone functioning. For example, how is the application routing working, how exactly logs are appended, how is authentication logic kicking in and so on. Mostly engineers confine themselves to configuration interfaces but do not know under the hood logic. Similarly engineering teams adopt a trend of certain technology, e.g. an org is only using DynamoDb and it becomes a norm. Now even seasoned engineers are not giving a thought whether this makes sense for a usecase or they should use something else. This kind of mindset can lead to learning block for you. As an engineer, always question the status quo, but remember do not stick to your questioning once you have 70% information or if you are making two way door decision.

Ship fast, fail fast, learn fast.

Imbalance of headcount and skillset in teams

Often leaders have tendency to upsell their team's vision and get more headcounts for the scope of work. This is good for growing teams as it is a feedback to leadership about more investment and also the leadership trust if they fund the project/team.

However, sometimes if the leaders do not perform right due diligence this could easily translate to empire buildings. There is nothing wrong from the leaders as its a tendency, but executives must challenge that and identify the right size and skillet required for a team to excel.

In the worst case, over funded teams lead to imbalance of headcount and skillsets required. I saw few teams managing 3-4 micro-services with 11 engineers while there were teams managing 15 services with just 6 engineers. This is dangerous equation for both teams.

One team would not be able to provide opportunities for its engineers leading to disengagement . This can lead to attrition or the engineer who will slip below the company bar and will be a bad example for other engineers on the team.

While the other will be constantly firefighting to keep 15 services up and running, handling tickets, but not able to think big and contribute to the success of company.

As an executive, I do not want any of these teams because both of these teams are maintaining status quo and not really challenging their potential.

How is it bad for my career?

As mentioned above, either you will lack next level growth opportunities or you will only be doing operational work (important, but should not be the only work) which is not adding much value to you to become 10x engineer.

Employees working for promotions

When you build something complex and ahead of its time, without identifying the real need. This is the worst thing an engineer can do. Engineers in my opinion should simplify for scale, not complicate for sounding cool.

An engineer who can bring impact with 10 lines of code is way better than somebody who brought similar impact building a new micro-service.

Building new micro-service/library/caching layer from scratch, which required sign off from principal engineers and you did all shiny things (operational review, security review, deployment checklist) to launch it without any bugs sounds commendable on paper. But in reality you wasted at least 2-3 months of high skilled engineer who could have delivered the same impact in say max 2-3 weeks. That would not sound cool, but the impact is similar.

Sometimes at FAANG you can see such culture, where building something new will be appreciated as against simplifying existing services/architecture to achieve high impact. Never over engineer a system which does not have those demands. Always build for next 3-5 years scale, not next 20 years. As an engineer you must understand your business demands to make informed decisions, this would make you 10x engineer who can optimize resources/time, just the required engineering architecture and force multiply yourself.

How is it bad for my career?

As an engineer you would want to do something which tinkers your mind, which encourages you to think differently and more importantly build around constraints to come up with innovative solutions. Not something which is easy to implement but takes weeks to settle as new system.

As an engineer, you should display maturity to understand why a new library/microservice is needed, how much TPS are we supporting, can we handle the requirement from existing services/tools (without compromising the computer science fundamentals). If possible, one should always prioritise solving customer problem with speed and then shift focus on some other problems. You may feel this mindset won't sound cool, but you will learn a lot and in true sense will become 10x engineer which everyone would like to have in their team/company. Solving multiple problems will give you much more experience than replicating something which is already established and you know how to create that new system.

Unnecessary review comments, but no direction

You will find few people who will ask the surface questions instead of the depth. You are presenting a proposal and some engineers sometimes with high influence will comment about wording the document, right doc structure, missing data, suggesting new sections which they have seen elsewhere and so on. Mind you, these are all valid feedback if the reviewer goes deep in document and trying to guide you towards decision/solution.

However sometimes you will meet people who like to share their pet feedback in every review, regardless of whether they understood the overall proposal or not. In such population, it becomes extremely important to be aware about the helpful feedback from few good folks and filter out the noise. Yes, I am calling it noise, because often this feedback is to outshine them as reviewer and not worthy for your review/proposal. If you are not aware, you might end up addressing all of those feedback but actually its waste of time. Next time you go to review, same folks would not remember they gave you this feedback.

Its important to filter out the right feedback that can help you create a strong compelling case and understand the points you are genuinely missing than over the surface kind of feedback.

How is it bad for my career?

You would spend your energy to please reviewers with their personal agenda and have no interest in unblocking you or giving you right directions to pursue. Therefore, if you want to move fast and make impact to customers look for such signals and carefully browse such reviews. Its okay to ignore few feedback in order to move fast, but when you realize its slowing you down, its time to make a change that can help you exercise your potential.

Objective communication, not humane

It is often encourage to talk numbers and drive the organizations based on clear defined objectives and key results. I agree with this approach, however the line managers should keep a flexible 20% bandwidth/communication outside the regular delivery discussions. Often when employees are given clear result metric values and they are evaluated on those metrics, it introduces fear of missing out targets and not providing freedom to experiment and learn. This is bad for organization/company culture, especially engineering organizations where one must encourage engineers to think outside the box.

For example, Gmail was a side project by an engineer at Google. Think of if engineers are asked why did they miss XY goal for that quarter or month, would they be able to come up with such ideas?

As managers, we must allow creativity/innovation and that in my opinion happens when there is a space beyond objective communication. Managers must create the environment where engineers feel empowered to think different and create instead of deliver the defined.

How is it bad for my career?

Lucky are those who got leaders who discovered potential/skills in employees, who themselves were not aware. If you get such a leader, you must work with them as long as possible to solve more problems and grow as an engineer. However on the flip side, you would only be occupied with achieving numbers sprint over sprint, month over month, year over year and would not really cash anything that makes you proud when you are 50 years old.

Look for opportunities to build something that makes you proud when you look back. If you are getting such opportunities in your current role, stick to that and think how you can elevate the customer experience even further.

Do not hesitate to think beyond your pay grade and take bets to share your ideas/vision with your leaders. If you have a great idea, they will value you. If they do not, you can always benefit somebody else with your great mind/skills.

Closing thoughts

Working in FAANG is rewarding and especially for those who have learnt the basics of software engineering and are now looking to build something at the scale of these companies. However, if you are starting your career, in my personal opinion you should start with relatively smaller companies.

Companies which are solving customer problems day in day out, preferably a technology startup and groom yourself as a 10x engineer. Things you learn at smaller companies in 1 year can easily take 3 years for engineers at FAANG if they are not driven to learn and often consumed in delivering objectives.

FAANG companies are great to learn leadership qualities. You grow as professional which can polish you as a seasoned engineer who can hold conversations with executives. But if you do not know how to debug a load balancer, explaining the database index performance, manage database replicas (in non-managed infrastructure), then its best to learn that.

You may say, if these problems are already solved why should you care. But as an engineer if you complain that you never used datastructures in your job, its probably because you are a surface engineer not indepth engineer.

Next time you see something coded for you and working flawlessly, set aside 1 hr to dive deep into the code of how is it really working, the object oriented design of the library, the constraints, exception handling, configuration interfaces and so on. This would groom you as a strong engineer who is ready to build such systems instead of pulling things off the shelf and building application layer.

My best wishes to the 10x engineer inside you. Whether you work at FAANG or non-FAANG, it really depends on what you want from your engineering career. Start contributing to open source on weekends, read whitepapers, read leadership books etc. If you are in illusion that you are at FAANG and are a great engineer, ask yourself above questions and then decide for yourself.

I wish you all the best, and a great 2025 ahead!

?? Repost if you liked this newsletter with your fellow 10x colleagues or friends.

P.S If you liked this post, you'll enjoy my newsletter. Every week I share actionable insights on building high-performance engineering teams, fostering innovation, and driving impactful outcomes for budding engineering leaders.

Follow me on linkedin and if you want to connect 1:1 for mentoring, career growth or bouncing off any ideas, book your FREE 1:1 session.

Follow my substack to get access to more frequent posts about engineering leadership.