More on this book
Community
Kindle Notes & Highlights
by
Jeff Lawson
Read between
March 8 - March 16, 2021
Ask Your Developer is an essential resource for understanding the connection between software, the people who build it, and the value they offer in building and transforming the organizations we need in the age of digital disruption.
Building software is incredibly hard, and building a culture of digital innovation is even harder.
it’s always struck me that business folks and software developers often want the same things—to build awesome products that delight customers, are massively adopted, and make a lot of money. However, businesspeople and developers often speak different languages and have different working styles—and these differences can inhibit the business and the developers from effectively collaborating to achieve their goals.
“Our business is not what’s in the brown boxes,” he said. “It’s the software that sends the brown boxes on their way.” We monetized our software not by selling it directly, but by selling everything else—books, DVDs, and CDs. What’s more, the quality of our software would determine whether we succeeded: “Our ability to win,” Jeff said, “is based on our ability to arrange magnetic particles on hard drives better than our competition.”
Software has moved from being a cost center to the profit center. That’s how the ferocious and relentless Darwinian competition kicks in. Suddenly, software isn’t a liability to be outsourced. It is the source of competitive advantage.
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. Software People are the ones who see the world through the lens of software. They are endlessly optimistic, because they believe that any business problem can be solved once it’s brought into the domain of software.
The iPhone keyboard is software. It disappears when you don’t need it, which is most of the time. It can change to an emoji keyboard when needed, or another language if you’re multilingual, which means Apple can ship one SKU worldwide. The language you need is just software, not something that has to be fixed at the factory.
even if your business isn’t hardware, the lessons are the same. How much of your industry is digital versus analog. What would happen if you could iterate on your key experiences and workflows on a weekly basis? That’s the software mindset at work, beginning by digitizing your physical reality, and then applying the software mindset to problem-solving.
beginning with a “request for proposal,” or RFP. You will spend months reviewing proposals and listening to sales pitches from software vendors who hope to win your business. You’ll run “bake-offs” to compare the products. Meetings are held. Opinions are solicited. Presentations are given. Sweeteners are added: Buy our HR software, and we’ll throw in our CRM package at a discounted rate. Then you spend months negotiating the contracts, and finally the winning software company sends in a squad of consultants who spend months, sometimes even years, installing the software. By the time it’s up
...more
now every company is becoming a software company, and most companies can’t build everything from scratch. They need a supply chain—just like Ford and Toyota—that divides the industry into areas of expertise and allows each company in the ecosystem to specialize on its core competency.
the most interesting implication of AWS was that it changed not just the way computing power was bought, but who was buying it. In the traditional world, IT decisions were made by people near the top of the organization—the CIO or the CFO. That’s because these were high-stakes decisions, with years of work and millions of dollars being decided. At AWS, however, a lot of customers were just ordinary developers. Individual engineers or department managers could spin up a server and storage capacity at AWS just by entering a credit card number.
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.
As a public company CEO, and a developer, my perspective is different than most executives as well as most developers. I’ve seen the challenges and the successes of collaboration between managers and developers from both sides.
I learned to dig in and monkey around. I learned that even if you thoroughly messed it up, you could always fix it. And that, in many ways, is the essence of building.
The superpower of software to me was how quickly you could take an idea and get it in front of customers. Once customers could play with your idea, they’d give you feedback, and tell you what was good and what was bad. That would inform the next thing you built, and so forth. You could release a new version every day if you wanted to. That iterative spirit is what makes software so powerful.
Telecom is a weird, complicated world, full of arcane technology and terminology with loads of cruft and crust that has built up over the decades, plus a litany of rules and regulations. 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.
I’ve realized that the relationship between developers and businesspeople is not well understood, but is critical to solving business problems with technology.
we could work together on the problems of our business even though he was a complete technophobe and I was a hard-core, true-believer, tech-loving computer science major. That working style exposes a truth that seems simple but is actually rather profound and surprisingly rare: the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions.
If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. —Antoine de Saint-Exupéry
There were thousands of systems, and billions of lines of code, a hodgepodge of hairballs and patches and workarounds, much of it so old that nobody remembered where it came from or who created it. The government was facing the same challenge that companies are facing—that more and more of what the government does depends on software, and that, thanks to companies like Spotify, Uber, and Facebook, citizens have high standards when it comes to what their user experience should be like across the board.
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.
A university in Japan had a manual billing system that it wanted to automate. In the manual system, a worker sat at a desk with a pile of invoices on the left side of the desk and a pile of bank statements on the right. The worker matched invoices with statements, stamping invoices that had been paid. Naturally, they wanted to do this with software. So a business owner at the university passed the request to a buyer at the university who dealt with firm’s sales reps, who passed the spec to a project manager, who passed it to another product manager—and finally to the engineers. The solution
...more
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.
At Twilio we’re always trying to run as many experiments as possible. We ship new versions of our product over 120,000 times per year—more than 300 times per day. With every one, we’re incrementally adding new features and functionality, fixing bugs, increasing performance, and running experiments.
If you hypothesize the world needs some technology product, you can test that hypothesis easily by building a quick website and buying ads on Google—seeing if you can get people to bite. You don’t have to actually build the product, just the marketing website to see if the value proposition resonates. Given the efficiency of online advertising, you can target your hypothesized buyers pretty well and test whether they hit the “buy button” on the website or not. Here’s where you might let people down: the buy button doesn’t actually work if you haven’t built the product. Usually the button leads
...more
It doesn’t make sense to hire smart people and tell them what to do. We hire smart people so they can tell us what to do. —Steve Jobs
Developers are just people, replete with ambitions to learn and grow, motivations to do their best work, and a full range of skills they want to exercise. In companies where this is understood and respected, and where developers are given a seat at the table, they’ll be engaged, active company builders with you.
We pay higher than most similar companies in base pay, which is guaranteed and not subject to some management fad or poorly set goals. And we tend to give a little more stock equity as well, to compensate employees for the lack of bonus—with the side benefit of focusing employees on long-term versus short-term objectives. My belief has always been to pay people well, so they feel it’s fair, but don’t cloud things by believing that compensation is the great motivator, especially for creative roles.
As technical leaders, the more we progress in our careers we tend to exchange up-to-date technical competency for managerial competency. Two valuable but different knowledge sets that we bring to the table. Whose opinion is right—the one with more experience, or the one with more knowledge of the technologies?
Constructive criticism isn’t about tearing people down; it’s about helping them get better. It’s actually a form of respect. And it’s how people learn. Making meetings open to the whole company means that sometimes an engineer gets skewered in front of an audience. That might make the experience even more unpleasant, but on the other hand, knowing that a lot of people might see your performance does create an added incentive to get your act together before you show up. It also sends a message to all of the “read only” people who are watching about what they should expect when it’s their turn
...more
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.
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 you. You start to believe you’re a passive part of the process, as opposed to an empowered and trusted actor.
You might ask whether decisions are informed more by customer need than by the org chart. To understand if the team feels accountable for progress, ask what metrics they’re measured by, and whether they feel they can reasonably control them. Ask how many people outside of their team decide what they can or can’t do.
good service is necessary, but insufficient to be a great customer-centric organization: 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.
The Product Owner, as you might expect, is typically the product manager. Their job is not to shield the Development Team from customers, but rather to facilitate an understanding of the customer’s needs to the rest of the team. They should act as a bridge, and enable conversations as needed between customers and the rest of the team. But a good Product Owner is skilled at correctly abstracting the customer problem to be solved, to represent the broadest set of customers.
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.
Executives say they want innovation, but then unwittingly punish people for its natural consequences. And because human beings are good at pain avoidance, the desire to avoid punishment pretty quickly overrides the innovation directive. The result is an organization that moves slowly, is risk averse, and lacks accountability.
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. When your tools direct nearly all of your energy toward the task at hand—serving customers and being creative—it’s magical. The opposite is also true—when you’re fighting your tools, it’s a real morale hit.
This was the opposite of moving fast. Writing the code wasn’t the hard part. Wrangling our antiquated systems was. Talk about a self-inflicted wound. As a result, our best engineers started quitting, frustrated at the inability to do their jobs. At first it was a few, and before we knew it, nearly half of our engineers had quit. Half! It was an absolute disaster, and it almost tanked the company.
Instead of six months, can we deliver a new feature in six weeks? Six days? Six hours? Jason reckons the platform does 80 percent of the work that a developer previously had to do. Some processes that previously took weeks or even months now can be done “with a few clicks in a few minutes.” Today, Twilio releases new code to a production over 160,000 times per year—that’s nearly 550 times every single working day.
By allowing teams to duplicate work if they need to, you also let the teams show you, with their valuable time and skills, where you need to invest. It’s like that old story: An architect is asked to design a college campus. Upon presenting the final campus design, the regents point out that there are no walking paths. The architect’s reply? “We’ll let the students decide with their feet where the sidewalks should go. Within a year, it’ll be obvious.”
These quick rollouts also taught us a few things. First was how great things can happen when people stop worrying about making mistakes or not getting everything perfect the first time around. During the COVID-19 crisis, change was free. There were no alternatives, no office politics, and no fear of mistakes—because the alternatives were far worse.
