A Fleet of Fast Boats Over a Big Ship
Why small autonomous teams outperform large organizations -- lessons from Microsoft, four exits, and 25 years of building tech companies.
I spent the early part of my career at Microsoft. The talent density was extraordinary — some of the sharpest engineers and product minds I’ve ever worked with. And yet, getting anything meaningful shipped felt like pushing a boulder uphill through quicksand.
A decision that should have taken an afternoon would consume weeks. You’d start with a reasonable idea, then spend days in alignment meetings — syncing with partner teams, getting sign-off from program managers, looping in stakeholders who had vague but apparently critical opinions. By the time everyone had weighed in, the original idea had been sanded down into something nobody was excited about, but everyone could tolerate. That’s the big ship disease. The talent is world-class, but the system metabolizes speed into consensus.
That experience shaped everything I’ve done since. Across four exits and 25 years of building and scaling tech companies, I’ve come back to the same conviction over and over: a fleet of fast boats will outrun a big ship every single time.
Why Big Ships Get Slow
It’s not malice. It’s physics.
Coordination costs scale quadratically with team size. Fred Brooks told us this in 1975 and we keep re-learning it. A team of 5 has 10 communication channels. A team of 15 has 105. A team of 50 has 1,225. Every additional person doesn’t just add capacity — they add overhead to everyone else.
Dependencies are the silent killer. When Team A needs something from Team B before they can unblock Team C, you don’t have three teams working in parallel — you have a serial pipeline with a lot of people waiting. I’ve seen organizations with hundreds of engineers where the actual throughput was worse than a single squad of eight because every initiative was gridlocked by cross-team dependencies.
Then there’s the diffusion of ownership. When responsibility is shared across too many people, nobody owns the outcome. Decisions get escalated because nobody wants to be wrong. Process replaces judgment because it’s safer to follow the playbook than to make a call. And eventually, the organization optimizes for internal alignment over customer value.
This is how you end up in a world where shipping a minor feature takes a quarter and nobody can explain why.
The Fast Boat Model
The alternative is simple in concept and hard in execution: small, cross-functional teams with full ownership of a domain.
A fast boat is 5 to 8 people — typically a product manager, a designer, and a handful of engineers. They own a problem space end to end. Not just the code, not just the feature, but the problem, the solution, the deployment, the monitoring, and the business outcome.
At this size, communication is natural. You don’t need a stand-up ceremony to know what your teammates are doing — you know because you talked to them at the whiteboard twenty minutes ago. Decisions happen fast because the people with context are the people with authority. There’s no need to write a six-page proposal and route it through three approval layers when the whole team is sitting in the same room and can hash it out in an hour.
The magic of the fast boat is that it restores ownership. When a small team owns a domain completely, they feel it. They care about the quality of the code because they’re the ones who get paged when it breaks. They care about the user experience because they see the metrics every day. They ship faster because there’s nobody to wait for.
What “Autonomous” Actually Means
Let me be clear — autonomous does not mean anarchic. This is where a lot of organizations get the model wrong. They read about Spotify squads or Netflix freedom and think the answer is to remove all structure. That’s a recipe for chaos.
Autonomy works when it’s bounded. Every fast boat needs three things:
A clear mission. Not a feature list — a problem to solve. “Reduce invoice processing time for non-PO invoices by 40%” is a mission. “Build the new dashboard” is an instruction. The difference matters enormously because the mission gives the team room to find the best solution, while the instruction turns them into order-takers.
Clear metrics. The team needs to know how success is measured, and those metrics need to be within their control. If a team is accountable for a conversion rate but doesn’t own the checkout flow, you’ve set them up to fail.
Clear boundaries. What’s in scope, what’s out of scope, what are the non-negotiables (security, compliance, brand guidelines, API contracts with other teams). Within those boundaries — full freedom on how to execute.
This is the difference between empowerment and abandonment. Empowerment is giving a team a destination and letting them choose the route. Abandonment is pushing them out the door without a map.
The Harbor Master, Not the Captain
If you’re a CTO or CPTO running a fleet of fast boats, your role fundamentally changes. You’re not steering each boat. You’re the harbor master.
That means three things in practice. First, setting the direction — making sure every team’s mission ladders up to a coherent company strategy. The boats need to be sailing roughly the same direction, even if they’re taking different routes. Second, preventing collisions — ensuring teams aren’t duplicating work, aren’t building incompatible systems, aren’t making architectural decisions that will create nightmares in two years. This is where platform teams, shared standards, and lightweight architectural governance come in. Third, clearing the waterway — removing organizational obstacles, fighting for resources, shielding teams from corporate noise so they can focus on their mission.
What you’re explicitly not doing is telling teams how to build things. The moment you start dictating implementation details to a team of capable engineers, you’ve collapsed the model back into a command-and-control hierarchy with extra steps.
The Product Operating Model Connection
This isn’t just my opinion born from experience — it’s backed by some of the best thinking in product management. Marty Cagan’s work on empowered product teams, particularly in Empowered and Transformed, lays out the same fundamental argument: the best product companies run empowered teams, not feature teams.
A feature team takes a roadmap of outputs and delivers them. An empowered team takes a set of problems and outcomes and figures out the best way to solve them. The fleet of fast boats is the organizational structure that makes empowered teams possible. You can’t have empowered teams inside a big ship because the dependencies and approval chains strip away the autonomy that empowerment requires.
One pattern from Cagan’s work that I’ve applied successfully across multiple companies is the Product Discovery Team — a trio of a Product Designer, Product Owner, and Senior Engineer. This tiny team works directly with customers to understand their actual problems and rapidly prototype solutions. It’s an extremely agile, customer-driven, and fast way to discover what to build. I’ve liked this approach so much that I’ve made it a default in every organization I’ve led.
Here’s where it gets really interesting. With the productivity gains from GenAI tools like Claude Code — where a capable engineer can build a functioning product prototype in hours rather than weeks — the line between discovery and delivery is blurring. A Product Discovery Team can now discover the problem AND build a working solution in the same sprint. This means that what used to be a Product Delivery Team of 5-8 people can increasingly look like what was previously a Discovery Team of three. The fast boat just got faster and smaller. I believe this is where product development organizations are heading: scaled fleets of these lean, discovery-capable speed boats, each one able to go from customer problem to shipped solution at a pace that would have been unimaginable even two years ago.
The Tradeoffs
I’d be dishonest if I said this model has no costs. It absolutely does.
You lose some consistency. When teams have freedom to choose their own approaches, they will. One team uses React, another uses Vue. One team writes extensive documentation, another ships fast and iterates. You have to decide which inconsistencies matter (API contracts, security practices, data formats) and which ones you can live with (internal tooling choices, coding style).
You need stronger hiring. The fast boat model doesn’t work with people who need to be told what to do every day. You need self-directed engineers, product managers who can think strategically, designers who can make decisions without waiting for a committee. This raises the hiring bar significantly.
You need to tolerate different approaches. Two teams will solve similar problems in different ways. Your instinct as a leader will be to standardize. Resist it — unless there’s a genuine technical reason to converge. Premature standardization is just centralized control wearing a different hat.
Communication across boats requires intentional effort. The natural communication channels within a small team are great, but cross-team communication doesn’t happen by accident. You need rituals — architecture reviews, demo days, shared documentation — to keep the fleet coherent.
How to Get There
If you’re currently running a big ship and want to transition to a fleet, don’t try to restructure everything at once. That’s how you sink the ship before the boats are ready.
Start with one team. Pick a domain that’s relatively self-contained, staff it with your best people, give them a clear mission and real autonomy. Let them prove the model. This first team will hit problems — unclear boundaries, missing platform capabilities, resistance from the rest of the organization. Good. Each of those problems is a lesson that makes the next team easier.
Build the platform layer. As you spin up more boats, you’ll find common needs — CI/CD, observability, authentication, shared data models. Invest in a thin platform team whose job is to make the fast boats faster, not to gatekeep or impose process.
Change how you measure. Stop measuring output (features shipped, story points burned) and start measuring outcomes (customer impact, business metrics). This is the single hardest cultural shift, and it’s non-negotiable. If you keep rewarding output, teams will optimize for shipping things rather than solving problems.
Be patient. The transition takes 12 to 18 months to really take hold. The first few months will feel slower as teams figure out their boundaries and build confidence. Leaders will get nervous and want to pull the reins back. Don’t. The compounding returns of genuine team autonomy take time to materialize, but when they do, the difference in velocity and quality is transformative.
I’ve seen this pattern work at early-stage startups and at companies with hundreds of engineers. The scale changes, the principles don’t. Give small teams real ownership, get out of their way, and watch what happens. Every time, they’ll outrun the big ship.