More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
March 15 - April 25, 2022
We want to teach employees how to teach themselves. That’s the essence of a learning environment. We’re building a mindset, a way of analyzing and solving problems. The Socratic method is as effective with business problems as it is with complex legal cases.
When things go wrong, it’s either a time to blame, or a time to learn. I believe each failure is an opportunity to uncover deep learnings about how the organization operates, and what could strengthen it systematically, and then take action.
Knowing that people inevitably make mistakes, why did “the system” allow that mistake to impact customers? Answering that question will get you to the true root cause, or, more realistically, true root causes.
The best measure of somebody’s future travels are their past travels. We want people who want to learn, and bootcamp grads who’ve changed professions mid-career demonstrate exactly that willingness.
What happens when something goes wrong in government? Instead of quickly learning and iterating, or using it as a learning opportunity, the participants are hauled before Congress and grilled on national television.
When you hold the whole picture in your heads and you work together every day, you can make progress incredibly fast. That’s the power of a small team—there are no proxies; you’re just directly solving customer problems with your code.
Lacking a customer, the loudest voice or the highest pay grade decides what people should work on. But having a customer grounds the team’s work in discoverable truths that customers can express.
Bikeshedding, therefore, is the tendency for nonexperts in charge to expend a lot of calories on unimportant details, because they lack the context to make the most important decisions.
Teams do their best work when each member of the team feels accountable to the customer, and a deep sense of purpose to serve the customer. Small teams enable that kind of connection and purpose, with a mission that comes from inside the team, driven by a primary interaction with the customer and their problems, not from executives.
What you want is for members of the team, and the team as a whole, to believe what they’re doing is important. That intrinsic motivation doesn’t come from inspirational speeches or a big paycheck. It arises from the knowledge that your work has real impact on the lives of fellow human beings.
People will forget what you said, forget what you did, but people will never forget how you made them feel. —Maya Angelou
Hospitality is the foundation of my business philosophy. Virtually nothing else is as important as how one is made to feel in any business transaction. Hospitality exists when you believe the other person is on your side. The converse is just as true. Hospitality is present when something happens for you. It is absent when something happens to you. Those two simple prepositions—for and to—express it all.
Danny Meyer
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.
Danny Meyer
In every business, there are employees who are the first point of contact with the customers (attendants at airport gates, receptionists at doctors’ offices, bank tellers, executive assistants). Those people can come across either as agents or as gatekeepers. An agent makes things happen for others. A gatekeeper sets up barriers to keep people out. We’re looking for agents, and our staff members are responsible for monitoring their own performance: In that transaction, did I present myself as an agent or a gatekeeper? In the world of hospitality, there’s rarely anything between.
Danny Meyer
The first step is ensuring proximity to customers. Keeping the people who build the product close to customers makes so much sense, it almost seems unnecessary to explain how and why companies should do it.
Any individual feature is too small to merit the organizational effort to prioritize it. Yet when you remove all that activation energy, and let a developer see a cool customer problem and spend a few hours solving it—almost as a passion project because they can—your customers see you as a responsive, customer-focused organization.
By removing layers of overhead, engineers who are close to customers can make low-risk decisions that benefit customers. Customers become human beings, not database entries or masses acting statistically. Those stereotypes about developers being antisocial types who are detached from humanity—that’s rubbish.
“One of the oldest sayings in business is ‘The customer is always right.’ I think that’s become a bit outdated. I want to go on the offensive to create opportunities for our customers to feel that they are being heard even when they’re not right. To do so, I always actively encourage them—when I’m on my rounds, in our comment cards, and in letters or emails to us—to let us know if they feel something’s not right. When they do, I thank them.”
Danny Meyer
Think about the format of a news story or press release: they’re written to relay the most important piece of information in the headline. Effective headlines hook the reader by tapping into something they care about. For a customer, it’s a problem they need solved. The subheadline puts a little more meat on the bone. The opening paragraph, more detail, and so forth, until the closing sentence relays the least important detail.
Great product development press releases start with the understanding that the customer is the reader, and the words have to hook the customer into caring about the product.
At Twilio, I often say “our strategy is simple: build things our customers want for which they’ll pay us.”
If you need to run a mile, make sure each stride is well executed. It’s important to deliver working software with every sprint.
accurately estimating the amount of work required to implement functionality in software is an art, which we attempt to turn into a science with Agile practices. And it’s a team effort.
Note that story points are a fictional metric—they’re not based on any hard metric, like lines of code written—so they’re not transferable between companies or teams. (As an aside, lines of code written is a horrible metric that you should never care about—less is more when it comes to good code.)
Think of the User Stories as an artifact that describes the work to be done, all from the customer’s point of view. This differs from the Product Requirements Docs (PRDs) of yesteryear, which focused more on what the software needed to do than on what the customer needed. The difference may seem subtle, but it’s important.
A bad User Story describes a large complex system, while a good one is limited in scope. This increases predictability and limits surface area for misinterpretations or big open questions. A good User Story, though, does describe end-to-end what the customer needs to accomplish, so that the developer can internalize and understand the customer problem. This allows the developer to make good implementation decisions and use their intuition versus just “doing what they’re told.”
In every sprint, while the Development Team is primarily focused on building that sprint’s set of User Stories, the Product Owner is primarily focused on finalizing the set of User Stories for the following sprint. While ownership of the backlog lives primarily with the Product Owners, fleshing out the stories with technical details is a tight collaboration, far from a “throw it over the wall” kind of process.
there are four attributes in software development: features, deadlines, quality, and certainty. Generally speaking, you can pick any three, but you can’t have all four.
There are not just diminishing returns, but negative returns, to adding developers past about ten people. Thus the focus on small teams. But that also explains why you can’t add more people, within an existing team structure, and expect more output.
Over longer periods of time, though, good leaders can fix the problem to better divide and conquer. Splitting the problem domain, code, and people into multiple smaller teams allows you then to staff back up and add more people.
Agile itself is not bad for developers—in fact, it’s quite good. But implementers need to take care to ensure that developers stay engaged in the business and treat development as a collaboration, not a task assignment exercise.
the brilliance of Zuckerberg’s original motto: “Move fast and break things.” He acknowledges that moving fast incurs a cost—things won’t be perfect—and he’s okay with that. If you break something, I have your back as long as you were pushing the envelope to invent something for our customers. By doing this, he ensures that the innovation directive will prevail.
To make your developers successful, you need to invest in infrastructure. You don’t need to do this up front. In fact, these systems tend to evolve organically as your software team gets bigger and more sophisticated, but you do have to actively feed it.
In a DevOps environment, the same developer writes the code, tests the code, packages it, monitors it, and remains responsible for it after it goes into production.
the person who writes the code also “wears the pager” for that code after it goes into production. It’s your code. If it crashes, you fix it.
Instead of focusing on how much it costs to build a platform team, focus on the return those platform engineers can deliver. But also realize that these investments take time to pay off. Not only do you have to build the team, and have them build the infrastructure; the other teams need to adopt it. This cycle takes time, but it pays back in spades over a multiyear investment. It truly becomes a source of competitive advantage.
the companies that harness the power of software to deliver the best digital customer experiences will survive and thrive in the digital age.
