Does every CTO need a skunkworks?

Something shifted in the last year and I’m not sure everyone has clocked it yet. A couple of good engineers running a fleet of coding agents can now spin up five working MVPs from scratch in the time it takes a normal team to grind through a couple of sprints on one straightforward feature. I don’t mean toy demos either, I mean things you can click through, deploy, and put in front of a real customer to watch them react. That’s a different category of speed altogether, and most engineering orgs have no idea what to do with it.

That kind of speed doesn’t survive contact with a normal engineering department, though. The moment your five-MVPs-a-week crew has to route through the branch protection rules, the design review, the architecture sign-off, the shared component library that everything has to go through, and the ticket that references an epic that references a quarterly objective, they slow right down to everyone else’s pace. All that process earns its keep on the product that actually pays the bills, and I’d defend most of it there. It just quietly strangles anything trying to move fast.

So you do what Lockheed did in the 1940s when it needed a fighter jet faster than its own bureaucracy could manage. It stuck a tiny team in a rented shed, well away from the process, and let them build, which is where the word skunkworks comes from. The idea travels perfectly to software. Give a small crew a blank repo, a direct line to someone who can actually make decisions, and permission to ignore the house style and bin whatever doesn’t work. Not a hack day, not an innovation lab with beanbags and a demo nobody ships, but a standing team whose whole job is to find out fast what’s worth building.

The people you want in there are a specific breed, and most companies mishandle them for years. They’re the hacker-mentality engineers, the ones who move fast and break shit and love every second of it. Give them a blank page and they’ll have something running before the kickoff meeting would have finished, make five hard technical bets before lunch and get four of them right, and genuinely enjoy the part where nothing exists yet. Hand them a fleet of agents and they get frightening in the best possible way. Those same people tend to wilt the second a product turns into maintenance and tickets and edge cases, which is usually the point a normal org tells them to knuckle down and slowly sands off the thing that made them special. In a skunkworks that restlessness is the entire point rather than a performance problem.

And these are emphatically not the vibe coders I moaned about in vibe coding isn’t engineering, the ones who hammer a prompt until something runs and then ship it blind. They’re the opposite. These are top-tier engineers who happen to be brilliant at driving AI, the sort who burn a big token budget and make every single one of those tokens count. They still carry the whole system design in their heads, they’ve just worked out how to get there ten times faster because they know exactly what to ask for and can smell when the model has quietly done something stupid.

None of which means you let them anywhere near production on their own. Moving fast and breaking shit is perfect when the thing breaking is a prototype nobody depends on, and a genuine disaster when it’s the live system holding real customers’ money. That afternoon’s MVP still has the permission check that only looks like it works and a stack of assumptions that fall over the instant real traffic arrives, however good the engineer who built it. So the fast crew proves the idea is worth having, and the steadier hands who actually enjoy the last twenty per cent turn it into something safe to ship.

So does every company actually need one of these, or is it a toy for the big players with money to burn? A few years ago I’d have said luxury, because a skunkworks meant pulling your sharpest people off real work to go and tinker. Agents have changed the maths completely. Keeping two or three hackers on permanent standby costs almost nothing now, and being able to answer “could we have a rough version of that by Friday” with an actual yes has never been worth more. I’m coming round to the view that every CTO should have one of these in their back pocket, whatever the size of the company. You don’t have to run it constantly. You just want to be able to reach for it the week you need to outrun your own organisation.