Ask Your Developer
When developers run the show
Description
In the early days of Twilio, Jeff Lawson liked to tell a story about a company that was, on paper, in the business of selling T-shirts. Amazon. The point wasn't the shirts. The point was that behind the ordinary act of buying one online sat an enormous machine of code — recommendation engines, one-click checkout, warehouse logistics, pricing systems — and that machine was the actual business. Lawson, who co-founded Twilio in 2008 and took it public in 2016, had spent his career watching that pattern repeat. The thing customers touched was rarely the thing that mattered. What mattered was the software underneath, and who was allowed to build it.
Lawson published Ask Your Developer in 2021, and the title is also its argument. When a business problem lands on an executive's desk — customers are churning, a competitor shipped something new, a process is too slow — the reflex in most companies is to ask a consultant, buy a tool, or convene a committee. Lawson's claim is that the sharpest move is usually the one nobody makes: turn to the engineers, describe the problem, and ask what they'd build. Not because developers are magic, but because in a digital economy they are the people who translate ambition into working reality.
That sounds simple until we notice how few companies actually operate this way. Most treat their developers as a back-office cost, a queue of tickets to be managed, a resource to be optimized rather than a creative force to be unleashed. Lawson thinks that's the expensive mistake of the decade, and he wrote the book for the executives making it.
The question we’re asking : Why does Lawson think the way a company treats its developers now decides whether it wins or loses?What we’ll see : How a communications startup's founder came to see code as the sharpest competitive weapon a business has — and what leaders keep getting wrong about the people who wield it.
Table of contents
01Chapter 1 — The T-shirt company that had to become software
Lawson's own path runs through several ventures, and he uses them as evidence rather than confession. Before Twilio he had co-founded companies in the early web era, including a startup called Nine Star and, later, an events ticketing business, and along the way he served as the first chief technology officer at StubHub. In every case the lesson was the same: the software was the product, even when the product looked like something else. A ticketing marketplace that sells seats to a concert is really a matching-and-logistics engine wearing a friendlier label. He came out of those years convinced that the digital layer had stopped being a support function and become the business itself.
The framing he keeps returning to is that every company is becoming a software company, whether or not it wants to. A bank competes on its app now, not its marble lobby. A car company competes on the screen in the dashboard and the software that updates it overnight. An insurer competes on how fast a claim moves through its systems. The physical thing still exists, but the experience of it — the speed, the personalization, the friction or lack of it — is authored in code. And code is authored by developers.
02Chapter 2 — Build versus buy, and the trap in the middle
The oldest question in corporate technology is build or buy. Should a company write its own software for a given task, or purchase a ready-made tool from a vendor? For decades the safe answer was buy. Building was slow, risky, expensive; vendors had economies of scale and someone to blame when things broke. Lawson doesn't dispute that buying makes sense for plenty of things — nobody should write their own payroll system to feel innovative. His quarrel is with what happens when a company applies the buy reflex to the things that actually make it different.
His rule of thumb is a useful one: buy what makes you the same, build what makes you different. Payroll, email, expense reports — buy them, because doing them your own way earns you nothing. But the customer experience, the core product, the thing a competitor could copy and hurt you with — that is where building pays off, because a bought solution makes you identical to everyone else who bought it. When a company outsources its differentiation, it hands its strategy to a vendor's roadmap and its competitors' shared toolkit.
03Chapter 3 — Developers are creatives, not order-takers
The emotional center of Lawson's argument is a reframing of who developers actually are. The default corporate view treats them as a kind of skilled labor: you write a detailed specification, hand it down, and they produce the code as ordered. Lawson thinks this squanders the most valuable thing developers have, which is judgment. Writing software is not typing up someone else's plan. It is a creative act — thousands of small decisions about how a thing should work, made by the person closest to the material.
The consequence is practical. If you hand a developer a rigid spec and ask them to execute it, you get exactly what you asked for, which is rarely what you needed, because the person writing the spec couldn't foresee the problems that only surface in the building. But if you hand a developer the problem — the actual business goal, the customer pain, the constraint — and let them propose the solution, you get their creativity working on your behalf. That is the literal meaning of the book's title. Don't hand down orders. Ask your developer.
04Chapter 4 — The question every company is now forced to ask
Step back from the tactics, and Lawson is describing a shift in what a business fundamentally is. For most of the twentieth century, strategy lived in the executive suite and was executed through people and physical assets — factories, stores, sales forces. Software was a tool that helped execute the strategy. What Lawson is arguing is that in a digital economy the relationship has inverted: the software is where strategy now takes physical form. The decisions that determine whether a company wins are increasingly decisions made in code, by the people writing it.
That inversion is uncomfortable for a generation of leaders, because it moves strategic power toward a group they don't fully understand and often can't do themselves. It is tempting to respond by trying to control developers more tightly — more process, more oversight, more specification. Lawson's whole case is that this instinct is exactly backwards. The more central software becomes, the more a company needs its builders to exercise judgment, and the less a distant executive can meaningfully direct the thousand daily choices that add up to a competitive product.
05Conclusion
Lawson keeps coming back to that opening image — the T-shirt company that is really a software company — because it dissolves the comfortable idea that software is somebody else's department. Amazon didn't win by selling better shirts. It won by out-building everyone on the infrastructure customers never saw. The whole of Ask Your Developer is an attempt to get executives to look past the product they sell and toward the machine that produces it, and then to look at the people who make that machine.
Related books
