LLM Book Knowledgebase

Software as Competitive Advantage

7 min read

Software as Competitive Advantage

The central argument of Jeff Lawson’s Ask Your Developer — and a thread running through How Google Works, The Phoenix Project, and The Big Switch — is that the dominant competitive variable in virtually every industry is now software. Not customer service, not distribution, not brand recognition (though these still matter) — software. The company that can build, iterate, and deploy better software faster than its competitors will win. The company that treats software as a cost center to be minimized will be disrupted.

The Strategic Transition: From Cost Center to Profit Center

The traditional view of IT within non-tech companies: a necessary overhead. Systems must be maintained, compliance must be met, emails must flow — but none of this generates revenue. The CIO reports to the CFO. The IT budget is a line item to be reduced.

Lawson identifies the moment this model broke down. At Amazon, Jeff Bezos articulated the shift explicitly:

“Our business is not what’s in the brown boxes. 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.‘”

This is not a metaphor. Amazon did not compete with Barnes & Noble on retail expertise, shelf space, or buying relationships. It competed on software. The distribution advantages it built were software advantages: recommendation algorithms, fulfillment logistics software, warehouse management systems, and eventually AWS — the infrastructure layer it built for itself and then offered to the world.

The principle generalizes:

“Software has moved from being a cost center to the profit center… Suddenly, software isn’t a liability to be outsourced. It is the source of competitive advantage.”

The Software Person Mindset

Lawson distinguishes between a software developer (a role) and a software person (a mindset):

“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. 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?‘”

This is a leadership orientation claim. Leaders who do not ask “how can software solve this?” will consistently underinvest in software capabilities, outsource the wrong things, and fail to recognize competitive threats from software-native competitors until it is too late.

The contrasting failure mode: leaders who see software as a commodity input to be procured at minimum cost. Lawson argues:

“With off-the-shelf software apps, you have to change your business to match the software — which is crazy! Really, you should change the software to build the business your customers need.”

The Build vs. Buy Decision Framework

The most practically actionable principle in Ask Your Developer is the build vs. buy framework:

“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. When your customers care, you need to build.”

And its corollary:

“Because you can’t buy differentiation. You can only build it.”

The economic logic: off-the-shelf software is available to all competitors. If every company in an industry uses the same CRM, the same e-commerce platform, the same analytics tool, none of them has a software advantage — they are competing on the same digital playing field, differentiated only by factors outside the software.

The practical implementation: a “building block” model where commodity infrastructure (cloud, messaging, payment processing, authentication) is purchased as utility services, while customer-facing and differentiating logic is built in-house.

“You tie together these building blocks into the end-to-end experience, which you imagine, build, and own — because that’s your competitive advantage. But the pieces that make it up are taken off the shelf and rapidly integrated.”

The Google Model: Technical Insight as Strategy

Schmidt and Rosenberg in How Google Works articulate the same principle from the inside of a technology company:

“Bet on technical insights that help solve a big problem in a novel way, optimize for scale, not for revenue, and let great products grow the market for everyone.”

And more specifically:

“A technical insight is a new way of applying technology or design that either drives down the cost or increases the functions and usability of the product by a significant factor. The result is something that is better than the competition in a fundamental way.”

The question “What is your technical insight?” is the filter applied to every product plan at Google. Products without a clear technical insight — products that merely deliver what existing tools deliver, slightly better or cheaper — are not worth building:

“The best products had achieved their success based on technical factors, not business ones, whereas the less stellar ones lacked technical distinction.”

This is consistent with Lawson’s framework. Competitive advantage comes from technical capability that others cannot easily replicate — either because it is genuinely novel, or because it is embedded in a codebase and team that took years to build and cannot be purchased off-the-shelf.

The Combinatorial Innovation Era

Schmidt and Rosenberg invoke Google’s chief economist Hal Varian’s concept of “combinatorial innovation”:

“We are entering what lead Google economist Hal Varian calls a new period of ‘combinatorial innovation.’ This occurs when there is a great availability of different component parts that can be combined or recombined to create new inventions.”

This is the software-as-competitive-advantage thesis in its most generative form. When a rich ecosystem of software components (APIs, cloud services, open-source libraries, AI models) is available as building blocks, the competitive advantage shifts from the ability to build basic components to the ability to combine them creatively in service of a specific customer problem. The combinatorial skill is a software skill.

Speed as a Competitive Variable

Both How Google Works and Ask Your Developer emphasize that in the software era, speed of iteration is itself a source of competitive advantage:

“The primary objective of any business today must be to increase the speed of the product development process and the quality of its output.”

And from The Phoenix Project:

“In these competitive times, the name of the game is quick time to market and to fail fast. We just can’t have multiyear product development timelines, waiting until the end to figure out whether we have a winner or loser on our hands.”

This is why DevOps (see devops-and-the-three-ways) matters strategically, not just operationally. The deployment pipeline is not just a technical improvement — it is the mechanism by which software advantage is sustained. A company that can deploy improvements ten times a day will outlearn and out-adapt a competitor that deploys quarterly.

The Disruption Risk

Nicholas Carr in The Big Switch provides the historical warning:

“But pioneering a new business while continuing to harvest profits from an old one is one of the toughest challenges a company can face.”

Companies that built competitive advantage in the pre-software era face a particular challenge: their advantages (physical distribution, brand, relationships, regulatory expertise) are not enhanced by software — they are potentially made irrelevant by software-native competitors who do not carry the organizational baggage of legacy systems and IT cultures that treat software as overhead.

The Outsourcing Trap

A recurring failure mode across sources: companies outsource software development to reduce costs, then discover they have outsourced their competitive differentiation. Lawson is explicit: “Suddenly, software isn’t a liability to be outsourced. It is the source of competitive advantage.” The IT outsourcing movement of the 1990s-2000s was economically rational under the old model (software as cost center) and strategically catastrophic under the new model (software as competitive advantage). Organizations that outsourced core software capabilities are now paying to rebuild them.

Backlinks