A collection of advice, quotes and rules.

Table of Contents

• Promotions
• Rules
• Quotes
• Books
• Advice
• Force multiplying Activities
  • Share best practices
  • Create templates
  • Build tools
  • Introduce a new mental model
  • Propose new goals and metrics
  • Create or modify a mechanism
  • Propose organizational changes
  • Participate in strategic sessions
  • Create durable deliverables

# Promotions

https://jvns.ca/blog/brag-documents/

# Rules

• Don't surprise your manager.
• Don't break Prod.
• Design early, or ship late.
• Run the code on your own desktop before running it anywhere else.
• Yes, all of it.
• Leave the code better than you found it.
• Metrics or it didn't happen.
• Ask the dumb questions. At least one person is guaranteed to learn something.
• Before you reinvent the wheel, use the one that's laying around.
• There are five correct answers to any question:
  • "Yes."
  • "No."
  • A number
  • A date
  • "I don't know, and I'll find out by "
• Answer. Explain. Educate (in that order)
  • When talking, listen for opportunites to A,E,E.
  • When writing, create opportunites to A,E,E. The writing will come across clearer.
  • When listening. Listen to what is not being said. You need to have an expectation for what should be said (ei. if A is missing then it was not said and you should dig deeper).

# Quotes

• I do not pretend to start with precise questions. I do not think you can start with anything precise. You have to achieve such precision as you can, as you go along. -- Bertrand
• Writing is nature's way of letting you know how sloppy your thinking is. -- Guindon
• Correlation is not causation but it sure is a hint. -- Edward
• If we have data, let’s look at data. If all we have are opinions, let’s go with mine. -- James
• The data may not contain the answer. The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. -- John
• I have no tools because I've destroyed my tools with my tools. -- James
• If you want to build a ship, don’t drum up the [people] to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. Incorrectly attributed to Antoine de Saint-Exupéry
• You must never confuse faith that you will prevail in the end—which you can never afford to lose—with the discipline to confront the most brutal facts of your current reality, whatever they might be. James
• Much of my trip focused on my personal faults, which were displayed in detail, and my anger at myself for being unable to correct them. The answer I got was "GET STRAIGHT! DO WHAT IT TAKES TO STRAIGHTEN OUT THE SHIT!" When I argued that it really didn't matter, the answer was "EVERYTHING MATTERS" -- Daniel
• There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. -- Leon
• There are only two hard problems in distributed systems:
  • Exactly-once delivery
  • Guaranteed order of messages
  • Exactly-once delivery -- Mathias
• Among the maxims on Lord Naoshige's wall there was this one: "Matters of great concern should be treated lightly." Master lttei commented, "Matters of small concern should be treated seriously." Among one's affairs there should not be more than two or three matters of what one could call great concern. If these are deliberated upon during ordinary times, they can be understood. Thinking about things previously and then handling them lightly when the time comes is what this is all about. -- Yamamoto
• In its passivity and resignation, cynicism is a hardening, a calcification of the soul. Hope is a stretching of its ligaments, a limber reach for something greater. -- Maria
• The universe tends toward maximum irony. Don't push it. -- Jamie
• The universe seeks equilibriums; it prefers to disperse energy, disrupt organization, and maximize chaos. Life is designed to combat these forces. We slow down reactions, concentrate matter, and organize chemicals into compartments; we sort laundry on Wednesdays. -- Siddhartha Mukherjee, in The Gene: An Intimate History
• A foolish consistency is the hobgoblin with fine calipers, adored by little statesmen and philosophers and developers. -- Jim
• Move as a team. Never move alone -- Public Enemy, "Welcome To The Terrordome"
• Work. Don't stress about the fruit of your labor. Work. -- Premalatha
• If I knew less, I’d have been better off. -- Benjamin
• Programs must be written for people to read, and only incidentally for machines to execute. -- Harold
• Adjectives are like lard. They make all writing flabby. -- Jake
• New organs of perception come into being as a result of necessity. Therefore, O man, increase your necessity, so that you may increase your perception. -- Rumi
• If we could see the whole truth of any situation, our only response would be one of compassion. -- Yongey
• Be joyful though you have considered all the facts. -- Wendell
• [HSMs] are not a sustainable operational load. -- Todd
• The only good thing about [certificate] pinning is that it makes revocation seem like a good idea. -- Trevor
• When someone says “assume that a public key cryptosystem exists,” this is roughly equivalent to saying “assume that you could clone dinosaurs, and that you could fill a park with these dinosaurs, and that you could get a ticket to this ‘Jurassic Park,’ and that you could stroll throughout this park without getting eaten, clawed, or otherwise quantum entangled with a macroscopic dinosaur particle.” -- James Mickens, "This World of Ours"
• It's a program, not a project. -- Michael
• HTTPS & SSL doesn't mean "trust this." It means "this is private." You may be having a private conversation with Satan.
• A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert A. Heinlein, in Time Enough for Love, 1973
• The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs. -- Maurice

# Books

