← Findings 🕐 7 min read
Findings

Small Team, 500-Person Company: Use Speed to Change One Workflow Before the Organization Can Stall It

Napoleon’s corps could move on separate routes and reunite at a chosen point. The organizational lesson is not that a small team should bypass its company.


Executive Summary

  • A small team can move faster than a 500-person company when it chooses one consequential workflow, gets the people who own that workflow into the room, and can make reversible decisions without waiting for a broad committee.
  • The useful military analogy is concentration and tempo: assemble the right capabilities at one decisive point, learn faster than competing priorities can scatter attention, then expand only after the work is safe and measurably better.
  • The company version is not “move before governance catches up.” The team must work inside explicit boundaries for data, human review, customer impact, and spend.
  • Run a 30-day sprint on one workflow. Name a business owner, an accountable operator, a technical builder, and a risk partner. Set a baseline before changing the work.
  • At day 30, decide to stop, revise, or scale to one adjacent team. Measure quality, cycle time, adoption, and total cost together.

The Strategic Insight: Concentrate Effort, Not Authority

Napoleon’s corps could move on separate routes and reunite at a chosen point. The organizational lesson is not that a small team should bypass its company. It is that a small, coordinated unit can bring the needed capabilities together around a narrow objective while the rest of the organization continues its work.

In a 500-person company, “defeat in detail” should mean removing a fragmented process bottleneck one piece at a time. It should never mean treating colleagues, control functions, or skeptical teams as opponents. The target is delay, rework, handoffs, and unclear ownership—not people.

Military outcomes also depended on conditions that do not transfer cleanly to business: coercive command, physical force, and opponents who could be incapacitated. Modern accounts of the 1940 campaign in France also caution against treating “Blitzkrieg” as a simple, prewritten formula. Use the history as a prompt about concentration and timing, not as proof that speed alone wins.

The 500-Person Company Problem

At this size, a company has enough specialization to create queues but may not have enough spare capacity to staff a large transformation office. A promising workflow can wait on IT, legal, security, procurement, data access, a department head, and frontline adoption. Each review may be reasonable. Together, they can leave the work without a single owner.

The remedy is a small cross-functional team with a bounded mandate. It brings the people needed to make a specific change together. It does not claim permanent authority over the workflow or over the company’s AI policy.

The 30-Day Concentration Sprint

1. Select one workflow with a real owner

Choose a frequent, costly, or slow workflow where a named executive or department leader can authorize a trial. Define the work in observable steps: what starts it, who handles it, what judgment is required, what output is produced, and how errors are caught.

Prefer a workflow with a clear baseline, accessible data, and a human who can review the result. Avoid beginning with decisions that directly determine employment, credit, eligibility, safety, or other high-impact outcomes unless the company already has the controls and expertise to govern them.

2. Assemble a four-role team

Role Responsibility Typical allocation
Business owner Sets the outcome, resolves priority conflicts, approves workflow changes 1–2 hours a week
Workflow operator Maps real work, tests outputs, records exceptions, trains peers 20–40% for the sprint
Technical builder Configures the tool, integrations, access, and logging 20–40% for the sprint
Risk partner Defines data, security, legal, and review boundaries; resolves escalations 1–2 hours a week

One person may cover more than one role in a small company, but the responsibilities still need named owners. The workflow operator must have time to test the changed process; an enthusiastic sponsor alone is not sufficient.

3. Set guardrails before the first live use

Write down the allowed data, approved tools, human review points, prohibited actions, escalation path, and maximum trial spend. Keep the first release reversible. Do not let an experiment send external communications, alter records, or make consequential decisions without the controls and approvals already required for that work.

Ask the risk partner to attend the sprint kickoff and one weekly review. This makes review part of the working cadence rather than a surprise gate at the end. If the proposed workflow crosses a company policy or legal boundary, pause and resolve that boundary before live use.

4. Run a short build–observe–adjust loop

Days Work Evidence to keep
1–3 Map current steps and capture a baseline Volume, cycle time, quality checks, exceptions, current cost
4–10 Build the smallest safe change and test on historical or non-production cases Test cases, failure modes, reviewer notes
11–20 Trial with a small set of trained users and human review Adoption, override rate, defects, time, support burden
21–26 Fix the largest failure mode and repeat the same checks Before-and-after results, unresolved risks
27–30 Decide: stop, revise, or expand to one adjacent group Decision memo with owner, evidence, and next review date

Keep the daily coordination short and focused on blockers, exceptions, and the next test. The business owner should resolve priority and access questions quickly. That is where speed is created: fewer idle handoffs, not weaker controls.

How to Keep the Team from Being Isolated

Speed that produces distrust is not an advantage. Invite affected employees into workflow mapping and early testing. Explain what is changing, what remains a human responsibility, and how feedback will be handled. Give the team a route to raise concerns without going through the pilot sponsor.

The risk partner should be a participant, not a late-stage approver. IT, security, legal, and procurement should receive a short written scope at the start: tools, data, users, expected volume, vendor terms, and exit plan. Escalate only the decisions that exceed the agreed boundaries. Record those decisions so the next team does not restart from zero.

The Decision Rule: Scale Only When the Whole Workflow Improves

Before the sprint, choose a small set of measures and record the current state. Evaluate the changed workflow as a system; a faster first draft is not a win if review time, error correction, or support burden rises by more.

Measure Question for the day-30 review
Quality Did accuracy, completeness, or compliance hold at the required level?
Cycle time Did elapsed time from request to usable outcome fall?
Human effort Did total handling and review time change, including rework?
Adoption Did the intended users choose the workflow after training?
Exceptions Which cases still require escalation or manual handling?
Cost What are the tool, integration, review, and support costs per completed outcome?

Scale to one adjacent team only if the quality bar holds, the workflow owner confirms the result, and the full cost is understood. Otherwise, revise the design or stop. A stop decision with clear evidence is useful: it prevents a weak workflow from consuming the next team’s capacity.

What This Means for Your Organization

The first move is not a company-wide AI strategy or a new committee. It is a 30-day assignment: choose one workflow, appoint its owner, reserve the four roles, record a baseline, and agree on the safety boundary before testing. The executive sponsor should clear the specific access and priority blockers that would otherwise leave the team waiting.

The hard part is choosing a workflow that matters and earns participation from the people who perform it. If this raises questions specific to your organization, I’d welcome the conversation — brandon@brandonsneider.com.

Sources

  • Antoine-Henri Jomini, The Art of War (1838), on lines of operation and concentration. Historical framework; useful as context, not empirical evidence for modern company performance. Project Gutenberg text.
  • U.S. Army, FM 3-0: Operations (2022), on isolating and defeating parts of a larger force. Military doctrine; used here only to clarify the historical concept, not to prescribe organizational behavior. Army University Press publication.
  • Robert M. Citino, “The Myth of the Blitzkrieg,” U.S. Army Command and General Staff College, Combat Studies Institute (1987). A historiographic caution against oversimplifying the 1940 campaign into a ready-made doctrine. GovInfo PDF.
  • Robert M. Citino, “The Wehrmacht’s Last Stand: The German Campaigns of 1944–1945,” and related work on German operational history. Context for why organizational outcomes depend on doctrine, logistics, opposition, and contingency—not speed alone. U.S. Army War College / Army University Press catalog.

State of AI | brandon@brandonsneider.com October 2026