The argument in four sentences
1. Your customer experience is now delivered as software, which means you compete on software-industry terms.
2. Decades of evidence from that industry connect delivery performance to operating practices, not tool choice.
3. Companies keep trying to buy the operating model anyway: platforms, martech, transformation programs, and now AI, with the same failure recurring underneath.
4. The durable advantage is velocity, the rate at which a team turns intent into live customer experience, and it has to be built.
Your software becomes your customer's experience.
We've all heard some version of the line “every company is a software company.” Usually it's followed by an argument for buying more software. We mean something entirely different: a description of the terms you now compete on.
Think about the way your customers experience your organization today: the website, the portal, the campaign landing page, the personalized offer, the answer your chatbot gives someone at 2 a.m. Increasingly, your customer experience is software.
And once that's true, something else also becomes true: you have a backlog. You have releases. You have decisions that either get made quickly or spend three weeks ricocheting around an organization. In short, you have a software delivery operation, whether anybody calls it that or not.
If you lead marketing, digital, or technology, the question is no longer whether you're in the software business. You are. The question is whether you're operating like a winning one.
What makes one organization faster than another?
We don't have to guess. The software industry has spent decades running what amounts to a giant natural experiment under fairly brutal competitive pressure, and two revolutions happened at roughly the same time.
The first was technological. Cloud computing put the tooling of the world's largest engineering organizations within reach of anyone with a credit card. That leveled the field, and it created a problem for anyone hoping technology itself would provide a permanent advantage: everyone else could buy it too.
The second revolution was operational. Software teams changed the way they worked. The old model treated software development like a capital project: define everything up front, approve the plan, lock the requirements, build, test, launch. That's a perfectly sensible way to construct a building.
Software is not a building.
Discover halfway through construction that your headquarters is in the wrong city and you have a very expensive problem; discover halfway through a software project that the market wants something different, and changing direction should be an advantage of the medium. The best software organizations built for that advantage: smaller pieces shipped sooner, decisions moved closer to the work, market response steering what got built next. They did it not because Agile ceremonies were inherently magical, but because shorter feedback loops helped them make the unknown known.
Research from the DORA program, including the work documented in Accelerate, has repeatedly connected software delivery performance with organizational and delivery practices, not tool choice. Technology raised the ceiling, and the operating model determined how close the organization got to it.
If that sounds familiar, it's because the same sequence is now running through marketing.
What's the difference between speed and velocity?
We use the word velocity deliberately. Speed tells you how fast something is moving. Velocity tells you how fast it's moving and in what direction, and that difference gets lost surprisingly often.
A team can become incredibly efficient at producing the wrong things. It can automate a broken process. It can use AI to create ten times more content nobody needed in the first place. The result? You're moving faster, just not necessarily forward.
When we talk about organizational velocity, we mean the rate at which a team can turn intent into a live customer experience, and then use what it learns to improve the next cycle.
That depends on some decidedly unglamorous things: who owns the work, who can make which decisions, and how quickly market feedback reaches the people who can act on it.
This is why two companies can run the exact same technology stack and operate in completely different worlds. One changes a headline before lunch; the other opens a ticket. One launches an experiment this week; the other schedules the meeting where everyone will decide who needs to attend the meeting about the experiment.
Same platform. Very different velocity.
We keep trying to buy the hard part
Once companies saw faster organizations pulling ahead, an industry emerged to sell them the recipe: frameworks, certifications, transformation programs, consultants, new process layers. Sometimes these helped.
But there was a recurring failure mode: companies installed the visible artifacts of a new operating model without changing the authority structure underneath. You could call the meeting a stand-up, a scrum, or Tuesday Morning Innovation Time; if nobody in the room had the authority to decide anything, the name was never the problem. The organizations that genuinely became faster changed the machinery beneath the ceremonies: decision rights, ownership, batch size, feedback loops.
And now we're doing it again with AI, at much higher speed. A widely discussed 2025 report from MIT's Project NANDA, The GenAI Divide, examined enterprise AI initiatives and found a striking gap between experimentation and measurable business impact. Its argument was not simply that organizations needed better models: integration, workflows, and the organization's ability to absorb the technology mattered enormously.
That should sound familiar, because we've run this play before. We bought martech to make marketing faster. Then we bought digital experience platforms to make digital faster. Now we're buying AI to make everyone faster. Each time, the same inconvenient questions sit underneath the technology: who decides, who owns the outcome, and what can change without escalation.
AI doesn't eliminate those questions; it makes them more urgent. Make execution dramatically faster without improving judgment or governance and you don't eliminate organizational problems; you accelerate them.
So why does marketing still feel so slow?
This is the part I find most interesting. The operating revolution that transformed software engineering never fully crossed the organizational border. Marketing and digital teams inherited all the technology: CMS platforms, DAMs, CDPs, personalization engines, experimentation platforms, analytics suites, automation tools, and now generative AI. Stack after stack after stack.
What they often didn't inherit were the operating practices that made modern software organizations fast. So we ended up with dashboards but not always the feedback loops; experimentation technology inside organizations where getting an experiment approved takes a month; content platforms surrounded by six layers of review; AI systems capable of acting in seconds connected to governance processes measured in weeks. Then everyone looks at the platform and asks why the transformation didn't happen, when the platform may not be the problem. The test was never the platform; it's how quickly your organization can get out of its own way.
You can't buy velocity. You build it.
Acting like a software business does not mean making your marketing team speak like engineers. (Please don't start assigning story points to press releases.) It means learning the lessons the software industry paid dearly to discover.
1. Settle decision rights before you make another platform decision. A surprising amount of “process friction” is really authority friction: nobody knows who can approve the content, and the team responsible for the outcome doesn't control the decisions required to produce it. Before buying another tool, write down who can decide what (content, design, experiments, budget, AI use, publishing) and what evidence reopens a decision once it's made. This sounds almost embarrassingly basic, which is probably why it gets skipped.
2. Shorten the distance between shipping and learning. Most organizations measure production: campaigns, pages, assets, tickets. A more revealing measure is how long an idea takes to become something a customer can react to. Measure that cycle time, then shorten it: smaller releases, sooner, shaped by the response to the last one. The goal isn't to move faster for its own sake; it's to reduce the time you can spend being confidently wrong, which is the direction part of velocity.
3. Stop treating marketing and technology as two delivery organizations. Marketing defines something. Technology interprets it. Questions go back. Answers come forward. Priorities change. Tickets pile up. Then everybody wonders why a “simple change” took six weeks. High-velocity organizations don't eliminate specialization; they eliminate unnecessary translation. The closer these teams get to a shared backlog and a shared definition of the outcome, the less energy goes into managing the boundaries between them. The org chart can keep its boxes; the work shouldn't have to care so much about them.
4. Govern for speed. Governance has a branding problem: mention it and most people picture a committee slowing everything down. Good governance does the opposite, answering questions before they become emergencies. With AI this becomes urgent: the moment a system writes, publishes, or acts on your organization's behalf, somebody has made an authority decision, and the only question is whether you made it deliberately. Decide what AI can do independently, where human review is required, and who is accountable when it gets something wrong. Organizations that answer these early move fast with confidence; organizations that don't discover their governance model one incident at a time.
That's an expensive way to write policy.
The moat you can't license
None of this is an argument against technology. Choose your platforms well, keep the architecture flexible, and give your people capable tools.
Technology sets the ceiling.
But there's a reason two organizations can buy the same platform, hire similarly talented people, and produce radically different results. The difference isn't hiding somewhere on the invoice. It lives in the organization around the technology: clear ownership, smaller batches, faster learning, better decisions, cross-functional trust, and governance that creates confidence rather than delay. That is velocity, and unlike your platform, your competitor can't buy an identical copy of it on Tuesday; it has to be built.
More importantly, it compounds. Every decision that stays made shortens the next cycle, and every feedback loop that gets tighter helps the organization make the next decision with better information. Eventually, the organization isn't simply producing things faster; it is getting better at getting better, and that is a much more durable advantage than another feature in the stack.
Every company is in the software business now. The companies that learned how to win in software left behind a pretty useful playbook. It would behove us to use it.