#amazon #leadership #principles Importance of Amazon's LP "Deliver Results" for Engineers.
Perhaps, the most important LP at Amazon is "Deliver Results". It is kind of a minimum requirement from everyone to consistently deliver result. Across all levels it is only about delivering results. No one cares about something cool and complex you learned if it has not customer impact.
"Deliver results" is about your ability to unblock yourself when problems arise: how you can handle conflicting opinions, being not unfamiliar with a technology, or even simply getting comments in the reviews that postpone your delivery.
"Deliver results" is NOT about high quality or high standards. However, the higher your level, the higher quality is expected. At the end of the day, let's be fair, "Deliver results" does not go in the isolation and is normally backed by the other LPs. This makes it very powerful for Amazon.
At the interview, you will be asked about a story when you demonstrated this quality. So be equipped with a story when you were able to deliver results despite difficult circumstances.
#amazon #leadership #principles Importance of Amazon's LP "Deep Dive" for Engineers.
You ONCE spend slightly more time to understand how something works and then uses this knowledge as a super power. The easiest way to train this skill is to dig something you do not understand asking 5 Why's. Each time you ask Why you deepen your expertise and gradually get expertise to influence others with the knowledge. It works - I proved it myself several times at Amazon
I must clarify that my interest is frameworks/libraries and developer tools, where *the customer is a developer*. My first piece of generic reusable code was a rainbow-colored button control in Delphi when I was ~14. At NetDec (Tashkent) I led the team to create UZTO framework, a la 1C:Enterprise in C#. Then at ComponentOne, the whole business is to sell software components, e.g. supercharged DataGrid for .NET. Those years my ultimate dream was to live in Redmond and work on .NET or Visual Studio. Then I joined Google where the job is to create the developer infrastructure used by Chrome engineers. I also fell in love with Go, hence the dream to join the Go team; but that didn't work out.
I learned that the higher you go in the career/level, the more it is important to work in a domain you care about. This is because at Staff+ level an engineer no longer can just write code or design systems, but must think about the business side - which is hard if you don't care about the domain of the business. For example, I don't want to go to Facebook or Netflix because I don't care about social networks or movies that much. Chrome isn't perfect either: people come here because they care about the *Web* - this ended up being the main limiting factor of growth in my team.
With such narrow speciality, there isn't a lot of choice really: if I don't know about a product, then it is probably not interesting. Also, the more developers use tool/framework, the better; this basically narrows down the choice to the most popular frameworks and tools. There are not a lot of teams like that, so where do I go?
