← Back to Library

Career paths for software engineers at large tech companies

In an era where the tech industry's churn rate is finally slowing, Gergely Orosz offers a rare, unvarnished look at the internal mechanics of promotion that most engineers only guess at. Drawing on exclusive insights from Ethan Evans, a retired Amazon Vice President who oversaw over 1,000 engineers, the piece dismantles the myth that technical brilliance alone guarantees advancement. Instead, it argues that the path to seniority is paved with operational grit, political savvy, and the willingness to solve problems leadership didn't even know existed.

The Myth of the Pure Coder

Orosz begins by reframing what "good" performance actually looks like at the mid-level, challenging the romanticized view of the solitary genius. The core of the argument is that independence is the baseline, not the ceiling. As Orosz writes, "A good L5 can take a reasonable design and just build it. They can figure out some missing details on their own, and don't need daily or even weekly guidance." This is a crucial distinction for busy professionals: the ability to operate without constant hand-holding is the entry ticket, not the exit visa.

Career paths for software engineers at large tech companies

However, the piece takes a harder line on behavioral expectations, suggesting that technical skill is easily negated by a negative attitude. Orosz notes, "Leaders might tolerate a high-maintenance engineer for a while, but will never consider a habitual complainer as a candidate for progression." This framing is effective because it strips away the excuse that talent grants immunity from soft skills. It aligns with the historical context of the Peter Principle, where individuals are promoted to their level of incompetence; here, the author argues that complaining accelerates that slide by marking an engineer as a liability rather than an asset. Critics might argue that this places an unfair burden on engineers to be perpetually agreeable, potentially silencing necessary dissent, but the author clarifies that pushing back is fine—just not the endless complaining that drains team morale.

"Leaders are going to be reluctant to promote those who only want the 'good' work of new design and development. Why? Because all the work needs to be done!"

The Anatomy of a Slam-Dunk Promotion

Moving beyond baseline competence, Orosz outlines the specific behaviors that trigger a promotion to the senior level. The argument shifts from execution to scope and foresight. The most compelling insight here is the value of solving invisible problems. As Orosz puts it, "A winning recipe for impressing leadership is almost always to spot and address a big problem we didn't know we had." This moves the engineer from a reactive role to a strategic one, demonstrating judgment that transcends code.

The piece also emphasizes the importance of "seeing around corners," a metaphor for proactive risk management. Orosz writes, "Highlighting and solving looming problems currently out of sight to your manager, pointing things out before they become problems, and volunteering to prevent them, is also highly prized." This is a sophisticated take on career growth that mirrors the concept of "span of control"; as engineers grow, their value is no longer just in their own output but in how they expand the effective capacity of the entire team by preventing future fires.

Yet, the author is careful to ground these high-level concepts in the reality of office politics. Orosz admits, "Many engineers dislike hearing that relationships matter because they believe standards should be objective and that 'opinions' shouldn't matter." He counters this by explaining that soft judgments dictate who gets the high-visibility projects. This is a pragmatic, if slightly cynical, acknowledgment of how large organizations function. The advice to be "pleasant and helpful" rather than trying to "suck up" is a nuanced distinction that prevents the advice from devolving into mere office sycophancy.

The Reality of Time and Patience

Perhaps the most valuable contribution of the piece is its insistence on realistic timelines. In an industry obsessed with speed, Orosz pushes back against the desire for instant gratification. "Once you and your manager agree a plan, realize that promotion will probably take 1 to 2 years from when you are a solid L5," the author writes. This is a necessary corrective to the culture of rapid advancement, which often leads to burnout or premature promotion failures.

The reasoning here is rooted in the need for consistency over luck. Orosz explains, "While you may believe you have shown mastery, from the outside it is often hard to tell if someone is actually good, or just got lucky on the first try. We want to avoid mistakes, so prefer to see a few things delivered in order to be sure that it is skill, not good fortune." This perspective shifts the burden of proof onto the engineer to demonstrate sustained excellence, a requirement that is often invisible to the individual but crystal clear to the leadership. The author suggests that the fastest way to progress is not by demanding it, but by being flexible and ready to seize opportunities as they arise, rather than waiting for a perfect project to land in one's lap.

"You cannot know when a new person will be hired for you to mentor, or when a big outage will happen. You will progress fastest by being flexible about which elements you demonstrate and by jumping on opportunities as they arise."

Bottom Line

Orosz's greatest strength is demystifying the opaque promotion criteria of large tech firms, replacing vague aspirations with a concrete checklist of behaviors that prioritize operational reliability and strategic foresight. The piece's vulnerability lies in its heavy reliance on the Amazon model, which may not translate perfectly to smaller or differently structured organizations, but the underlying principles of visibility and scope remain universal. For the busy engineer, the takeaway is clear: stop waiting for permission to lead and start solving the problems that keep your leaders awake at night.

Deep Dives

Explore these related deep dives:

  • Span of control

    The article mentions managers overseeing 25-80 people at different levels - span of control is the management theory explaining optimal team sizes and org structure that underlies these decisions

Sources

Career paths for software engineers at large tech companies

Across tech, the average tenure of software engineers seems to be rising, not least in Big Tech where it has increased rapidly. With today’s chilly job market having a dampening effect on the number of engineers switching jobs, it’s possible that staying in a role for years will become pretty normal for many in our industry.

So, if you can see yourself at your current workplace for the longer term, it’s sensible to consider the career path options available, and how to get promoted to the next level.

To shed light on these topics and others, I sought out someone who has managed large engineering orgs at a massive company. Ethan Evans is precisely such a person; he was a Vice President of Engineering at Amazon, and has overseen the growth and promotions of more than 1,000 engineers(!) over the course of his career.

Now recently retired from the online retail giant, Ethan can candidly discuss how large companies operate, and which tactics and strategies really work and help colleagues to enjoy thriving careers in big workplaces.

These days, Ethan teaches engineers and engineering managers how to get promoted faster, and runs live courses. He’s also built a 24/7 personalized “AI career coach”, and shares career growth advice in his weekly newsletter, Level Up. His class on fast career growth currently has a 25% discount for the US Thanksgiving holiday, from today through 2 Dec — you can check it out here.

In this issue, we cover:

Good performance as a mid-level engineer. Execute independently and try not to complain too much.

How to get a slam-dunk promotion to Senior. Have big ideas that are also correct, solve problems leadership didn’t know existed, see around corners, and more.

Tactics to get promoted to Senior. Agree a plan with your manager and be realistic about how long it takes.

Getting promoted to Principal Engineer. Standout technical expertise, tackling ambiguous & large-scale problems, and paying attention to the business, are all key.

Should you be a manager? As you grow more senior, there may be opportunities to become a manager. But is it the best path for you?

When to switch to management. Switching early (at L5) or later (L7+) is rare, and is most common at senior level (L6).

Different management levels. How being a manager at L5, L6, and L7 levels differ.

Throughout this article, we use Amazon’s career levels ...