More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
January 13 - January 22, 2021
The “interface” he’s skeptical of refers to Product Requirements Documents (PRDs), Kanban tasks, or other systems of throwing work over the wall.
That’s why getting everyone together on one team, and even eliminating the physical and organizational distance between them, is such a powerful tool. It catches wrong assumptions and bad decisions early in the process.
When the Atlas team meets, everyone attends. Thus everybody stays close to the customers and can give them what they want. They’re one brain, serving customers.
Chapter 9 Wearing the Customers’ Shoes
.h2
Customer centricity, as the name implies, is creating an organization that constantly self-corrects to put customers at the center of our decisions. Like a gyroscope that resists being moved off-center, a customer-centric organization resists the many forces that attempt to deprioritize customers. But it’s incredibly hard to do, and that’s where it’s helpful to learn from the masters.
In his book Setting the Table, Danny explains how the concepts of hospitality and service apply to every business.
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.
From worn-in trainers to leather loafers, there’s a constant reminder in every conference room to wear our customers’ shoes. We
But having a memorable company value around customers that’s discussed frequently still doesn’t magically enable the company to serve customers well.
The first step is ensuring proximity to customers.
But in many, maybe most, software organizations, developers never talk to customers at all. They operate in a kind of bubble, developing software that someone on the business side has specced out and handed to them.
A forum for customers is fine, but too often nobody is listening to what customers are saying. But not at Bunq: the company requires developers to participate on the forum, and a developer there soon spotted Leroy’s idea and saw other customers up-voting it.
As I’ve noted before, most things in code aren’t actually all that hard to build. Most of the work often goes into the overhead of planning. But by putting engineers directly into the flow of customer feedback, you achieve two things. First, you humanize your customers.
Second, you let the developers make instinctive decisions about work-versus-reward trade-offs.
More important than having access to the raw customer idea stream, developers are well served by being in the flow of customer problems. When developers are kept close to customer problems, they can help vet the problems with an instinctual understanding of the problem and its possible solutions.
Engineers on his team are required to speak to at least one customer a quarter. Getting that done isn’t as easy as you’d think.
Developers don’t even have to come back with an idea for a new feature. “Sometimes the outcome is just that you come back to your desk feeling good. We’re not always trying to get something out of it. It’s just about feeling that emotional connection,” Ben says. “Get them out of the basement, right? They’re not troglodytes. Get them talking to people.”
At Twilio, I often say “our strategy is simple: build things our customers want for which they’ll pay us.”
Another thing to ask your developers: during product reviews, start the conversation with the customer problem. Don’t jump right into talk of strategy or features, but start with why the customer will care. Ask your leaders about which customers demonstrated the problem, and how they validated that the customer problem represents a broad market need. The answer doesn’t matter as much as the process does. Does the team have the right mechanisms in place to truly understand customers?
Chapter 10 Demystifying Agile
.h2
The core problem was that most software projects started with meticulous requirements gathering, and then planning out months or years of work, with hard dependencies between myriad teams to deliver a final, working product in the end.
The main problem was that in software, requirements were often not truly knowable at the get-go of a project, so all of the meticulously crafted dependencies and assumptions were often wrong, and the business needs would change faster than the software project could keep up.
The first concept is anticipating that there will be changes to the requirements, so instead of being surprised and upset by changes, creating a system that expects them. Agile does this in a few ways. First is by limiting work in progress. If you have one hundred things that are 10 percent done, the chance that changes will come along and interrupt at least one of those workstreams is great.
Agile limits work in progress by breaking work into short sprints, often only two weeks long, with the goal of delivering a working product at the end of each cycle.
The second concept is chunking up work as you go, into units that are manageable, predictable, and implementable.
If you need to run a mile, make sure each stride is well executed. It’s important to deliver working software with every sprint. That’s why many teams implement “sprint demos” on the last day of the sprint to show off the results of their work, creating cultural reinforcement of this key tenet of Agile.
Agile teams typically chunk up complex tasks by creating a backlog of work to be done. While the engineers implement the current sprint’s backlog of tasks, the product manager’s job is to get the next sprint’s backlog ready by resolving ambiguities and removing uncertainties as best as possible.
The way I think about it, 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.
If you’re upset that you can’t throw more bodies at the problem, it’s understandable. Budget is what we have to work with as executives. But in the short term, don’t aim your frustrations toward the team. That will only demoralize an already (probably) exhausted team, and it’s pointless. It’s like getting mad at gravity. Sure, if your parachute fails, curse gravity all you want, but it won’t help.
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.
It’s no surprise then that daily stand-ups can cut into flow. Which balance of flow-state time and meeting time works best for your organization? Why don’t you . . . Ask Your Developer?
Many developers want the freedom to understand customers, think deeply about the business, and use their whole brain. But an overly rigid Agile system can encourage developers to believe it’s not their job to understand customers or the business—so they constrain themselves by playing the role the system expects.
Across Twilio, we are not strict adherents to a particular Agile methodology.
But we do strictly enforce a few key ideas. The most religiously adhered-to rule is that 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 their ideas of what’s needed differ from what leadership considers most important, it’s not a blind top-down mandate to take leadership’s word, but it sparks a very...
This highlight has been truncated due to consecutive passage length restrictions.
Once the structure is in place, we usually let teams choose their working style. Most, if not all, teams operate on two-week sprints, with the goal of having demonstrable progress at the end of each sprint. Some teams are better at this than others. All seek to limit work in progress, which is the goal of both Scrum and Kanban, with varying levels of success.
Most teams attempt to assign a measure of productivity, using story points, to their work so they can track whether they are getting more productive over time.
Chapter 11 Invest in Infrastructure
.h2
These two ideas are in complete opposition to each other. Executives say they want innovation, but then unwittingly punish people for its natural consequences.
Ever wonder why engineers flock to companies like Google? Sure, the pay is good. But the support infrastructure is world-class. It’s one thing to coddle developers with free lunch and tricycles, but Google really coddles developers with great infrastructure on which to build.
