Last year, when I was building Virtual Inspections, a product that lets city inspectors have virtual meetings with inspectors in the field using Twilio Video, I read Jeff Lawson's book Ask Your Developer.
Jeff is the CEO of Twilio, a company I love and admire. Their communication APIs have enabled so many developers to build amazing applications and businesses. So when I heard about this book, I immediately bought it and devoured it in a few days.
If you run a software company and manage developers, this is a book for you. Read it now. You will learn what developers value and crave for (no, it's not ping-pong tables or free food), how software-supply-chain and the API-economy works, how to turn software development from a cost-center to a profit-center, delight your customers, and finally make a lot of money in the process.
If you are a software developer, this book will teach you how not just to be a code monkey that takes in requirements and cranks out code, day in and day out. Instead of just taking orders from the top, you will learn to collaborate with business people to help them formulate the requirements and strategy for building awesome and useful software that delivers value to the users.
That's enough for the sales pitch for this book. Read it now. If you don't have time, here's a (not-so) brief summary and my notes from the book. Let me know what you think after reading it.
At many companies, there's often a false divide between business people and software developers. There's a disconnect between the way businesspeople think, what they want to accomplish, and what the software developers in those companies think they're supposed to do.
Ask Your Developer mindset helps business people better understand and collaborate with software developers to build incredible products that delight customers, are massively adopted, and make a lot of money.
It is about setting high expectations for developers—not how much code they can grind out, but how well they can use their ingenuity and creativity to solve the world's biggest problems. They can do this only if they're empowered and given a wide enough berth. The most important thing is to give developers problems to solve, not solutions to implement.
Companies that build industry-changing software products seem to do three things well:
- Understand why software developers matter more than ever.
- Understand developers and know how to motivate them.
- Invest in their developers' success.
From Cost Center to Strategic Centerpiece
To differentiate from your competitors, you need to focus on software as a source of competitive advantage. You can't just outsource or buy your way out. If all banks just bought the same bank software, they'd all be undifferentiated.
How Software People Think?
Not necessarily a programmer. A software person is anybody who, when faced with a problem, asks the question: "How can software solve this problem?"
It's a mindset, not a skill set.
Buying software no longer makes sense.
By definition, a one-size-fits-all piece of software doesn't suit anyone very well. With off-the-shelf software apps, you have to change your business to match the software—which is crazy! Instead, you should change the software to build the business your customers need.
The New Software Supply Chain
What matters is not how you use servers, but rather how you serve users.
Jeff Lawson, 2010
Industries that produce physical goods such as cars have mature supply chains. They don't create every piece of a car themselves. Each car contains parts provided by hundreds of major suppliers, allowing companies to specialize in parts of the process, making the entire industry more efficient and productive.
Every company that is going to survive and thrive in the digital economy needs to build software. Thus, your software supply chain matters.
Until recently, the software industry had no such thing.
Most software companies wrote all of their own software end-to-end. That approach worked when there were a few software companies, and it was a highly specialized field. But now that every company is becoming a software company, not everyone can and should build everything from scratch. They need a supply chain.
The software supply chain delivers reusable chunks of code that developers bring together to make finished applications. These are Application Programming Interfaces or APIs in short. Each supplier provides a piece of the puzzle. For example, Twilio provides communication, AWS or Azure provides the data center, Stripe or Paypal enables payments. Modern applications integrate dozens of these services to offer a unique value proposition for the customer.
A brief history of software
Computers have transformed from mainframes, then minicomputers, Unix workstations, and finally the PC. The computers kept getting smaller, but the software industry pretty much used the same business model.
Here is how that looks.
A company invests R&D money to create an application and then sells it to individual users or massive enterprises. You built software once and incurred practically no incremental cost for each unit sold.
Though this is an excellent business for the company, it is a huge pain for the customers. Each company needs to have its own IT department, which would rack and stack servers, and install and maintain this infrastructure. Many of these large installations are prone to failure and never completed successfully. These projects take so long to implement that multiple generations of company leaders would often come and go before completion.
This problem got solved when the second era of software—Software as a Service (SaaS)—began about twenty years ago. With SaaS, line-of-business owners who needed a new software program didn't need to send a request to the IT department and then get in line and wait for them to undertake a huge multimillion-dollar, multiyear initiative. They could just open their browser and subscribe to a SaaS product.
Another change involved the business model. Instead of paying to license a program based on how many servers you deployed—including a big initial payment upfront and then paying annual maintenance fees—you just subscribed. When you stopped needing the software, you ended your subscription, just like a magazine subscription.
The platform business model, where companies like AWS or Twilio provide the infrastructure and platform upon which software developers build their applications, represents the next big thing in software.
The API economy
APIs are well-defined interfaces that enable code to talk to other bits of code. Once a team builds and exposes an API to others, they must teach other teams to use it via accurate and up-to-date documentation.
For an API to work, you need to document it clearly. One team could find another team's API documentation and start using their services, often without even needing to talk. This enables the teams to work together effectively, solving the coordination problem.
Build AND Buy
The only things companies should build themselves are the things that are core to their business and anything that gives you differentiation with customers. Because you can't buy differentiation, you can only build it.
Your company's "value add" might be how you integrate the pieces and how well you develop the customer-facing software that sits on top of microservices. For example, iPhone contains many commodity pieces that Apple didn't build. However, the design, software, building a brand, and telling a story, are all unique to Apple. That's where they decided to differentiate.
Understand and Motivate your developers
As a business leader, you need to understand two things:
- What drives developers to do their best work.
- What you do as a leader, that either motivates or accidentally demotivates them.
The key to getting business people and developers to work well together is for the business people to share problems, not solutions.
Writing code is creative. Writing software is more similar to making music or writing a book than doing math or science.
Yet most companies don't understand this; and don't create an environment where developers can exercise this creative muscle—and everybody loses. Developers don't do their best work, and they dream of quitting to start their own company. Companies lose because some of their best talent goes underutilized. Customers lose because the products are the sad results of a dispassionate software factory.
To solve this puzzle, companies must first recognize that code is creative, that many developers are creative problem solvers—and should be treated as such.
It's not about ping pong.
Too often, executives take the wrong lessons from Silicon Valley. It's easy to latch on to the superficial stuff that is evident when you walk around tech offices, like free food or letting people wear T-shirts and hoodies and bring dogs to the office.
After visiting enough Silicon Valley offices, it would be easy to assume that if you litter your office with enough Ping-Pong tables and colorful tricycles, great software will somehow emerge. Sure, you should let developers wear T-shirts and hoodies if they want to, but that's not the point.
The thing that matters most is that developers are given responsibility and freedom. Not just freedom in working hours or what to wear, but freedom in terms of creativity.
Enable the developer to deeply understand what the user needs and then let them meet it. This is what sharing problems is all about.
When developers actually care about their work, intrinsic motivation kicks in and unlocks new and even more creative ideas.
When developers are merely reading a specification document, they become isolated from the people who will use the software. The code becomes clunky and error-prone, because the developer didn't know how people would use it. Not only that, but the act of writing the code takes forever because the developer feels no passion and has no intuition for how to get it done.
Why do Software Projects run late?
If you've ever worked with developers or had teams build software for your business, there's often a struggle to get things built quickly. It always seems to take longer than the company wants.
This is the natural outcome of a flawed process in which managers tell developers what solutions to build rather than including them earlier in the process when they are defining the problem that needs to be solved.
The managers are getting pressure from executives on the business or financial side of the company. So they come up with an idea and commit to a deadline, but they’re beholden to engineering to make that happen. And that can be a difficult feeling as an engineering team when somebody just comes by and says, ‘Do this, quick, by this deadline,’ and then runs away.
Including developers earlier in the discussion isn't just about being nice and not hurting their feelings. It also creates real advantages. How can managers commit to deadlines when they don't understand the actual work that needs to be done? What if the specified solution can't be built in the time frame given? Either the features will get cut, work will be hastily implemented, or the developers will burn out and quit.
None of which are good outcomes.
Managers have the power to connect developers with customer needs and help them facilitate a solution. 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. It becomes like a giant game of telephone, where the message gets relayed through so many people that developers have little way of understanding the people who will use the software they're building.
Hiring Developers
You just have to treat software developers like people. Developers are just people, packed with ambitions to learn and grow, motivations to do their best work, and a full range of skills they want to exercise.
Autonomy, Mastery, and Purpose
Autonomy means working independently, being trusted to make decisions, and not being told what to do. Mastery represents the ability to get better at your craft over time. Purpose involves the feeling that the work you do matters.
Developers want their work to matter. They want to develop systems that generate revenue, or save money for the company, or enable the company to deliver new experiences that delight customers. They want to invent new lines of business. Show them that in your organization, developers are considered key to the company’s future, solving problems that have impact on millions of people.
Compensation
Employees need to feel that they are being paid fairly. Bonuses and variable pay structures can actually inhibit creative thinking rather than enabling it. They end up conveying a message to employees that management sees them as coin-operated machines, which misses the point on why most employees want to work.
Twilio doesn't go overboard on perks like tricycles, haircuts, or a dozen beers on tap. While those things are attractive to prospective employees, you risk employees taking the job for the wrong reasons. You want employees to join Twilio because they love the work, they enjoy their teammates, and they want to serve our customers—those are the durable motivators.
The best way to find out why talent is or isn't attracted to your company is to - **Ask Your Developers**. Seriously. Ask your existing talent what's working at the company and what's not. Ask developers who've been around what they love and hate about the company.
Making Developers Successful
Creating a world-class engineering culture is about building a system where developers, product managers, and executives can have repeated successes building software.
Craft a system of mechanisms and practices that enable large teams of developers to focus on building great products, honing their craft, and serving your customers.
Experiments
One of Twilio's 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.
Don't go too big, too fast
When you fund an initiative with hundreds of millions of dollars and big fanfare, the pressure for a big outcome in an unrealistically short time hangs over the team. You can achieve far more with fewer dollars and a more iterative, experimental approach.
Twilio's Story
Twilio was born out of frustration with the giant telecommunication companies. The communications industry was built upon a century of physical infrastructure investments: digging millions of miles of ditches and laying down wire, launching satellites into space, or spending billions buying wireless spectrum from governments. These were big, high-risk activities, so they moved slowly.
AWS inspired Twilio - Infrastructure as Application Programming Interfaces (APIs) that developers could invoke with a few lines of code and pennies per use. Modernizing communications for the software era seemed like a big problem, and I (Jeff) thought there was a way to solve it: **turning communication into APIs for software developers.**
Writing software that could interact with the telecom system turned out to be an insanely difficult challenge. Telecom is a weird, complicated world, full of arcane technology and terminology with loads of cruft and crust 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. However, Twilio looked at it as an opportunity. The worse the legacy world was to deal with, the bigger Twilio's opportunity was to simplify it and improve the customer experience.
Twilio would abstract one hundred years of complexity that the industry had accumulated and present it as a simple API for developers.
Twilio does not sell products to consumers. They sell a service to software developers that lets their apps communicate with voice, SMS, email, and more. You probably use Twilio every day but don't realize it.
Twilio's approach has been to win over the hearts and minds of developers who work at every kind of company with powerful, easy-to-learn communications building blocks they could quickly and confidently incorporate into the apps they're building.
So the secret of Twilio's success has been empowering a type of worker that few vendors actually treat as their customers: software developers. That's why so many developers know about Twilio, while other parts of the company didn't yet know what Twilio does.
Twilio didn't try to explain what they do. Instead, it provoked a conversation by catching people's attention and their curiosity. Later, when they looked Twilio up, they got the message. It was a suggestion to business folks that Instead of being disconnected from the business problems and customers, developers can be great company-building partners as well.
Thus, Ask Your Developer.
Top comments (0)