Context

Keywords

Summary

• Messaging to legacy companies: In the present day where running experiments and iterating quickly is everything, outsourcing to agencies or hiring consultants to make software won’t do. It’s slow, expensive, and generally doesn’t get you the results you need. If all your competitors bought the same software, you would be undifferentiated. Outsourcing also significantly reduces your speed of iteration

• We’re moving away from solutions to enabling building blocks. With these, we can empower internal teams to do so much more with their talents. With solutions, there was little scope for change

• Companies should build in house only what is differentiable for their user experience, and buy everything else

• For business people to work together with developers, they should share problems and not solutions. Don’t ask them to grind out the code. Just communicate the problem. Then, let create their own specifications and just vet the specifications to make sure they address the problem

• Recruiting — don’t hire smart people and tell them what to do. Instead, ask them to tell you what to do

• Management: Have small teams with single threaded leaders. Then, have well documented “communication APIs” to foster effective communication across teams

Highlights

Chapter 1

• Create MVPs to gather information as quickly as possible and iterate on it quickly

• Twilio's billboard for a while was “ask your developer”. You may not know what Twilio (or a company like Twilio) does, but your developers do

• Outsourcing or hiring consultants to make software won’t do. It’s slow, expensive, and generally doesn’t get you the results you need. If all your competitors bought the same software, you would be undifferentiated. Outsourcing also significantly reduces your speed of iteration

• What would happen if you could iterate on your digital experiences and workflows on a weekly basis?

• By definition, a one sized fits all software doesn’t suit anyone very well. And if all companies buy the same software, they will be undifferentiated

• With off the shelf software, you have to change the business to meet the software. Instead, you should be able to change the software to meet your business needs

Chapter 2

• We’re moving away from solutions to building blocks [note: I think this is true for indie developers based on personal experience, but not sure if this is also true for enterprises yet]

• Selling packaged enterprise software to big corporations used to be a huge business. But it wasn’t good for the enterprises. SaaS solved this and provided savings (enabled by the cloud)

• But now that SaaS is everywhere and there are more developers, customers want more. They want much more customisation

• Micro services enable these [note: they have their own drawbacks, though]. A SaaS service can give you a core function as an API, and then your own developers can build on this and own the user experience

• Author's advice: build in house only what is essential for user experience, buy everything else [note: this is questionable advice. companies lose a lot of tacit knowledge when they outsource everything. Example: intel can't manufacture high ends chips on its own now because it has outsourced them to Taiwan for too long]

• Author gives an example of how Apple does not design or build its memory chips and flash drives in the iPhone because they are not differentiators, but designs its own microprocessors because they are a differentiator [Note: again, this is iffy. With the M1 chip, Apple is designing memory inhouse, because it can be a differentiator when integrated well with the processor. That's the problem with outsourcing important things to vendors — you can't build things that come from parts that were designed to work seamlessly with each other]

Chapter 3

• Started a bunch of failed or middling startups right before and after the dot com bust. Then joined aws to gain experience. In the middle, also helped launch stubhub

• For business people to work together with developers, they should share problems and not solutions

Chapter 4

• Enable programmers to be creative. Don’t ask them to grind out the code. Just communicate the problem. Then, let create their own specifications

• Assign problems, not tasks

• Ask developers to do tasks by hand first, so they have empathy for the user and deeply understand what the user needs

• Include developers early in the discussion, so that you they can get proper deadlines

• Never say things like “this should be a quick thing” or “you can do this in a day” if you don’t understand how exactly it’ll be done

• Say no to “this pixel goes here”. Yes to “this is the problem we have”

Chapter 5

• It’s okay to fail as long as you avoid ruin and learn from the failures

• Keep costs of experiments Low, and iterate a lot

• Just make sure that before you start an experiment you 1) the potential payoffs if the experiment works are large enough, and 2) you decide on the metrics for success before you start running the experiment

• Running experiments doesn’t work if you don’t follow up the winners with more resources. Water the sapling

Chapter 6

• Recruiting — don’t hire smart people and tell them what to do. Instead, ask them to tell you what to do

• Don’t have stupid rules like dress codes

• Sell the mission, and make sure you show people how your work is mission critical

• The author has no bonuses at his company! Believes that people should focus on the customers and not their bonuses. If someone performs really well, increase their salary at the next performance review. But pays more than industry

• Creative work is not influenced by bonuses. Though sales is totally driven by commissions

Chapter 7

• Meetings are all public, where only key members have “write access” (ie they can speak). But everyone has read access. This solves the problem of the two piza team rule. All teams know what’s happening

• Criticise people in public when their planning is not up to scratch. But when things go south irl, have a blameless culture so you can figure out where exactly things went wrong (blameless port mortem)

• Dont blame individuals. Find out where the organisational problems lie

Chapter 8

• Have small teams with single threaded leaders. Then, have well documented “APIs” to foster effective communication across teams

• The small size will mean that motivation and connection to the mission remains high. Single threadedness will ensure focus. It’s the equivalent of micro services that only do one thing

• Veto powers by management are a destroyer of intrinsic motivation

• Treat other teams as customers with internal revenue and costs, instead of as collaborators

Chapter 9

• Really put yourself in the customers shoes by interacting with them personally. Don’t rely on NPS scores — they’re useless

Chapter 10

Chapter 11

• Invest in infrastructure. It’ll help you move faster in the long term. Will also help reduce bugs and crashes

• Composable (micro services) > monolithic. Though this can go too far