More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
February 12 - February 24, 2021
You don’t want employees focused on bonuses. You want them focused on customers.
At the start of every year we had the same big arguments about setting the goals. Are they too hard? Too easy? At the end of each year we argued about whether the goals had been set well at the beginning and whether the bonuses were merited or not. In some years, we blew away the goals and the board was concerned we’d sandbagged them. In other years, we missed the goals, and the team felt that the goals were unfair to begin with. In every case, we ended up paying out the money. That’s when I decided this wasn’t worth the effort.
Some of my quarterly business reviews have even been called “the Inquisition” in the past. But that’s not the goal, that’s a failing. It’s my job as a leader to build an environment where our leaders feel constant, gentle pressure to perform, and support for their continued, urgent exploration of their problem domain—but not an inquisition.
Consider asking your teams, maybe in your next big company survey, if they’re more motivated by chances of success, versus avoidance of failure. These are some questions that might help you understand if your culture is oriented toward learning and truth seeking.
Coordinating a 10-person team requires 45 relations between people, but coordinating a 100-person team results in nearly 5,000 relationships, and coordinating a 1,000-person company requires nearly 500,000 relationships to work.
At the beginning of Twilio, it was just Evan, John, and I—three developer-founders.
In one instance, I remember that a customer reported a bug on Twitter and I wrote the fix within five minutes—but actually held off deploying it for a day because I didn’t want us to look like such a small company.
We could imagine how our decisions would play out over time. Even though we each had our areas of expertise (Evan wrote a lot of the infrastructure, John wrote a lot of the core product services, I wrote a lot of the API, web, and billing layers), we all knew enough to act as one brain.
To this day every new Twilion, no matter their role, learns the basics of coding and builds an app on our platform. When they complete their app they earn a red Twilio track jacket—a true badge of honor!
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.
We call such leaders “single-threaded” because they wake up in the morning with only one thing on their mind—how their team can win. (Threads are units of execution in a computer program—a multi-threaded program is doing a lot at once, but a single-threaded program is focused on doing just one thing.)
The problem is that many times leaders step in on unimportant and inconsequential decisions. It’s called “bikeshedding.”
you’re not an expert in nuclear reactor design, you’re probably not going to probe deeply into the details, and you’re likely to accept the recommendations of the expert engineers. Yet if they were to ask you what color they should paint the bike shed outside the nuclear reactor, a large discussion would ensue, with each committee member attempting to add value and express their opinion. 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.
RAPID® was created by Bain as a tool to clarify decision accountability, assigning roles to the five key roles in any decision (Recommend, Agree, Perform, Input, Decide).
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.
Sadly, as executives and managers, our primary window into viscerally understanding how well we’re serving customers is the quantity and content of the many LinkedIn InMails, tweets, and emails we receive unprompted from customers.
At Twilio, I often say “our strategy is simple: build things our customers want for which they’ll pay us.” Obviously we have long-term plans for the business, but I don’t want teams to confuse our company’s goals for serving our customers.
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.
“mythical developer month”—which says that the more developers you throw at a project that’s late, the more you will only make it later. Why this counterintuitive outcome? Two things: First is the ramp-up time for new developers. But more important is the communication overhead between those developers thrown onto the project. All those new resources need to ask a lot of questions about how things work, and those questions interrupt and disrupt the currently productive developers.
Werner Vogels of Amazon notes that this approach—where you’re knowingly permissive of duplicated work—is often a nonstarter at traditional companies, which tend to feel it’s out of control or chaotic. “It’s so counterintuitive for them because they’re all about efficiency,” he explains. “They’re used to having top-down control, and in essence the hierarchy becomes more important than moving fast.”
Resist the urge to cut corners on platform investment—remember, money spent on platforms makes all of your developers more productive.
