- Retail and AWS Amazon operates differently. Retail is more product focused, AWS is service oriented. Below notes is focused on AWS Amazon
- As comparison to FB (Meta) AWS products are platform hence the heavily focus on operational excellence.
- Frugality is a popular concept. The story of how AWS came about started with the company just have bunch of servers that are dormant, they are very good in maintaining infrastructure, why don’t they begin to provide it as a product for other companies?
Good:
- Get paid relatively well.
- High ownership. “You build it, you own it” concept
- Lots of boomerangs back. Don’t need to reinterview if boomerang back within 6 months.
- Easily move to other teams if you are not in “Focus” or “PIP”
Bad:
- Oncalls are heavy since it is “You build it, you own it”. There is little separation of operations engineers vs development engineers.
- Notorious “PIP culture (more on that below) and the politics that goes with it.
- Some managers would put engineers in to “PIP” to prevent them from leaving.
- No engineering perks (as compared to other FAANGs) like free parking, meals, etc.
- Lots of internal tools, not reusable outside of Amazon.
- Turn over rate is high. Sometimes employees are viewed as “resources” than human beings.
Performance Improvement Process Culture
- 1. Focus (also called Development Plan or Development List): Usually presented as an informal coaching plan, this is really the first step of the formal performance management process. The person in question is given a project they must complete within a well defined timeline of usually a month. Around 10-15% of the organization is put in Focus every year. It’s common for managers to be “forced” to put a person in Focus to meet their organizational-level Focus target.
- 2. Pivot: If you fail Focus, you are given the option to either quit and take a severance package offered, or to go through a PIP.
- 3. PIP: Similar to Focus, you’re given another well defined project with an especially aggressive timeline to complete. You’re fired if you aren’t able to finish it. Anecdotally, most people on a PIP do not pass this process. There is unwritten statistics that 6% of your team are forced to get put into PIP even if you’re a good performer.
- URA: If you resign at any point in the process (including Focus), you are considered as Unregretted Attrition (URA) and are put on the “no rehire” list.
- No switching of teams. If on Focus or PIP, you are not allowed to switch teams during the process without Director/VP level approval. There are stories of managers abusing Focus in order to prevent well-performing people from leaving the team.
Career Progression
- Entry level is L4. Interns starts here
- L5 is the stopping point. You either get stuck here and end up leaving or stay here for awhile.
- L5 -> L6 requires an L6+ Engineer to review your work and approve. This is quite different from most big companies as the approval requires inputs from actual Engineers.
- L7 is Principal, holds a lot of power. Quite hard to get promoted from L6 -> L7. Most people don’t make it on their first try.
- L10: VP and Distinguished Engineer. Amazon’s most senior individual technical contributors, responsible for driving Amazon’s overall technical architecture. This level is the same as the VP level on the management chain, and the title including the VP represents this.
- The main jobs are:
- SDE: Software Development Engineer. At most similar places this role is called a software engineer.
- Solutions Architect. This role exists within AWS and they typically work with other organizations to onboard staff and to work with AWS.
- Data Engineer: a role more common within AWS.
- System Development Engineer (SysDE): developing best practices, refining operational procedures and scaling up operations. Similar to the SRE role.
- SDM: Software Development Manager. Most similar places call this role the engineering manager.
- Teams usually don’t have a SysDE, but when they do, usually is a high impact hard core Operational Excellence team.
Oncalls
- On calls is a place where everyone can learn more in one week of participation vs 4 weeks of development
- On calls follows an escalation policy due to tight service level objectives. Usually engineers need to respond within 15 minutes. Escalation can go all the way up to CEO if no one responds but this usually never happens.
- It is a common case for managers, vps, and executives to join on calls. Managers surprisingly are quite technical and can work on a solution with an active engineer to remediate the issue
- “Correct of Error” is written and reviewed during on calls. It is similar to Post Mortems in other companies.
- Attending On calls does not usually increase additional compensation unless on calls are so frequent or certain laws in countries like Germany
- Every team most certainly have Operational Dashboards and Metrics. There is a lottery to show these dashboards and present them to other teams during big meetings.
Planning and Documentation:
- Very focused on documentation. Usually cannot exceed more than 6 pages of well written documents
- For new products and services to get funded, have to write documentations from customer point of view including FAQs. Documentations seems to be used as a data indicator for promotions as well.
- For peak season periods there is operation planning like prime days or black fridays.
- Product roadmaps are usually bottom up. Meaning engineers/product managers proposes the changes. This is eventually floated all the way to VPs to consider which projects should be funded.
Advices (taken directly from the article):
- Take Leadership Principles (LPs) seriously and speak them. “Embed them into each piece of work and discussion you have. You will be evaluated and decisions will be on the basis of LPs. Customer obsession is the most important LP.”
- Unblock yourself and rely on others. “The learning curve is very steep due to the vast number of internal tools. Unblock yourself and rely on others heavily at the start.”
- Get oncall, early. “The sooner you get oncall, the faster you’ll learn, and the easier the next oncalls will be. It’s like a band-aid in that it’s better to just experience the intensity of ripping it off in one go.”
- Be vocal in what you want to work on. “Don’t be afraid to ask to work on projects in sister teams and not under your immediate manager, if you find them interesting. It’s in their interest to keep you happy (hire and develop the best). Some of the attrition I have seen could’ve been easily avoided with a change of team or a more open discussion with the SDM.”
- Embrace writing CoEs (Correction of Errors). “It’s a rigorous experience but at the end of it you should be an expert in that domain. A single end-to-end COE ownership will give you enough data points and ownership in an area for an L4>L5 promotion. Presenting a COE to a L8+ can be a fantastic learning experience and it can even boost your career.”
- Learn to write in the Amazon style. “Writing, and writing well is one of the best things you can learn to do at Amazon. In order to progress your career, you’ll also need to learn it.”
- Move teams if it’s not a good fit. “You’ll want to find a good team that you can do good work on. Take advantage of internal mobility and move on to a different team if your current team does not match this description.”
- Your manager and skip level. “Get chummy with both of them. You’ll need a good relationship with them for your career to progress as fast as you’d like it to.”
- Take initiative. “You need to take more initiative than at many other, similar-sized companies, thanks to both the scale and end-to-end ownership being expected.”
Ref:
Coffee Break 
Leave a comment