• Required books for an SDE I
  • The Design of Everyday Things: More than a book about physical design, it illustrates how you actually obsess over customers.
  • Every Computer Performance Book: How to Avoid and Solve Performance Problems on The Computers You Work With: This deceptively simple book will give you a grounding in the basics of keeping complex systems running, and improving them as you go.
• Useful books for all SDEs and SDMs
  • How Big Things Get Done, by Bent Flyvbjerg and Dan Gardner. Most projects come in late and over budget. This book will help you avoid that.
  • The Design of Design: Essays from a Computer Scientist: By Fred Brooks, the author of the “Mythical Man-Month.” These essays are underrated gold.
  • The Elements of Style, by Strunk and White: At some point in your career, you realize that the majority of your writing is for other people. If it's in English, let this be your constant companion.
  • The Systems Bible: The Beginner's Guide to Systems Large and Small: At first, you laugh at all the jokes. Then you realize he's describing a situation that came up in a recent COE. Then you stop laughing. And then you realize this is a bundle of koans for system designers and operators.
  • The Utopia of Rules: On Technology, Stupidity, and the Secret Joys of Bureaucracy: Sophisticated, intelligent critiques of complex bureaucratic systems (and their critics).
• Books specific to TLS, PKI or cryptography
  • Bulletproof TLS and PKI, by Ivan Ristic. The most comprehensive work on the subject.
  • Real-World Cryptography, by David Wong. I'm not a cryptographer. My mathematical abilities are not strong, and yet this book filled in a lot of the gaps in my cryptographic knowledge..

# Advice

• Debugging advice from Rob Pike
• What have you tried?
• Sane Data Updates Are Harder Than You Think: Three part-series that pretty much nails the problems you'll find in data synchronization:
  • Part 1
  • Part 2
  • Part 3
• Is it worth the time?
• The basic laws of human stupidity
• Mark Dominus' approach to annual self-evaluations
• Why Things Go Right
• Controlling Your Environment Makes You Happy
• What makes a good intern project?
• Automation is Good Intentions: automation is not the end. We still needs feedback loops to make sure the automation is applying the correct set of rules.
• Zonal Architecture for Regional Services: Aside from being good advice for service redundancy, this is also a good primer on what we mean by "regional," "zonal" and "cellular" around here.

# Force multiplying Activities

"Force-multiplying" is manager-speak for making everyone around you better at their job. But how do you do that? The following is written from the standpoint of a UX designer, but you can easily adapt it to your domain.

## Share best practices

• Share best practices in one-off settings (Slack, Email, meetings, etc.)
  • Make your thought process visible
  • Highlight others' great examples
  • Take on a mentee or an apprentice
  • Become a mentor or start office hours

Pro tip: Don’t just share a best practice or a link to an interesting article, describe the thought process behind it and why it’s relevant to your audience. This makes advice more useful—nobody will be solving the exact same problem as you in the future, but the approach can be similar.

• Create internal documentation
  • AWS Ops Wins (case studies that reduce latency, cost and errors to AWS and our customers)
  • Document writing for designers
  • Project milestones and resources
  • Internal docsite: Design system documentation
  • Internal Q&A platform: Answer a question publicly, i.e. on Sage, or on Answers

In all these examples: When you document a best practice, others are able to learn from you without the need for a face-to-face interaction

• Write a blog or newsletter:
  • Write It Right
  • Luu's Tran’s Blog
  • Adam Elman’s Blog
  • Making Great Decisions Blog
• Host in-person training (mentor at scale):
  • Required new employee training (i.e. Peculiar UX)
  • Regular 1-to-1, 1-to-many coaching (i.e. Office Hours, CXBR consultations, presentations)
  • Seasonal training sessions
• Record videos:
  • For all Amazonians: Working Backwards
  • For UX: Design tutorials
  • For UX, PM, and Devs: Kumo Clips

## Create templates

• Doc templates:
  • Amazon-wide document templates
  • Org-wide templates for project kick-offs, research reports, and other common project milestones

