Ask Your Developer, book review: How to prosper in a ‘build or die’ business landscape

When you think about what makes the user experience of Uber, Netflix or your favourite grocery delivery service so good, you probably think about startups, disruption and smartphones. But as The Lean Startup author Eric Ries points out in the introduction to Ask Your Developer, APIs from Twilio are what actually make a lot of those experiences work. And if you want that kind of transformation inside your own organization, you should, well, 'ask your developer'. 

Named after Twilio's quintessentially Silicon Valley billboard on the freeway into San Francisco, this is really a book about the benefits of developer culture for people who are never going to write a line of code. 

SEE: Hiring Kit: Python developer (TechRepublic Premium)

If every business is a technology business these days, then getting digital transformation right requires better communication between the employees who understand and create your technology and those who run your business. You can either ask your developers what services you should be buying, or deal with them making their own decisions about services and APIs, and putting them on expenses. 

For several years, Twilio CEO Jeff Lawson has been talking about the importance of building rather than buying the software that differentiates your business, because software development (and IT in general) should be a competitive advantage rather than a cost centre. Here he extends the idea: 'building' is about more than building software – it's about building everything from products to processes, to make them fit you and your customers better. The people who understand this are 'software people', whether they're designing backend-processing systems or the minimal Square credit card reader. 

Seen this way, software is critical to making your business successful; it's not so much 'build or buy', as 'build or die'. 

The book is full of examples of 'digital natives' offering products "faster, cheaper and with a better customer experience". Some of those leave out a few details: mattress company Casper may be getting a fifth of Tempur Sealy's revenue with 70 times fewer employees, but it's also the company that forgot to get a financial licence to offer credit to UK customers and withdrew from the UK and European markets completely in 2020. And Robinhood is less of an example than a salutary warning in the wake of the Game Stop short squeeze furore. 

The stories are more useful and more detailed when they're Twilio customers like ING, which built its own contact centre system using Twilio APIs to replace seventeen different systems used across its various banks. Lawson's potted histories of enterprise software and the rise of cloud services and APIs do a good job of putting digital transformation in context for what he calls The Third Great Era of Software. 

His stories about dropping out of college and building startups (some of which you've heard of, some of which you probably haven't) are much funnier and less sententious than the usual Silicon Valley anecdotes. You learn a fair amount about how AWS works, and it all leads seamlessly into explaining, in sufficient but not over-technical detail, what Twilio does. But the point is less to help the reader understand specific technologies and more to set up two simple but vital insights: building software is relatively easy, but building the right thing is hard; and businesspeople will get more from developers if they share their problems rather than ask for specific solutions.

Creative problem-solvers

Most business leaders know far more about motivating their sales team than their developers, and media stereotypes of misfit geeks don't help. Code is creative, Lawson maintains, and developers are creative problem-solvers, and if you're handing them a detailed product requirements document rather than engaging that creativity it's likely to divert into side projects – or a new job. Readers don't get instructions on how to design a better requirement specification process, just examples of letting developers investigate problems and work them out. Lawson spends much more time explaining how to encourage experiments and deal well with failures, so you don't discourage those creative developers, but also know when to shut projects down. 

The section on recruiting, managing and paying developers should be required reading for anyone who meets software developers in their organisation. But not all of the ideas presented here are going to work everywhere: the Socratic method of asking questions and the open weekly business reviews that Andy Jassy is famous for at AWS can be very effective with the right culture, but done badly can turn into toxic humiliation sessions. Not every business will need to understand how to scale from a small team to the size of Amazon, but most will benefit from having small multidisciplinary teams and developing empathy for customers without falling into the trap of building every idea that customers come up with. 

SEE: Developer: Rust programming language is being used for bigger projects

The lightning tour of agile development may be useful for businesspeople with no experience of it, and Lawson's cynicism about traditional waterfall development is understandable for a startup founder who presumably never worked on products delivered that way. But anyone serious about managing development should look for more balanced explanations of the options. The notion that Microsoft is "obsessed with stamping out deduplication" will also be amusing to anyone familiar with the many overlapping products, tools and services coming out of Redmond. 

The discussion of the platform Twilio uses to build its own software is probably a little technical for the book's audience (and not detailed enough for anyone wanting to build something similar), but it conveys the point of DevOps fairly well and there's an important discussion of the trade-off between investing in developers and the features they build versus investing in tools and platforms developers will use to build those features. 

Anyone familiar with, but perhaps frustrated by, developers should find Ask Your Developer enlightening. You might chuckle in recognition when you read comments like "the engineering mind-set is often predisposed to (a) having strong opinion and (b) not keeping those opinions to themselves," but asking your developer implies listening to your developer. And if you're looking for a way to ease into those conversations, start with the question Lawson asks when talking to staff at Twilio: "What customer problem are you solving?" 

RECENT AND RELATED CONTENT

First it was Agile software development, now Agile management is remaking the workplace

The developer's dream? This company's tech workspace brings Agile development to life

Twilio delivers strong Q4 results, revenue climbs 65%

How Twilio's $3.2 billion Segment acquisition transforms the company

What is low-code and no-code? A guide to development platforms

Read more book reviews

• Lurking, book review: A people's history of online culture
• Augmented Reality, book review: Exploring the attractive and alarming potential of AR
• The Entrepreneur's Faces, book review: A compendium of startup stories
• Holiday reading roundup: How the future looked, before the pandemic
• Culture Warlords, book review: Into the heart of online darkness