At Amazon we have a role called TPM - of which I am one. It's not a role that I was familiar with until I started here.
As I talk to more and more people, candidates and peers my definition/description of this role have drastically evolved. Here are my current ramblings on this.
You may or may not know that Amazon.com (the website) is made up of hundreds (maybe more) of micro-services. Generally a service is owned by a 2-pizza team - that is a team you can feed with 2 pizzas. This creates a challenge for teams that build features that consume those services. And gets even more complex when you consider lineage of services, that is the hierarchy of service dependency.
In past jobs, we used to talk about things like service bus and services directories. These were ways that we were trying to tame service based architectures. In the end these met with marginal success (I am being generous). Actually they were very complex, obscure, hard to keep accurate. I remember spending months arguing over a service taxonomy. Yuck.
At Amazon we don't try to tame this environment. The rationale? It's a Day 2 type of mentality.
If you're thinking like a startup you aren't spending a lot of time trying to organize all your services. You're not trying to stamp out duplication. Day 1 companies are innovating, trying new things, letting things evolve and deprecating the stuff that doesn't "survive".
TPMs have to live in this world and make it possible for everyone else to as well. It is our job to architect technical solutions in this environment. To negotiate with others to get things done. Sometimes it means that we have to get scrappy. Your ability to do this and deliver something great for our customers is what makes a great TPM and what keeps Amazon...well being Amazon.
No comments:
Post a Comment