20 People vs a 400-Person IT Department
I know a team of fewer than twenty people that delivers more visible business value than a corporate IT department hundreds of people strong operating beside it.
Not because they are better engineers. Not because they have better AI models. Not because they have more budget.
The difference is primarily how the team is organized.
Beside the traditional enterprise IT organization sits a small group of roughly twenty people. They call themselves pirates.
About a third are not even professional software engineers. They come from business, product, operations, data, automation and technology.
Business teams love them because things that previously took months begin appearing in production within weeks.
I call this pattern the Pirate Ship Model.
Why the “Turn the Tanker” Model Gets Stuck
Most large organizations try to adopt AI using the same machinery they used for previous technology transformations.
They create steering committees, AI strategies, security policies, governance frameworks, approved-vendor lists, roadmaps, workshops and board presentations.
Every one of those things may be necessary. The problem begins when, after three months, the organization has a fifty-page AI policy, fourteen recurring meetings and nothing running in production.
That is the tanker model.
The tanker has thousands of dependencies, legacy systems, procurement, security, compliance, enterprise architecture, specialized teams and years of backlog.
It does not turn quickly. Nor should it.
Large organizations need stability. Innovation needs almost the opposite environment: short decision loops, fast feedback, direct sponsorship and responsibility for outcomes.
What Is a Pirate Ship?
A Pirate Ship is a small cross-functional team operating next to the main technology organization. Not against it. Beside it.
Its job is not to replace enterprise IT. Its job is to test a new operating model quickly, build the first production systems and prove where real value exists.
1. It Is Small
Usually a dozen to a few dozen people—small enough for everyone to understand the goal, context and current state.
2. It Is Cross-Functional
It is not composed only of developers. It may combine engineering, product, operations, UX, analytics, domain experts and business operators.
For AI transformation this matters because value is usually created at the intersection of technology and the real business process.
3. It Has Executive Sponsorship
A Pirate Ship cannot report through seven layers of management. It needs an umbrella from a CEO, COO, CTO or board-level transformation sponsor.
The sponsor does not micromanage the team. The sponsor removes blockers and protects the team from being absorbed into processes designed for a different kind of work.
4. It Is Allowed to Move Faster
This does not mean ignoring security, law or architecture. It means not forcing every AI experiment through the same process used for changes to mission-critical core systems.
If every AI use case goes through the same governance path as a SAP change supporting billions in revenue, innovation loses before the first deployment.
Core IT Remains the Source of Truth
This is the most important distinction.
The Pirate Ship Model does not assume legacy IT is bad and should be bypassed.
Traditional IT remains the source of truth: SAP, ERP, CRM, identity, data, infrastructure, security and critical processes.
The pirates build a new value layer on top of that foundation.
- Core Enterprise IT — systems of record and critical processes.
- Controlled Access Layer — APIs, events, read models and permissions.
- Pirate Ship — AI agents, automations, new workflows and internal products.
- Business — users, operations and measurable outcomes.
The Pirate Ship does not sink the tanker. It sails ahead and discovers where the organization should go.
The Pirate Flag Is Not a New Idea
During the development of the original Macintosh, Apple's small Macintosh team deliberately cultivated a distinct identity, symbolized by a pirate flag over their building.
The lesson is not romantic rebellion. The lesson is organizational separation: creating an environment where a small group can focus on a new product model without carrying the full weight of an organization optimized for the existing business.
We Saw the Same Pattern During the Rise of E-Commerce
Two decades ago the same organizational conflict appeared around online retail.
Sales saw cannibalization. Logistics saw parcels instead of pallets. IT saw another system to maintain, often built with technologies that did not fit enterprise standards at the time.
Smart boards created small independent e-commerce units with their own goals, budget, team and pace.
When online represented 1% of revenue, people asked whether it made sense. At 10%, the question became how to scale it faster.
AI is entering a very similar phase.
AI Today Looks Like E-Commerce Twenty Years Ago
Everyone can see that something is changing, but existing functions interpret the change through their current responsibilities.
- IT sees security, architecture and vendor risk.
- HR sees skills, roles and accountability.
- Legal sees data, IP and compliance.
- Business sees faster workflows, lower costs and new possibilities.
Each perspective is valid. The problem begins when all of them must be fully resolved before the first production deployment.
An organization can spend a year “transforming with AI” without redesigning a single real workflow.
Why AI Amplifies Small Teams
AI radically increases the leverage of small teams.
A few years ago even a modest product initiative needed separate frontend, backend, QA, DevOps, analytics and project-management capacity.
Today portions of that work can be compressed with coding agents, AI-assisted testing, automated documentation, research, workflow automation, AI analytics and infrastructure automation.
This does not mean roles disappear. It means twelve to twenty carefully selected people can test more hypotheses and move from problem to production much faster.
Why Some Pirates Should Not Be Programmers
AI transformation is not only a software-engineering problem. It is a work redesign problem.
The most valuable questions are:
- Where do we lose time?
- Which decision is still manual?
- Where do people move information between systems?
- Where does knowledge exist only inside employees' heads?
- Which process exists only because systems do not communicate?
- Which manager is effectively a human API between departments?
The best person to identify these bottlenecks may not be a developer. It may be someone who has operated the process for ten years.
Pirate Ship Operating Model™
The model can be described through six principles:
- Executive Sponsorship — direct protection from a board-level sponsor.
- Small Cross-Functional Crew — a compact team combining technology and domain knowledge.
- Controlled Access to Core — access to enterprise data and systems through defined interfaces.
- Production First — the objective is real usage, not another presentation.
- Outcome Ownership — the team owns the business result, not just delivery artifacts.
- Scale After Proof — standardization follows demonstrated value rather than preceding it.
90-Day Pirate Ship Test™
After ninety days of an AI transformation, one question should be easy to answer: what is running in production?
A healthy Pirate Ship should have:
- several validated use cases,
- at least one functioning production workflow or system,
- real users,
- first production data,
- a list of things that failed,
- a concrete iteration backlog.
A tanker-style program may have an AI policy, governance framework, vendor list, training program and use-case backlog—and still no production.
Policy, governance and security matter. They should evolve in contact with real deployments rather than become a substitute for them.
Time to Production as a Core Transformation Metric
During the first months, one of the strongest metrics is Time to Production.
Not the number of workshops, PoCs, Copilot licenses or trained employees.
The real question is how long it takes to move from a business problem to a solution used in a real process.
If nothing is running in production after three months, ask whether you are transforming the company or merely managing the transformation.
Pirates Can Sink Too
The model has serious risks. Autonomy without boundaries can create shadow IT, security debt, duplicated data, ownerless systems, operational chaos and critical processes dependent on a handful of people.
Autonomy therefore cannot mean anarchy.
A mature model combines freedom to build with clear architectural boundaries, controlled access to core systems, production ownership, observability, security guardrails and explicit integration criteria.
When Should the Pirate Ship Return to Port?
1. Integration
A proven solution becomes part of the core platform or standard IT portfolio.
2. Internal Product
The pirate team retains ownership and develops the solution as an internal platform for multiple business units.
3. New Business Unit
If the area becomes strategic, the experimental team may become the foundation of a new organizational capability—exactly as happened with e-commerce teams.
Pirate Ship Maturity Model™
- Stage 0 — Debate: AI exists mainly in decks and discussion.
- Stage 1 — Pirate Ship: a small autonomous team is created.
- Stage 2 — Production Proof: the first workflows and products run in production.
- Stage 3 — Business Pull: other departments begin requesting similar solutions.
- Stage 4 — Platformization: proven patterns move into shared infrastructure.
- Stage 5 — Organizational Redesign: the organization redesigns whole processes around AI capabilities.
Stage 5 is real transformation. Not a tool rollout. Not a license. Not a policy. A change in how the organization operates.
The Biggest Mistake: Trying to Change the Whole Company at Once
Large organizations often begin with: how do we deploy AI to 10,000 employees?
A better question is:
Which one process can we redesign so well that 10,000 people start asking for the same change?
Technology transformation rarely begins with mass rollout. It begins with an example that works, demonstrates a new capability and creates business pull.
What to Measure Instead of “AI Adoption”
- Time to Production,
- process time before and after redesign,
- manual handoffs removed,
- decisions supported by current context,
- frequency of real business usage,
- business pull from additional departments,
- percentage of experiments that graduate into durable ownership.
Executive Checklist: Do You Need a Pirate Ship?
- Has your AI transformation existed mostly in presentations for months?
- Does business wait much longer for automation than it expects?
- Does every AI use case follow the same process as a core-system change?
- Is there a board-level sponsor ready to remove blockers?
- Can core data and capabilities be exposed safely through APIs or events?
- Can you identify three to five high-value, controlled-risk processes?
- Can the team own the outcome end to end?
- Do you have explicit criteria for integration and platformization?
Technology Does Not Win. A New Operating Model Does.
The history of e-commerce is a useful warning. Companies that treated the internet as another IT project debated integration. Companies that saw a new business channel built new operating models.
AI will follow a similar pattern.
The advantage will not go to the companies that buy the first copilot, model, agent or automation platform. It will go to companies that learn to organize work differently.
How Do You Know Your AI Transformation Is Moving in the Right Direction?
Look for one simple signal.
After three months, something should exist that did not exist before: a process, product, agent, automation or new workflow—and a real user should be using it.
If three months produced mainly meetings, roadmaps and a fifty-page AI policy, you may not be transforming the organization.
You may simply be trying to turn the tanker.
Sometimes the smarter move is simpler:
Launch the Pirate Ship.
Softech POV
At Softech, we see AI transformation as an operating-system design problem rather than a tool-selection exercise. A small cross-functional team can move rapidly from business process to production solution while using existing enterprise systems as the source of truth and adding a new layer of AI-native workflows above them.
In the first phase of transformation, you do not need to turn the entire tanker. First, you need to show where it is worth going.