Large companies rebuild startup speed through three structural changes: a small dedicated team of four to seven people removed from the matrix with no dual reporting, a budget envelope the team controls without per-item approval, and explicit written decision rights that name exactly what the team decides alone. Everything else is secondary.
- This is not a talent problem. The people inside large organizations are highly capable.
- The startup taking the category makes decisions in 48 hours that take the incumbent 48 days.
- Approval layers, legal queues, and locked planning calendars are what kill the speed.
The direct answer: large companies rebuild startup speed through three structural changes. First, a small dedicated team (four to seven people) removed from the matrix and given no dual reporting lines. Second, a budget envelope the team controls without per-item approval. Third, explicit written decision rights that specify exactly which decisions the team makes autonomously, with no upstream sign-off required. Everything else is secondary to those three.
Every large company has a startup story. Most of them involve a small team, constrained resources, a deadline that felt impossible, and a decision process that could fit in a single conference room. The products those companies built in Year One moved fast because they had to. Now they have 3,000 employees, 18 approval layers, a legal review queue, and a planning calendar that locks down Q3 priorities in January. The startup that takes their category will be making decisions in 48 hours that take their team 48 days.
This is not a talent problem. The people inside large organizations are, on average, highly capable, often more experienced than the challengers competing with them. It is not a budget problem; the challenger brand running $500K in monthly ad spend is competing against a parent company with a nine-figure media budget. The speed gap is structural. It lives inside the approval architecture, the team design, and the decision rights framework that the organization has built, usually without consciously choosing to build it.
The question I hear most consistently from innovation leads and C-suite sponsors at Fortune 500 companies is not "how do we catch up?", it's "why do we keep falling behind when we clearly have more resources?" That question is the whole subject of why Fortune 500 brands keep losing to DTC challengers. The answer is almost always the same: the structure is optimized for control, not velocity. Those two things are genuinely in tension.
The approval architecture
is the moat, and you're
inside it.
The average enterprise product decision passes through between five and nine organizational sign-offs before reaching execution. Legal review for risk exposure. Finance approval for budget. Brand checks for consistency. Technology architecture review for integration compatibility. Regional stakeholder alignment. Category manager input. Executive sponsor sign-off. Each layer adds days. The layers compound.
What makes this difficult to fix is that every layer exists for a reason. Legal review exists because the company has been sued. Brand checks exist because a regional team once launched something that conflicted with a global campaign. Finance approvals exist because a business unit once overcommitted its budget. The approval architecture is, in most cases, a scar map of past failures. The problem is that it applies equally to decisions that carry significant risk and to decisions that carry none, which means it adds delay without proportionate risk reduction.
"The approval architecture is a scar map of past failures. The problem is it applies equally to decisions that carry significant risk and decisions that carry none."
The committee problem compounds this. Most large companies have learned (correctly) that single-person decisions at scale carry too much individual risk. So they move decisions into committees. The committee format adds stakeholder breadth at the cost of decision speed, and it creates a second-order problem: committees optimize for consensus, not quality. The best decisions are often the most contested. Committees have structural incentives to select the least-contested option. Speed dies in the search for alignment.
The fast-moving units inside large companies that I have worked with share one trait: they have been explicitly exempted from a portion of the standard approval architecture. Not all of it (they still operate inside legal, financial, and brand guardrails) but they have been granted a decision perimeter within which they can move without upstream sign-off. That exemption is the product of a deliberate organizational choice, and it almost never happens without an executive sponsor willing to defend it.
How to Audit Your Own Approval Architecture
Before you redesign anything, map what you actually have. Take the last three product decisions or campaign launches your team executed and trace every step from initial proposal to live. Count the number of distinct people who had to say yes. Note how many days each sign-off took. Identify which approvals were driven by genuine risk versus habit or politics. Most teams who do this exercise discover that roughly half their approval steps are habit-based, not risk-based. Those are the ones you can systematically remove or convert to consultation rather than sign-off. The pattern of enterprise organizations losing to smaller challengers almost always traces back to this audit never being done.
Outsourcing work to agencies
doesn't outsource the bottleneck.
It moves it downstream.
The instinct, when an organization recognizes it cannot move fast internally, is to hire an agency that can. The agency has specialist talent, existing process, and no internal politics. They can build the landing page in a week instead of a quarter. What this logic misses is that the bottleneck in most enterprise projects is not execution, it's decision-making. The agency can execute at speed. But the agency still needs internal approval at every meaningful decision point: the brief, the strategy, the creative direction, the copy, the launch, the optimization decisions post-live.
Every agency handoff is an approval event. A project that requires eight internal approvals takes the same amount of time whether the work between approvals is done by internal staff or an external team. The execution speed of the agency is largely irrelevant if the organizational decision rhythm is 10–14 days per review cycle.
The more serious version of this problem is when companies use agency dependency as a substitute for building internal capability. The agency learns the brand, the channels, the customer, and the platforms, and the internal team learns how to manage the agency. When the agency relationship ends or the market shifts, the company is left without the capability it thought the agency relationship was building. Speed and capability are not the same thing. Agencies can provide the former. They rarely build the latter.
Agency relationships work when scoped to execution on a strategy the internal team fully owns, not as a substitute for internal strategic capability. The companies that use agencies most effectively treat them as production resources with deep channel expertise, not as strategic partners who will tell the company what to do.
The test: if your agency disappeared tomorrow, could your internal team reconstruct the strategy and brief a new partner within two weeks? If the answer is no, the dependency has grown beyond what is healthy for organizational velocity.
There is a version of agency dependency that is even more costly than capability erosion: the agency becomes the institutional memory of what the brand stands for in a given channel. When the platform changes or the agency relationship ends, the company does not just lose execution capacity. It loses the reasoning behind every campaign decision made over the last two years. The fix is deliberate: insist that every agency engagement produces documented strategy rationale, not just deliverables. The work is owned by the agency. The thinking must be owned by the team.
Matrix organizations are
consensus machines. Consensus
is the enemy of speed.
The matrix organizational model, where team members report to both a functional leader and a business unit leader, was designed to balance functional expertise against business priority. It is one of the most effective speed destroyers in corporate history. The dual reporting line creates dual accountability, which creates negotiated priority, which means every project competes for resource attention with every other project at the functional level. The person working on your initiative is also working on seven others. They cannot prioritize yours without deprioritizing someone else's, which requires a negotiation, which takes time.
The result is that speed in a matrix organization depends almost entirely on the informal influence of the initiative's internal champion. Projects with highly connected, senior sponsors move fast because the champion can apply informal pressure across functional boundaries. Projects without that sponsorship move at the pace of whoever happens to have bandwidth. This is not a sustainable operating model for innovation, which by definition requires working on things that are not yet prioritized by the existing power structure.
The companies that have successfully built fast-moving units inside large organizations have, almost without exception, removed those units from the matrix. A dedicated team with clear headcount, no dual reporting lines, and a single accountable leader moves at a categorically different speed than a cross-functional team assembled from borrowed resources. This is uncomfortable for large organizations because it requires making permanent headcount commitments to work that has not yet proven its value, which is precisely the kind of bet that large companies are structurally bad at making.
The objection I hear most often from senior leaders at this point is: "we cannot afford to pull people out of their functional roles." This is worth examining honestly. The cost of running a cross-functional team that moves slowly is not zero. A matrix team working on an innovation program for 18 months to produce something a dedicated team could have built in four months carries an enormous opportunity cost. The resources are being spent either way. The question is whether they are being spent in a structure that produces results or in a structure that produces presentations about results.
There is also a talent argument that rarely gets made. The best people inside large organizations are often the most frustrated by the matrix, because they can see clearly what the structure is costing them. Dedicated fast-moving teams become a retention tool as much as a speed tool. Giving talented people the ability to work in a structure that matches their operating tempo keeps them from leaving to join challengers, which is the most direct form of the speed gap widening over time. The pattern of failed enterprise DTC launches almost always includes a talent exodus that the organization blamed on the market but was actually driven by the operating model.
Fast looks like a small team
with a clear mandate and
permission to make decisions.
The operational profile of a fast-moving unit inside a large organization is consistent across the examples I have seen work. The team is small, four to seven people covering product, build, marketing, and analytics. It has a budget envelope it controls without per-item approval. It has a defined scope, the category, channel, or market it owns, and a clear mandate to move within that scope without seeking permission for individual decisions. And it has a senior executive who serves as its shield against the approval architecture.
| Dimension | Standard Enterprise Team | Fast-Moving Unit |
|---|---|---|
Decision Cycle |
10–30 days per approval | 48–72 hours within mandate |
Team Size |
15–40 (cross-functional matrix) | 4–7 (dedicated, no dual reporting) |
Budget Control |
Per-item approval above threshold | Envelope control within quarter |
Launch to Market |
6–18 months | 4–12 weeks |
Test-and-Learn Cycle |
Quarterly, requires sign-off | Weekly, self-authorized within guardrails |
Year 1 Success Metric |
P&L contribution | Learning velocity + staged milestones |
The budget envelope model deserves attention because it is one of the most practically impactful changes a large organization can make. A team that controls its own quarterly spend envelope can move at the speed of its own decision-making. A team that needs finance approval for each spend event moves at the speed of the finance approval queue. The organizational cost of giving the team envelope control is modest. The speed benefit is substantial.
What the Mandate Actually Says
A clear mandate is not a broad mission statement. It is a specific written document that defines: the category or channel the team owns; the decisions they can make without approval; the metrics they are accountable for; the time horizon they are operating on; and the executive they report to. Vague mandates produce vague output. Teams that move fast have a mandate they can quote from memory, because it actually constrains them in useful ways while opening the decision space they need.
Decision rights aren't a policy.
They're a product. Design them
with the same intentionality.
The most useful reframe I have found when working with innovation teams is to treat the decision rights framework as a product design problem. Who can make which decisions, at what dollar or risk threshold, without seeking upstream approval? What decisions require cross-functional alignment before execution? Which decisions are reversible, and therefore can be made without the same scrutiny as irreversible ones?
Most large organizations have implicit decision rights, patterns that emerged from culture and practice rather than being deliberately designed. Implicit rights are almost always slower than explicit ones, because every team member privately estimates their own authority before acting on each decision. The estimation itself takes time, and people systematically underestimate how much they can do unilaterally, it's safer to ask than to proceed and be wrong. Explicit decision rights documentation removes that estimation step entirely.
The framework is explicit about the difference between "requires approval" and "requires consultation." Many decisions currently gated behind approval would be better served by requiring brief consultation (a 15-minute conversation with a legal or finance stakeholder) without requiring formal sign-off. Most legal and finance teams, when asked directly, will tell you which decisions in their queue actually need full review and which are being sent to them as a CYA behavior. That conversation alone can unlock significant velocity.
The Reversibility Test
When building your decision rights framework, one of the most useful organizing principles is reversibility. A decision that can be undone in 24 hours carries fundamentally different risk than one that cannot. Copy tests, spend reallocation within the budget envelope, creative variations: all reversible, all should be autonomous. Technology architecture choices, brand extensions, major channel commitments: largely irreversible, warrant scrutiny. The mistake most organizations make is applying the same review process to both categories. The reversibility test produces a clearer, faster framework than any risk score model I have seen. Ask the question directly for each decision type: if this is wrong, how long does it take to undo? Let the answer determine the review requirement.
The second useful organizing principle is cost. A $5,000 spend decision and a $500,000 spend decision should not go through the same approval queue. Set explicit thresholds that match your team's risk tolerance, and document them. Teams that know exactly where the line is move confidently up to it. Teams with vague authority estimate conservatively, which means they are functionally operating with less authority than they have been granted. The written document exists precisely to remove that estimation step. See how this compares to the governance patterns of real versus theatrical innovation programs.
Every fast unit inside
a slow organization
has a political sponsor.
I have not seen a single successful fast-moving unit inside a large organization that did not have a senior executive willing to spend political capital defending its operating model. The approval architecture does not exempt itself. Someone with enough organizational authority has to actively shield the unit from the standard process, and that shielding is a continuous act, not a one-time decision.
I advise Fortune 500 commerce and innovation teams, Nike, Coca-Cola, Hallmark, P&G, on building the structures that actually move. The form takes two minutes.
The sponsor role is specific. It is not a champion, someone who believes in the work and advocates for it in meetings. It is someone who can intervene when the approval architecture is about to crush the unit, and who is willing to do so visibly. When legal says the campaign needs six weeks of review and the unit needs to launch in two, the sponsor is the person who gets on the phone with the General Counsel and negotiates a parallel review path. That requires organizational authority and a willingness to spend it.
The implication is that fast-moving units need to be positioned close enough to genuine organizational power that their sponsor can act. A unit reporting to a VP who reports to a SVP who reports to a C-suite executive has too many layers between its operating reality and the authority that can clear the path. The most effective structures have the unit reporting directly to a C-level executive or to a dedicated Chief Innovation Officer with real P&L accountability.
This is the hardest part of the recommendation to act on. Most organizations create innovation programs because a senior leader is excited about the concept, but excitement does not automatically translate into willingness to take political heat when the program bumps against entrenched process. The programs that succeed are the ones where the sponsor was told explicitly, before the program launched: this will require you to intervene in the approval process. If that is not something you are willing to do, the program will fail on schedule.
What to Ask a Potential Sponsor Before Launching
Before launching any fast-moving unit inside a large organization, I recommend a direct conversation with the prospective executive sponsor. The conversation has three questions. First: can you tell me the last time you personally overrode a process decision because the business need required it? If the answer is "that does not happen here," the sponsor does not have the authority or the will the role requires. Second: if the legal team tells this unit they need six weeks for a campaign that we need to launch in two, what will you do? The answer reveals whether the sponsor understands their actual role. Third: what is your success metric for this program in Year 1, and is profitability on that list? If it is, realign or find a different sponsor. Year 1 profitability as a metric kills more innovation programs than any structural problem.
The board conversation that typically precedes launching these programs is a distinct challenge, covered in detail in the commerce strategy board conversation framework. The short version: boards need to understand why the standard operating model is not sufficient for the challenge at hand before they will support the structural exceptions required for a fast-moving unit to work.
The minimum viable structure
for a fast-moving unit
inside a large organization.
Based on the patterns I have seen work (and the ones I have seen fail) here is the minimum viable structure for a fast-moving unit inside a large organization. Each element is load-bearing. Removing any one of them tends to produce the same outcome: a program that looks like innovation from the outside and operates like a committee on the inside, the exact innovation theater that produces slide decks instead of shipped products.
Common questions
on enterprise speed
and innovation structure.
The speed gap between a challenger brand and an enterprise is not fixed. I have seen organizations move at genuinely startup pace when the structural conditions are right, and the conditions are not complicated. They require organizational courage more than organizational capability. The companies willing to make these structural commitments, dedicated team, budget envelope, explicit decision rights, executive sponsorship with real authority, can compete with challengers on speed while keeping the brand scale, distribution reach, and capital position that challengers cannot replicate. Most companies are one structural decision away from that combination.
If you are working through the build-vs-buy decision as part of rebuilding your commerce infrastructure, the enterprise build-buy-partner framework is a useful complement to this post: the structural changes described here apply regardless of which path you take, but the path you take affects how much runway you have to make the structural changes before competitors pull ahead. The lessons from what Shopify's ascent taught enterprise commerce teams are directly relevant here: the companies that moved first on structural flexibility are the ones that created the largest moats.
Recreating startup speed inside a large company is one of the hardest things to engineer, and it is exactly what the enterprise innovation practice is for. The form takes two minutes: start the conversation.
Advising Fortune 500 innovation teams.
I have helped enterprise commerce teams at Nike, Coca-Cola, Hallmark, and P&G build the structures and operating models that actually move. If you are working on an innovation program that keeps running into the organizational architecture, I know the pattern. The form takes two minutes.
Start a conversation More about Taylor →