Tuesday, December 18, 2012

15 things I learned from "Shipping Greatness"

I finished reading "Shipping Greatness" by Chris Vander Mey (ex-Googler, ex-Amazonian). It's a great book, and I highly recommend it to anyone who is interested in learning how to ship software as close to schedule as possible, with as few bugs as possible, which is really the best we can hope for in this industry. Here are some things I jotted down while reading the book. You should really read the whole book, if only for the 'in-the-trenches' vignettes from Google and Amazon.

1. When tackling a new product, always start with the needs/problems of your customers (of course Jeff Bezos is famous for this approach at Amazon).

2. Have a mission statement that inspires and that also fits on a t-shirt if possible (for example the mission statement of the personalization team at Amazon is "increase customer delight").

3. Define your product by writing a press release (Amazon does it; it forces you to be succinct and to capture the essence of your product).

4. Avoid building a product that nobody wants. Engage real customers in testing early versions of the product or in giving feedback from on mockups and wireframes.

5. When putting together project schedules, remember that 60% is the best you can hope for in terms of productivity, so adjust the schedules accordingly.

6. Never release on a Friday! You don't want to scramble to find engineers available to fix critical issues over the weekend.

7. Apply the High School Embarrassment Test to the product you want to ship: will you be embarrassed if one of your old high school friends sees your product?

8. Run periodic bug bashes that are scheduled in the project plan and that are short (1 hour or so). Incentivize participation by giving away t-shirts, be grateful for every bug found -- better you find it than your customers!

9. Report on meaningful metrics: for example Google measures "seven-day active user count" (unique users who used the product in the last 7 days) so they can compare week to week.

10. Have a launch checklist - makes sure all moving pieces are accounted for, facilitates communication across different functions of the team (commercial pilots go through a checklist before every flight).

11. When you write email messages, make sure they are "crisp", i.e. clear, succinct, and covering a single topic if possible.

12. Before the daily standup meeting, have the dev lead give a 30-second brief on the status of the project (it sets the context of the meeting and reminds the team of critical things).

13. If one person in a team meeting is being strongly negative and dismissive of other people or of the product, take it offline for a one-on-one meeting rather than arguing in front of the team. 

14. If you need to give a presentation, make it short (10-15 min), deliver one and only one message, and tell a story if you can. Also use blue background with yellow and white font because it looks great on any projector.

15. In terms of getting things done, start by doing things that you, and only you, can do, so you're not blocking others (e.g. approve an expense report).

I really struggled to keep the list somewhat short. The book is full of similar nuggets. Go read it!

1 comment:

matt harrison said...

Looks like good suggestions. The yellow on blue for slides is interesting. Most people who have a strong opinion on that subject suggest that black on white is the best.

Modifying EC2 security groups via AWS Lambda functions

One task that comes up again and again is adding, removing or updating source CIDR blocks in various security groups in an EC2 infrastructur...