More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
July 1 - September 17, 2022
It’s no longer a question of Build vs. Buy. Rather, it’s the existential question of Build vs. Die.
The only things companies should build themselves are the things that are core to their business.
Software that faces your customers, you should build.
Share problems, not solutions with your developers.
‘Scientists find problems, and engineers fix problems.’
The Wright brothers had a technical hypothesis about a wing shape. They did not have business hypotheses for how to build commercial aircraft, or develop an airline industry, or create airports in major cities to turn flight into a system of mass transportation. They built a minimum viable aircraft, a modified glider with a motor. (Once they proved the technical hypothesis, they did turn to business, and they built a company to manufacture airplanes, but neither had much interest in or aptitude for business. Their greatest innovation involved technology, not business.
Writing code that will be used by millions or even billions of people is powerful. Very few professions share the same sense of scale or impact. That’s why developers are particularly motivated by purpose.
“Hero’s Journey.”
small-teams approach, which enables all three facets of autonomy, mastery, and purpose;
When you can be yet another cog in the machine, or a key member of a small but important team—many
best compensation plans are those where employees feel they’re compensated fairly,
If the same person comes in the next week with the same problem and the same crappy answer—now you have a problem. That person isn’t learning. They suck as much as they did yesterday. Repeated failure is certainly a problem and needs to become a personal performance conversation. But that part isn’t open; that’s the private part.
primary measures of success were revenue, customer count, API uptime and latency, and customer net promoter score
The key is treating other parts of the company as customers rather than collaborators.
Instead of saying, “My name is Susan. I work on the User Ops team, and I’m assigned to the Atlas project,” she would say, “My name is Susan, I work on Atlas doing User Ops work.”
Ask your leaders if they succeed or fail in a given undertaking, do they feel it was largely within their control? If not, you might think about how to organize your teams so everybody feels like they’re accountable for decisions and outcomes.
Once you’ve organized the company into small teams, defined by a customer, a mission, and metrics of success, it’s time for them to get to work sprinting in service of your customers.
ideas about hospitality, a phrase not often uttered in software companies. To him, it means making your customers feel you’re on their side.
Service is the technical delivery of a product. Hospitality is how the delivery of that product makes its recipient feel.
Service is a monologue—we decide how we want to do things and set our own standards for service. Hospitality, on the other hand, is a dialogue. To be on a guest’s side requires listening to that person with every sense, and following up with a thoughtful, gracious, appropriate response. It takes both great service and great hospitality to rise to the top.
Keeping the people who build the product close to customers
when you interface directly with the customer’s words, the need becomes more real—more human—and the work becomes more meaningful.
If you imagine the reader as your customer, then the press release format forces you to start with what’s most important to your customer, and explain why what you’re doing is relevant to them; otherwise they’d stop reading. Forcing this kind of clarity is good, because it puts the customer at the center of the artifact.
allowing customers and developers to communicate.
My favorite way of understanding if teams are wearing the customers’ shoes is to walk around and ask developers what customer problem they’re working on. If they tell me a feature, then I ask what customer problem it’s solving. If they can’t answer it, then that’s a sign that the team might not be building enough connection with customers.
why the customer will care.
which customers demonstrated the problem, and how they validated that the customer problem represents a broad market need.
artifact
As executives, we often get very fixated on features, but customers rarely buy based on a feature. They’re more interested in the big picture, and we can always add features later.
small, autonomous teams are the basis of progress. We limit the size of teams to ten or fewer people.
Instead of a planning system that imposes work on them, we ask them to draft their own goals each quarter based on what they’re hearing from customers. When
two-week sprints, with the goal of having demonstrable progress
limit work in progress,
One of my favorite follow-up questions is to ask about the customer problem they’re solving. Often we get into a good conversation about the customer, but sometimes I get a shrug of indifference and an answer along the lines of “I’m not sure, it’s what the PM told me to do.” That’s when I can see teams may have taken Agile’s division of labor too far, and I know a follow-up conversation with the team might be a good idea—both for the leaders, who could be getting more out of their team, but also for the developers who are content with not knowing. I believe that’s ultimately career limiting.
...more
Operational Maturity Model (OMM). It consists of six categories of excellence: documentation, security, supportability, resiliency, testability, and privacy.
demonstrate excellence in each category.
