More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
February 12 - February 24, 2021
I’ve seen executives at great companies unintentionally sabotage their own digital success by doing (and not doing) things that disempower talent and kill innovation.
even with CEO support and a hungry team, it still takes a lot of work to set up those teams for success. It starts with having the right players on the field and then empowering them to make progress.
He was referring to a legendary (though perhaps apocryphal) story in which Ernest Hemingway bet someone ten dollars he could write a whole novel in just six words and won the bet with this: “For sale: Baby shoes. Never worn.”
Perhaps by their own choosing, or perhaps because of the engineering and management processes the company has constructed, developers just write the code they’re asked to write. The cold, dispassionate process of software development common in some companies is a tragedy both for the business and the developers. I see it as a failure to fully realize the potential of this amazing talent.
I think there’s often a false divide between businesspeople and software developers. At many companies, there’s a disconnect between the way businesspeople think, and what they want to accomplish, and what the software developers in those companies think they’re supposed to do.
It’s no longer a question of Build vs. Buy. Rather, it’s the existential question of Build vs. Die. It’s natural selection driven by customers, who pick the companies that serve them better in this digital era.
To truly thrive in the digital era—either as a disruptor or those fending off the disruptors—you need to think like a Software Person. Now, a Software Person is not necessarily a developer—it’s anybody who, when faced with a problem, asks the question: “How can software solve this problem?” That’s because being a Software Person is a mindset, not a skill set.
Every kind of company can become a software company—all you have to do is internalize the value of rapid iteration. You don’t need to be Elon Musk or Jack Dorsey; you just need to believe in the power of iteration, and Darwin will be on your side. But of course, to iterate, you first need to build. You can’t iterate on something you’ve bought off the shelf. That’s why it’s Build vs. Die.
The problem is that, by definition, a one-size-fits-all piece of software doesn’t suit anyone very well. And if every company buys the same software, no company can differentiate itself. They are all just the same as their competitors, at least as seen through the digital lens—which is increasingly the only lens that matters.
That’s another reason why big corporations are so reluctant to change and why they continue to lag behind startups—because the top brass has a “shame and blame” culture, and the people who run the tech group don’t want to take risks. The safest bet has always been to go with some big commercial vendor. Sure, the software might not be great. But when things go wrong, the vendor takes the blame, not you.
This problem got solved when the second era of software—Software as a Service (SaaS)—began, about twenty years ago. The company that pioneered this model is Salesforce. Its founder and CEO, Marc Benioff, interned as an assembly language programmer at Apple (translation: he was a hard-core coder) and after university joined Oracle, where he quickly became a legendary salesman.
My rule of thumb is that for anything that gives you differentiation with customers, you should build. Software that faces your customers, you should build. Anything where your customers will be saying, why doesn’t it do X, and your answer is, well, the thing we bought doesn’t do X. That’s a problem.
But let me repeat the rule of thumb again: anything that is customer-facing, you should build.
Because you can’t buy differentiation. You can only build it.
Take Twilio, for example—we have (as of the time of writing) more than one thousand people on our R&D team improving our communications platform every day. Our customers get the benefit of that investment as our app gets better every day.
Deciding which areas are core competencies—an oft-discussed question of corporate leaders—now extends down to the microservice level.
When I arrived at the University of Michigan in 1995,
We decided to call our venture Notes4Free.com, registered the domain name, and adopted an unofficial tagline: “We don’t condone skipping class. We just make it easier.” As you might imagine, the service was very popular. What student wouldn’t want free lecture notes you could get without even leaving your dorm room? Soon we expanded to a second campus—Michigan State—and then to the entire Big 10.
fall of 1998 brought the dot-com boom. The opportunity to participate was too big to pass up. My cofounders and I dropped out of school to build the company full-time. We raised a $1 million seed investment round from friends and family and expanded our office three times in six months,
We hired a “professional” executive team, who, in retrospect, were primarily interested in selling the company. Which we did. In January 2000, we sold Veristy.com in an all-stock transaction to another company courting college students—CollegeClub.com—which had just filed to go public. CollegeClub withdrew its IPO filing to complete the acquisition of Versity, and by the time they refiled—in April 2000—the IPO window had closed, the party was ending, and they were burning about $30 million per month. Instead of an infusion of IPO cash, the company ran face-first into the wall, declaring
...more
In retrospect, I’m sure that company was an absolute shit show. We were twenty-one years old, running around with no business model and millions of investor dollars.
If I wanted to create a meaningful company one day, I needed to learn how big companies operated. What worked well? What should I emulate with my next startup? What stopped working when companies got big? What pitfalls should I avoid? I needed to learn how business worked, how to manage, lead, and scale a fast-growing organization. At startups, you just ran as fast as you could, but how did real companies work? I wanted to find out. It also wouldn’t hurt to get a paycheck and recharge the coffers. In the fall of 2004, I took an offer from Amazon Web Services (AWS) and moved to Seattle.
When I arrived, there were about thirty people on AWS, where I was a product manager, working from the sixth floor of the Pacific Medical Center—or PacMed for short—the old art deco hospital that had been converted into Amazon’s headquarters. Jeff Bezos worked on the seventh, and if you were near him, it meant he cared about what you were working on. AWS was his pet project, thus our presence on the sixth floor.
The whole company was divided into small, two-pizza teams, each operating like a tiny startup. There was urgency. There was energy. What we were doing mattered. We were inventing the future—that’s the feeling you want your technical talent to feel.
This is how innovation works: experimentation is the prerequisite to innovation. The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works. So I kept looking for ideas.
First, we needed a name. I’m a big believer in having a unique proper noun for the company that can be owned completely. We started making sounds with our mouths—literally just expressing syllables that sounded remotely like telephone. “Teliph.” “Telefoo.” “Telapia.” Nope, that’s a fish. We kept making sounds. It must have been hilarious to listen to, but we didn’t care. After about twenty minutes, I said: “Twili. Tweli. Twilio.” The last one had a ring to it. Amazingly, Twilio.com was available for seven dollars, so I bought it. That was that. We’d named our company.
On top of that, the carriers are notoriously slow moving and difficult to work with. But as we dug in and realized how hard it truly was, that encouraged us even more. The worse the legacy world was to deal with, the bigger our opportunity was to simplify it and improve the customer experience.
Our software would abstract one hundred years of complexity that the industry had accumulated and present it as a simple API for developers. An API lets web developers do things over the telecom system without having to learn how to speak telecom. They just write some code in common languages they already know, like Ruby, Python, JavaScript, or Java, and use it to build apps that can make and receive phone calls.
When we showed prototypes to venture capitalists, however, they weren’t impressed. We got turned down twenty times. Money was so tight that in 2008, when Erica and I got married, we sold our wedding presents and put the money in the bank. Investors might not have believed in Twilio, but I did, and so did my cofounders. We were not going to give up. We were convinced that we had come up with something that customers would love, in a large market.
That demand has been our tailwind as we’ve continually expanded our service—initially just voice calling in the United States—to now more than dozens of products, all of which span the globe. Twelve years in, I’m incredibly proud of what we, and our customers, have built.
rapid iteration, experimentation, and close contact with customers are the prerequisites to innovation. Second, having seen big companies like Amazon as well as tiny startups like StubHub, I’ve learned that the key ingredient to unlocking innovation is cultural more than anything else, and that culture starts at the top. And third, and most important, I’ve realized that the relationship between developers and businesspeople is not well understood, but is critical to solving business problems with technology.
the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions.
Incredibly important
She’s learning new skills, like developing products, managing employees, and running a business. “What I like about startups is that it’s hard. A lot of normal software jobs are too easy. I don’t feel challenged. The reason people get into engineering is because it’s challenging, and it’s fun. I like having different things to do every day. It’s the challenge of not knowing how to do something, then learning it, and then mastering it.” That notion of constant learning, and expanding horizons, is something I hear consistently from great developers.
Chad says the reason he’s bounced through so many jobs is that until he landed at Apple, it was very hard for him “to find a company that allows this sort of autonomy or freedom so I can give my full self.”
For developers like these, handing them a “Product Requirements Document” detailing exactly what to build wastes most of their potential. That’s why my biggest piece of advice to those executives who travel the world to visit Silicon Valley is this: Share problems, not solutions with your developers.
“When I was in engineering school,” he told me, “one of my engineering professors used to say, ‘Scientists find problems, and engineers fix problems.’ That’s always been my outlook on software engineers. They’re problem solvers. They sit down and look at a problem and then find the most efficient way to solve it.”
Think about it. Do you voluntarily do your day job on the weekends, for free, out of passion? Do most accountants do hobby accounting on the weekends? Maybe there are some who do, but probably not many. Do dentists play with some creative dentistry ideas on the side? (God I hope not!) For developers, code is more than a job—it’s a creative outlet. When developers can’t express that creativity at work, they find other areas to do it. Many have outside projects and even startups on the side.
“Anything creative, you have to let people do it. That’s why you hire them. If you want to direct every little thing, you end up hiring people who don’t use their brains.
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.
“Every time I hear phrases like ‘This should just be a quick thing,’ or ‘You can do this in a day,’ it drives me crazy,” Chad says. “Because unless you understand how things are put together, unless you know how the infrastructure is built, you have no idea how long it will take. I think that’s what sometimes causes a struggle between managers and engineering.”
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. The more layers there are between people who use a product and people who create the product, the worse things get.
But of course, nobody knows ahead of time, so you have to be willing to plant a lot of seeds and watch them grow.” When they start to sprout, don’t step on them, citing how small they are. Rather, water them and give them sunlight. Or, in corporate-speak, invest more. Like trees, every big idea starts small.
That enthusiasm is cool, and great things often start there, but you shouldn’t proceed before developing the idea into a business hypothesis. Without that, you won’t know what your experiment is measuring. Success or failure will be ambiguous, and you’re just left with “Is it moving the needle yet?” To which the answer will almost always be no.
At Twilio, one of our core values is “Write it down,” and experiments are a great place to exercise such a practice. It’s not uncommon for people to forget the original hypothesis, so keeping it in writing, as well as the results, keeps everybody on track.
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.
In reality, it’s quite easy to run experiments without hurting your customers. However, one mistake to avoid is treating an experiment like it’s not an experiment. If you aren’t sure the world needs your idea, do the work to test it experimentally, as I’ve advocated in this chapter. But if you jump straight to a huge investment and a big splashy launch, that’s when you’re more likely to hurt your reputation with customers. If, with big fanfare, you launch a big dud—that’s a brand and PR issue.
There’s a shortage of developers in the world. In 2019, there were four times as many open software jobs as there were new computer science graduates.
Here’s another issue you might think is silly that actually rankles developers in a big way: clothing. Dress codes. Making people wear “business attire,” or whatever. Like the TV sign, it’s small but sends a big (and wrong) message, which is: “We don’t even trust you to pick out your own pants.”
“I’m not interested in ping-pong, beer, or whatever other gimmick is used to attract new grads. The fact that I don’t like those things shouldn’t mean I’m not a ‘culture fit.’ I don’t want to work in tech to fool around, I want to create amazing things and learn from other smart people. That is the culture fit you should be looking for,” Kaya wrote (italics mine).
Management By Objectives (MBO) is another method of assigning bonuses, tied to goals that are set at an individual or team level for the employee. On paper this sounds better because you articulate what the team needs to do, and then the team members or individual get paid more if they do it. Yet I’ve seen companies burn so many calories trying to figure out what these MBOs should be! Sometimes it takes so long to set the MBOs that by the time they’re set, they’re irrelevant or wrong. Then employees are focused on achieving the goals versus doing what’s right.
