By Jeff Lawson.

Unsure where I found out about this book.

Jeff is a software engineer and the CEO of Twilio, this book is to help business-types to understand and get better productivity out of their software teams.

A quick read. Good for tech book club. 50% an advertisement for Twilio.

Why developers matter more than ever

1. Build vs die. An impassioned plea to build bespoke solutions instead of buying off the shelf as a competitive advantage to build what your customers actually want.
2. The new software chain. Micro-services.

Understand and motivate your developers

1. Hi, I’m Jeff, and I’m a developer. I was energized by his Notes4Free.com story! Background story of Twilio. Innovation is cultural. Important to have a relationship between tech and business people. Big takeaway: “Share problems, not solutions.”
2. Code is creative. Requests for startups - confirms my thoughts on having a list of problems to solve. “Call for solutions.”
3. Experimentation is the prerequisite to innovation. Big ideas start small. Experiment! A good experiment should 1: validate customer assumptions, 2: Lead to a big outcome. Write down your experiments. Ask your developer when to pull the plug on an experiment.
4. Recruiting & hiring developers. We all seek autonomy, mastery, purpose. Bonuses aren’t that motivating.

Making your developers successful

1. Create an open, learning environment. Learning how to learn, have guardrails and support.
   • Open project reviews. Public grilling from Chee Chew.
   • Socratic method. Public grilling from law school.
   • Blameless postmortem.
   • Learn by doing. Target spends 50 days for each IT staff member on learning.
   • Train leaders on smaller projects.
2. Small teams and single-threaded leaders. Amazon scaled its startup culture. Usually large companies lose their sense of energy. Two-pizza teams (or 2 dozen bagels). Every Twilio employee answers some customer calls and writes an app with their API.
   • Customer, mission, metrics. E.g. metrics: time from code check-in to deployment, revenue, customer count, API uptime & latency, customer net-promoter score.
   • Mitosis. When a team grows too big split it into 2 teams. It can take 6 months to refactor code to do this.
   • Single-threaded leaders & decision-making. VPs shouldn’t interfere. Bikeshedding. RAPID decision making.
   • Fallacy of better collaboration. Too many relationships. Better to have API-based “service contracts” instead.
3. Wearing the customers’ shoes.
   • Keep developers close to your customers, at least 1/quarter.
   • Start products with the press release for the customer (not investor).
4. Demystifying agile.
   • Can only have 3 of the 4: features, deadlines, quality, certainty.
   • Mythical man month.
   • Agile pitfalls… author not impressed by Kanban.
   • anything in moderation.
5. Invest in infrastructure.
   • DevOps. Developers in charge of feature all the way to deployment.
   • Operational Maturity Model (OMM): documentation, security, supportability, resiliency, testability, privacy.
   • Infrastructure provides “paved path” and “off roading” (routine should be easy, but complex should be possible).
   • “Canary” gradual deployment to users, with rollbacks if a problem.
   • OK for dev groups to be duplicating work to maintain independent control and speed. If pattern emerges can have a team nail it down.
   • Platforms are a force multiplier.
   • Tracking Time Spent Outside Code (TSOC)