Pro tip: Create a template whenever there’s an activity that happens over and over again and is done by different people. Combine sharing best practices (#1 above) with creating templates to make your guidance easier to copy and more actionable

• Design templates:
  • Compositions of design system components
  • Presentation templates
  • Research methods (i.e. a great participant screener template for usertesting.com would ensure more inclusive recruiting for others' research projects)
• Ideation / workshop templates:
  • Quip templates for remote workshops
  • Quip templates for self-service ideation sessions
• Code templates:
  • Design files + design system component code

Code templates make it easy to reuse patterns. Patterns may reduce unnecessary overrides of the design system.

• Decision-tree templates:
  • AWS Well-Architected

## Build tools

• Examples of tools built by Amazonians:
  • PR/FAQ Writing Tool
  • UX Writer Tool
  • Amazon Accessibility Evaluator
  • Non-inclusive Term Converter
  • Policy Engine (discover problems that need attention)
  • Kumo Automation Service (a framework that allows people to build tools to automate away support issues)

Pro tip: Great tools apply best practices automatically to someone’s document, code, or designs.

## Introduce a new mental model

• Mental model examples:
  • Company-wide: Leadership Principles
  • Org: RACI framework (Responsible, Accountable, Consulted, Informed), used to make decision-making more efficient
  • Org/Team:
    • Shape the culture via a vision/mission statement
    • Tenets – especially aspirational tenets, which will allow you to push your team's bar higher
    • List of key truths or decisions made to establish a common ground during discussions
      • Returns Progress Tracker
  • Product: Product framework (a product framework may expand the scope of work and ground future conversations): "Zones" framework on Product Detail Pages (video – 12:18+)

Pro tip: Great mental models are principles and frameworks that set a new, higher standard for the team’s work quality. With all these examples, it takes documenting and then proposing the new mental model to your peers or leaders to get buy-in.

## Propose new goals and metrics

• Goals can be introduced at different levels:
  • Org: “A CXBR review is required for all new products”
  • Org: “Each employee must attend Customer Connection training twice a year”
  • Org: “Resolve # shopper frustrations”
  • Product: New product metrics, evaluated regularly in MBRs (product goal can bring ongoing focus to an area that may not be getting enough attention)
  • Design team: “100% of design projects will identify the customer value they will deliver and then measure whether it was delivered"

Pro tip: Goals are a great way to influence: they add a target and ongoing accountability to meeting a certain outcome.

## Create or modify a mechanism

• Mechanisms created by Amazonians:
  • Andon Cord, Andon Cord for Everyone
  • Shopper Frustration Program
  • Customer Service Contact Review
  • Role Guidelines
  • Resource: How to create a mechanism
  • Resource: Mechanisms eLearning

Pro tip: Mechanisms provide solutions to recurring problems and don’t require you to be in the room to affect positive outcomes. But you don’t always have to create new mechanisms, start by first thinking about whether you can adjust an existing one.

• Modify a mechanism:
  • Add a new required field to a Quarterly Planning Doc Template
  • Add new required FAQs to your org's Press Release template
  • Add a new step to Embark for new employees
  • Add required steps in design reviews
  • CC a UX designer on all front-end code reviews to improve Design Quality Assurance

Pro tip: Modifying a mechanism always starts with (a) identifying what are the existing mechanisms (b) changing it get better outcomes in the future. The “Modify” tactic also applies to existing tools, templates, goals, and metrics.

## Propose organizational changes

• Ways to affect organizational structure and resourcing:
  • Author a narrative, PRs, or OP1 paragraph, which will require new resources
  • Partner with others to create a company-wide group
    • Software Builder Experience Org (created to focus on improving the experience for software builders across Amazon)
    • Amazon Affinity Groups
  • Author a cross-org narrative that solves shared problems (i.e. via multi-org working groups)
  • Take on direct reports

## Participate in strategic sessions

• Strategic session examples:
  • Cross-org: Become a CXBR or a Hiring BR
  • Org: Lead brainstorming / Think Big strategic sessions (i.e. get invited OR lead them, make it more inclusive and more customer obsessed)
  • Org: Provide feedback on PRs, project kick-offs (feedback on PRs influences all downstream steps)
  • Org/team: Organize generative research to uncover new opportunities for the business

## Create durable deliverables

Most "project" deliverables only advance the current project from one stage to the next. "Durable" deliverables on the other hand—are useful during multiple stages of your current project as well as during future projects.

3 Steps To Apply a Force-Multiplying Activity

• Aim for atleast for 10% of deliverables to be durable.
• Take initiative to define durable deliverables per project (atleast 2)
• Make sure that these are easy to find and not lost within a project.

Examples:

• Architecture diagrams
  • Amazon Shopping Product Detail Page "Zones"
  • AWS Trusted Advisor Technical architecture
• Coding standards
  • Guidance for Region Building and Special partitions in AWS Kumo
  • DynamoDB Operational Best Practices
• Project/Program/Team tenets
  • Tenet examples
• Design principles
  • AWS Trusted Advisor UX design - unification principles
• Personas and their Jobs-To-Be-Done (JTBDs)
  • AWS Personas
• Journey maps
  • AWS Support Troubleshooting Journey Map
• Timeless customer needs
  • AWS Support timeless customer needs
• Ideal business outcomes
  • Measurable goals tracked in a "2x2" business health update
• Ideal customer feelings/Emotional Design outcomes
  • Tutorial: How to apply Emotional Design to your product
• North Star Designs (mockups or Press Release descriptions)
  • Your Orders UX mobile design architecture video
• Design system and brand guidelines
  • Amazon Shopping's Rio design system

Measuring Impact

To ensure your force multiplying activity is working, you should have a way to audit its effectiveness on a consistent basis. Data will help you adjust along the way and it will allow you to show the impact of your work. Here are several ways impact can be measured:

• Awareness – this includes: views, clicks, attendees, subscribers, anecdotes (note: these provide a signal on adoption but may not be strong enough to demonstrate impact, see #2)
• Before-and-after comparisons – anecdotal examples of improvements (i.e. via anecdotal or survey feedback), A/B tests, Connections, Tech Survey results
• Organizational changes – resource reallocations, new investments, changes to mechanisms, executive buy-in of new initiatives

Pro tip: Since being an effective force multiplier requires adoption, collaboration, and usually buy-in from your peers and leaders, regular Earn Trust-building activities are key to maximizing your impact!