Everyone is giving you the same advice right now.
Give your developers AI tools and they'll move faster.
Of course... do that!
But that's just your same team with better tools. It's not a new development team.
AI changed what a small team can build and how fast they can build it. And your existing team, buried inside your existing product, can't take advantage of it. They're too busy keeping the lights on.
You need a new team. A small one, off to the side, with a blank slate.
Your Product Is Too Complex
At VinSolutions, we spent eight years building a CRM system for car dealers. By the end, it had so many levers and switches that I didn't even know what they all did. And I built a lot of them!
Not a single person in the entire company knew how the whole system worked.
Now imagine being a developer or a support person trying to make changes to that system. You don't know which switch you can pull or what it's actually going to do when you pull it.
A literal bug is likely to pop out of somewhere!
So you have to move slow. Leadership adds layers of approvals to avoid risk. You are forced to schedule another meeting to make sure you don't break something nobody remembers building.
That wasn't a VinSolutions problem. That's every product that survives long enough to matter. What is now a two-day idea takes two months to ship, if it ships at all, and it's not because your team got worse.
I've felt this my whole career. Give me a small team and a blank slate and I'll get more done in three weeks than in three months of fighting an existing codebase. I have always been way more valuable doing proof of concepts and prototypes than managing the day-to-day of a big team.
I hate processes. I just want to break things and move fast!
AI doesn't fix this. The complexity is organizational, not technical. It is why you need a new team.
The Original Skunk Works
Time for a quick history lesson.
In 1943, the Germans started flying jet fighters. The US Army needed one fast, and Lockheed's engineering organization was completely buried in wartime production.
So an engineer named Kelly Johnson pulled a small hand-picked team out of the main org and set them up in a rented circus tent next to a plastics factory. The tent smelled awful. One of the engineers started answering the phone "Skonk Works," a joke from the Li'l Abner comic strip, and the name stuck. Lockheed eventually made it official.
The Army gave them 180 days to deliver a working jet prototype. They did it in 143!
No committees. No status reports. Almost none of the process the rest of Lockheed ran on. That same little team went on to build the U-2, the SR-71 Blackbird, and the F-117 stealth fighter.
Lockheed's smartest move was protecting the team from Lockheed.
AI Raised the Stakes
A skunkworks team used to be a nice-to-have. Now I think it's survival.
The key to AI is you have to reimagine how the work is done. AI can streamline and automate so many parts of the software development process. Requirements, architecture, coding, testing, documentation, all of it. Doing it the old way and thinking the old way is the biggest limiter, and most teams don't even realize they're doing it.
Most teams ask "how do we bolt AI onto what we already have?"
The better question is "what would we build if we started from scratch today?"
Your main product team can't ask that question. They have customer commitments and a "golden goose" they can't kill. A skunkworks team can. That's the whole point of having one.
I Lived This One
Let me give you a real example.
CAMP Digital built an industry-leading marketing solution for home services companies. HVAC, plumbing, electrical. They were great at it. But they didn't service smaller home service companies, and because of the way they already did everything, it was very difficult for them to reimagine how to handle a different market segment with a different product and a different service delivery model.
The whole company was built around the existing model servicing larger companies. The technology, the processes, the people. Things were not as automated or streamlined and that didn't matter for larger paying customers. But they knew it wouldn't scale to a lot of smaller clients.
So we partnered up and spun the idea out into a brand new company I started called At Capacity, with me as CTO. We had a small team of developers from Full Scale, and within a few months we had prototyped the entire thing and got the product to market.
It worked so well that CAMP Digital acquired the company back. The technology we built from scratch now powers their entire business, both market segments, the big companies and the small ones.
That's the full loop. We rebuilt the technology from the ground up, but we had to do it separately, outside the constraints of the old product and the old company. Sometimes starting over separately is the only way to innovate.
It Takes a Different Breed of Developer
Not every good engineer is a good skunkworks engineer.
I've written before about MVP developers, the ones who are great at the first 80% of a project and bored to death by the last 20%. That's the personality you're looking for.
It takes a different kind of creativity. A different kind of curiosity. And a lot less fear of making mistakes.
Let's be honest, most people are scared to take risks at work. They don't want to lose their job or let someone down. On your main product, that instinct is probably right!
But new projects are about experimentation. Moving fast and breaking shit. Throwing away half of what you built last week and not crying about it. Living with a ton of ambiguity, because there is no spec and no examples to copy from.
Some developers thrive in that. Most don't. You have to find the ones who genuinely enjoy it. (It is the only place I would want to be!)
Don't ask them to do bug fixes. Put them on the skunkworks team and let them build your next jet.
Ownership Makes It Work
None of this works if you hand the team a spec and a deadline. That's just the old assembly line with a cooler name.
In my book Product Driven, I make the argument that ownership is built through trust and safety, not accountability pressure. A skunkworks team is that idea in its purest form. You give them a hard problem, you trust them with it, and you get out of the way.
That means protecting the people who try. If a failed experiment gets punished like a screwup, everyone stops experimenting and plays it safe. Most engineers don't resist ownership. They just don't believe it's safe to take it.
Make It Permanent
Most companies do this as a hackathon. One initiative, ship it, disband the team.
That's the mistake. The complexity doesn't go away after this quarter's project ships. It gets worse every year your product survives.
Keep the team small. Give them their own repo and their own rules. Have them report to someone senior enough to protect them from the rest of the org. And expect most of what they build to get killed. That's fine. That's the job.
Your product will always get more complicated. Your organization will always add layers. That's the tax you pay for building something that works.
Give a few of your best people a tent and a blank slate, and get out of their way.
It worked in 1943. It still works today.