Web Excursions 2022-01-06
I Took a Job at Amazon, Only to Leave After 10 Months.
After working at GoDaddy for 5.5 years I was ready to make a change.
I was recruited by Amazon to work in their devices org, and after joining learned that specifically I was joining a centralized UX team with in the sales and marketing division within devices
Interviewing
Amazon interview loops are fairly similar across roles and heavily rely on behavioral interview process through which they are assessing your answers against the Amazon Leadership Principles.
To Amazon’s credit, the leadership principles are not just bulletin board material, they are referenced and used actively in decision making
How Amazon Operates
Amazon effectively operates like a federation of smaller companies.
There are (extremely) large organizations, which break into divisions, and then into small, functionally independent teams.
At the time I joined, the Devices Org was 29,000 employees.
Each individual team owns its own infrastructure, roadmap, and goals which trickle down the org.
This is further emphasized when Team A, for example wants Team B to build an integration or work on something, they will “fund headcount” out of their operating budget.
When you operate at this type of scale, centralization is the enemy of efficiency.
This is a paradox. In order to be efficient on a macro level, it requires being (very) inefficient at the micro level.
For example, almost every organization is going to build their own tooling to solve effectively the same problems, but tailored to their specific use cases.
Every org (probably) has its own forecasting system, way of publishing content to the website etc.
A good example of this was when I joined, I wanted to see if there were any design systems for internal tools. It turned out there were 56
The most surprising thing I encountered when joining was how manual the vast majority of processes are.
It blew my mind how many business critical processes were managed with excel spreadsheets being shared via email chains.
Documentation Is Essential
One of the things I appreciate most about Amazon is their emphasis on documentation.
Every important decision is presented in the form of a document:
PRFAQ - Press Release and Frequently asked questions: a document format used to pitch a new idea or investment opportunity
OP1 - A team’s 1 year business plan: what they are going to work on and try and accomplish
BRD - A tactical plan for a particular project that lists all of the requirements in detail
Design Document - An engineering document which lays out the technical strategy with high level of detail, documenting the approach as well as alternatives considered
1 Pager - A summary document used to bring a stakeholder up to speed on a particular topic used for building alignment around goals
Global wiki - where you can learn about almost every topic at amazon.
A document centric strategy is critical at Amazon because of its decentralized nature.
Instead of a person being the source of truth on a subject, the document becomes the source of truth.
This makes communication much more egalitarian and explicit.
Also documents go through a number of revisions (usually includes 5-10 revisions) before they are reviewed by key stakeholders.
A document review meeting always begins by reading the document.
The assumption is that you have not read the document in detail and
so there is a practice to create space for everyone to thoroughly read through.
One quirk I find amusing is that everyone wants the document to have line numbers so they can reference specific points quickly.
After the document is read, the discussion begins and stakeholders go through each point.
The meeting ends with some sort of action item (go do this, meeting with these people and update the document, etc).
Teams are Fragile
When I first joined Amazon, there was a huge push for an aggressive start date.
This was because I was backfilling an open role.
The designer who’s place I was taking was still at the company but focused on other projects so the product team had been without a designer for 6 months.
ironic that they are asking me who has no clue what they are doing to deliver critical work.
People come and go (which has the net impact of making you feel like you are just a resource).
I reviewed the plan for the product I was working on and each quarter represented a scope of work (in my opinion) that you could build a whole company around -
CRMs, Email Builder, Complex Automations etc,
and my first thought was LOL we are never going to build all that yet it was what had been promised to stakeholders.
the path to promotion between PM, Engineering and Design are all different and have incentives that conflict with one another.
In many cases, in order for a PM to get promoted they need to deliver some large scale “win” which consequently can encourage overcommitment, fudging impact numbers / justification.
In my case, being overly ambitious contributed to poor morale on the engineering team,
which in turn lead to longer delays in project execution and shorter on call rotations.
the on call rotation shrinks meaning each engineer has to be on call more frequently.
Everything is Urgent (but takes forever)
Because of the federated operating model, there are many programs and teams who’s charter is to solve a problem that requires integrating with multiple tools or products.
you naturally inherit the constraints of every single surface you are integrating with. It is nearly impossible to be aware of all of these constraints so the process usually follows a similar pattern:
Design a solution
Review with stakeholders
Surface all the problems or things you didn’t account for
Rinse repeat
most team’s don’t want to “wait around” for design to be available to assist in the process, and are anxious to start building which usually results in half solutions.
Unfortunately, the majority of my time is spent doing “program” style work which leaves about 10% of my time for technical work.
companies’ critical needs will always trump your career ambitions and often there is a large delta between the job you were hired to do, and the job you actually do.
Everything is built in house
Amazon in particular is obsessed about data security and so it builds all of its tools in house.
If I am being perfectly honest, I can’t think of a single internal tool at Amazon that is better than a commercial counterpart.
Closing thoughts:
everyone’s experience at a big company will vary by organization and even by team.
Related: PR FAQs for Product Documents
A Press Release (PR) Frequently Asked Questions (FAQ) is a customer-centric document for designing new products. It is an idealized future “Press Release” (PR) and associated FAQs.
A PR FAQ follows a fairly strict format:
A Press Release (PR), written from the future point-of-view of when the new product is released.
A Public FAQ, detailing the questions that a customer might have about the product, written as if it is public product documentation that is released at the same time as the PR.
An Internal FAQ, answering any questions from internal stakeholders that have come up during the product development process.
The PR FAQ format has been around a while, but it was popularized by Amazon (where I first learned it) and is now used by Product Managers widely.
Template for a PR FAQ
Heading: short name for the product that the target customers will understand Subheading: One sentence saying who the market is and what the benefit is
Summary: 2–4 sentences that gives a summary of the product and the benefits. Should be self-contained so that a person could read only this paragraph and still understand the new product/feature.
Problem : 2–4 sentences describing the problem that a customer faces, which this product solves. Tests your assumptions about the pain-points that you are addressing.
Solution : 2–4 sentences, describing how the new product/feature addresses this problem. Tests your assumptions about how you are solving the pain-points.
Getting started: 1–3 sentences describing how someone can start using this product/feature (if it’s baked into the existing product, say this explicitly). Tests your assumptions about how easy the ramp-up is for your customers to take advantage of the new product/feature.
Internal quote: Someone within your company being quoted about what they like about the product/feature. Tests your assumptions about the value you are creating for your customers and how you position this product within your broader product offerings.
Customer Quote(s): a hypothetical customer saying what they like about the new product/feature. Tests your assumptions about how you want your customers to react to the new product/feature and your ideal customer profile. They should be doing something that they couldn’t do before, doing something much quicker and easier, saving time and effort, or in some other way making their life better. Whatever the benefit is, their delight in the benefit(s) should be exhibited in the quote. This should be multiple quotes from different customers if you have multiple profiles of ideal customers, example: mid-market and F50 customers.
Call to action: 1–2 sentences telling the reader where they can go next to start using the product/feature. Tests your assumptions about whether this is a feature that is automatically on, something they need to turn on, a beta-release, etc.
The PR/FAQ format works because it is:
Customer-centric
Forcing your assumptions to be explicit
Interpretable by any stakeholder
Increases the ownership of stakeholders
Simple enough to be created by any stakeholder
What Is the Difference Between the Folder and Directory (And Other Special) Progids?
When you’re installing your shell extension, you need to know which progid to hang it off of inside
HKEY_CLASSES_ROOT
.“Folder” is the progid for any shell folder. It could be a virtual folder (like Control Panel) or a file system folder (like
C:\WINDOWS
).“Directory” is the progid for file system folders. This is a subset of “Folder”.
“
*
” is the progid for all files. Doesn’t matter what the extension is.“
.
” (that’s a single period) is the progid for files without any extension.“
AllFileSystemObjects
” is the union of “*
” and “Directory”. It is the progid for all files and for file system directories.