More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
January 13 - January 22, 2021
He didn’t know anything about software, a fact that ended up being a boon because when he asked me to solve a problem, I became more engaged.
Chapter 4 Code Is Creative
.h2
The truth is that most software is pretty simple. It’s what developers call CRUD applications: Create, Read, Update, Delete. Most apps online are forms that let the user input data, modify data, report out data, or delete data. Nearly every website or mobile app you’ve ever used is 95 percent CRUD operations. This isn’t rocket science. What that means is that the real difference in how long it takes to solve a problem, and how well it’s solved, comes from the developer understanding the problem, as Ozone did. When developers actually care about their work, intrinsic motivation kicks in and
...more
Great product managers are not a layer between customer needs and developers. In fact, they actually remove layers, eliminate preconceived solutions and erroneous presumptions, and streamline communications. Great product managers don’t abstract the developer from the customer needs; instead, they facilitate understanding of customer problems.
When you see a developer, ask what they’re working on, and what customer problem it’s going to solve. Do they know? Ask when they last interacted with a customer, and how it made them feel. Did it motivate them? Ask what they learned that surprised them. Based on their answers, you’ll get a sense for whether developers are truly brought into customer problems, or whether they’re just asked to implement solutions.
Chapter 5 Experimentation Is The Prerequisite to Innovation
.h2
Innovation is kind of like that—experiments are buying lottery tickets for the chance of a breakthrough innovation.
However, I don’t like the lottery ticket analogy, because no amount of skill can increase your chances of winning. With experimentation and innovation, you can get better and better at it with practice.
First, vet the idea. This doesn’t need to be exhaustive; there should be low activation energy for starting a new experiment. What you really want to know are just two things: What assumptions about customers, the problem, or the market are you making, and how will your experiment prove or disprove those assumptions? If you are wildly successful, will it be a big outcome? The point is to grow a big tree, so ask whether the seed you’re planting has that chance if it’s successful.
Next, agree upon metrics of success. Eric Ries is great at this, so read his books The Lean Startup and The Startup Way to learn his in-depth methods for what he calls “Innovation Accounting.”
Your experiment might aim to (a) figure out if one customer will indeed pay you that much to solve the problem; and (b) validate that the problem is applicable to a sufficient number of customers that you could reasonably find one thousand in the next five years to bite.
If you can’t even get one to bite, then that’s a problem. Or if you do, but they’ll only pay $1,000 per year instead of $500,000, that’s a problem. Or if they do pay the right amount, but you realize there are only ten companies in the world that have this need, then that’s a problem.
Having a hypothesis, and a set of assumptions to prove or disprove, is great—but you need it in writing so you can track progress. At Twilio, one of our core values is “Write it down,” and experiments are a great place to exercise such a practice.
Finally, let’s look at the trickiest situation, the fuzzy middle, where the hypothesis remains in an unproven state, neither true nor false, and your metrics are all over the place. Those are the hardest calls. This is the one actual kind of failure story for a team running an experiment. If your goal is to prove or disprove a hypothesis, and you can’t do either given a reasonable amount of time, then the experiment may actually be failing. This is why clarity of metrics is so important at the onset of an experiment.
Perhaps the problem is your team. It’s certainly possible, as in any endeavor, for a team to be poorly executing. In an experiment, the failure mode is extended periods of time with no answer to the question of whether the hypothesis is true. During the rapid iteration phase of an experiment, it’s useful to check in with the team on a weekly, or perhaps biweekly, basis to help guide the experiment based on the rapid pace of learning.
To engineers, facts matter. I just think of it this way: engineers hate bullshit. So if you need someone who will tell you the truth, even if it’s ugly—go find a frontline engineer.
Chapter 6 Recruiting and Hiring Developers
.h2
In his book Drive: The Surprising Truth About What Motivates Us, Daniel Pink argues that compensation isn’t necessarily what motivates people. Or it does, but only up to a point. Companies need only compensate employees to the point where they feel they are paid fairly. (I’ll talk more about that toward the end of this chapter.) Once you meet the bar of fairness, employees focus on the real reasons for work: autonomy, mastery, and purpose. I believe this is especially true for developers.
Part III Making Your Developers Successful
.h1
Chapter 7 Creating an Open, Learning Environment
.h2
The goal, always, is to find the truth. That must be our north star, the destination toward which we navigate.
Well, business decisions shouldn’t be about anybody’s opinion. People have hunches and instincts. Just theories, really. But those theories need to be tested. And that’s where you need an openness to learning—and learning quickly.
An open environment is one where you give people autonomy by sharing problems, but it’s not just a matter of throwing out big problems and letting folks sink or swim. As a leader, you’re still on the hook for results, so sinking doesn’t sound so awesome. Rather, an open environment provides (a) guardrails and (b) support. Instead of “sink or swim,” we give people swim lessons—and even let them wear floaties if they need them.
Chee Chew, our chief product officer at Twilio, has introduced a lot of smart ideas since he joined the company in 2019. One of his most important innovations is a concept he calls Open Project Reviews (OPRs). It means that every time Chee meets with a team to discuss a project, anyone is welcome to observe. This might be a first meeting where an engineer pitches a new product idea, or a meeting where a team of developers are explaining what progress they’ve made on a project that has been up and running for years. The meetings are published on a public calendar to which anyone can subscribe.
...more
Another benefit is that OPRs hold people accountable. Decisions are made out in the open, in front of everyone—not in secret meetings in closed rooms, where others only learn about things secondhand, through the grapevine, and messages can get muddled. Everyone in the company knows exactly what the people in that meeting are expected to deliver. There’s no going back and changing things later.
This was a weekly meeting where the general managers (GMs) of all the services assembled. In my day there were about ten people in the meeting; today there are probably hundreds. Andy looks through the metrics of each
When he finds something that’s off, for example something that’s trending in the wrong direction, he stops and asks the leader why their metrics are off and what they’re doing to fix it.
The hard part is to balance that open environment for feedback without creating an environment of fear. That’s where the “open” part comes in. Leaders should expect the best from their teams, and when a GM is unprepared, it should be apparent to that person, but also to the room, that this is not acceptable.
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.
In 2010, a fledgling ten-person startup called Uber (actually UberCab at the time) became a Twilio customer. Over the years, they experienced meteoric growth and by the time we went public in 2016 they represented more than 10 percent of our revenue and were a prominent part of our IPO road show.
Chapter 8 Small Teams and Single-Threaded Leaders
.h2
Shortly after he rejoined Amazon in 2012, I called him up with a simple question: How would you compare and contrast those three companies—Amazon at 100 people, 5,000 people, and now 75,000 people? He thought for a few moments, and then said this: “You know, it’s the same company. The same sense of urgency. The same bounce in people’s step. The same intelligence. It’s awesome.” In 1998, there was a single floor full of employees in its Seattle office, full of startup hustle and drive. In 2012, it was the same picture, only there were nearly a thousand such floors full of Amazon startups
...more
At the heart of Amazon’s scale are small teams with empowered, mission-driven leaders. In essence, a collection of startups.
And as the bagel orders grew, I found it was getting harder and harder to hold the whole business in our heads. (It was also harder and harder to carry the bagels.)
For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. I typically start by defining the customer they’re serving.
Once you have a customer defined, then you define a mission.
For an infrastructure team, that might be “to maximize the productivity of our engineers to build, test, release and operate high-quality Internet-scale products.”
Last, to measure progress against this mission, and to know if customers are being served by the team’s existence, they need measures of success.
these should be relatively long-lived measurements that tell the story of progress toward the stated mission, versus objectives that change quarterly. For example, when Twilio Infrastructure got started, our build system, which packages our code for deployment to servers, was horribly broken. It could take half a day to build and deploy our software, and half of the time the build would fail for unknown reasons. It was killing developer productivity. So the Infrastructure team took on a measure of “time from code check-in to deployment.”
The other benefit of a small, driven team: nobody can hide.
The big question is typically how to divide the teams. How you do it is situationally dependent. Sometimes it’s by function of the product, sometimes it’s by layers of functionality, sometimes it’s by customer segment—but the most important thing is that you keep the customer, mission, metrics, and codebase together with that team. That last bit—the codebase—is the hard part because you have to plan ahead. Likely the system was built as one large codebase, and in order to split your teams, you must refactor the system into two codebases that two teams can independently own. This takes time;
...more
Lots of companies talk about empowerment but are ultimately too risk-averse to give their leaders enough freedom. Executives are too worried about their own success to actually let the people who report to them have any real agency.
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.
It’s a sanity check on the decisions, but for hard decisions, it’s usually easier to ask your boss to make the call. But doing so is escaping accountability, which isn’t good for building a culture of empowered leaders. As a leader, I tend to ask more questions than answer them. My goal is to make the single-threaded leaders accountable, but help them answer their own questions. I’m not perfect, and too often I fall for the trap of making the call when asked, but my goal is to help them clarify their own decision-making instead.
So what’s the solution? People feel empowered and “in the know” as a function of how close they are to the decision maker, which breaks down like this: If you’re the decision maker, you have complete autonomy. If your manager has the decision, you’re likely to understand their process by which the decision is made, you’re in conversations that inform the decision, and you’re likely to go along with the decision. If somebody far away, whom you interact with rarely or don’t even know, makes a decision that impacts you, you take on a victim mindset. These are things being done to you, not with
...more
One problem you soon encounter scaling up a bunch of small, autonomous teams is how they coordinate their work. The more teams you have, and the more autonomous they are, the less they are likely to collaborate, which many leaders will bemoan. In fact, when things in a company aren’t humming along, it’s common for leaders to exclaim “We need better collaboration” as the answer. And while that sounds nice, it’s not realistic to say that people just need to manage their thousands of relationships with other people and other teams better. The whole system, and agility, would collapse under the
...more
it’s important to formalize the relationships between teams as “service contracts.”
This is really just allowing every team to think about their output as a product, designed to serve customers in the same way we serve people outside of the company.
I believe the goal isn’t better collaboration; it’s actually less collaboration. Great companies don’t say: “I need better customer support.” They say: “We should reduce the need for customers to contact customer support.”
Remember Patio11, whom you met in Chapter 4? He has a great analogy for what building a successful small team is like: building a single brain made up of all the necessary functions. Creating teams this way helps avert what he thinks is a major issue at many companies, even though it’s standard practice: siloing developers away from the business processes.
