‘Labs’ teams, Skunkworks, and Special Projects: Beware
In a previous post, I talked about balancing ‘creating work’ and ‘destroying work’ such that the backlog does not become a huge mental burden on everyone to the point that it gives the impression that “the dev team is slow” or “we’re not making enough progress”. These are common themes at most of the places I’ve worked.
One typical reaction to that is to pick a particular project and try to run it differently than “business as usual”. The projects chosen are often something other than just an incremental feature for the existing project. It might be an idea for an entirely new product or business unit or some grand re-imagining of the existing product. Often a founder is nostalgic for the days when they were coding entire features in a matter of days. Unencumbered by meetings, customers, existing code, internal stakeholders, compliance concerns, and everything else that comes along for the ride, they truly could crank out product in a way they’ve never seen all these expensive devs do since.
To try to recapture some of that velocity that was ‘lost’ and get back to ‘the scrappy start-up days’, someone will inevitably propose cordoning off a special squad that can behave like they used to ‘back in the basement/garage’. They go by many names: Skunkworks, Tiger-Team, Startup-within-a-Startup, “Project Mayhem” and the like.
I’m here to rain on the parade and tell you why this is almost always going to go poorly. If you’re an engineering manager or product manager asked to participate you should almost always push back against this type of idea. There is one exception though, which I will get to.
The typical setup for a team like this:
- They have a mandate to build something that’s different from the usual.
- They are exempted from certain things that are perceived as ‘slowing them down’:
- Meetings
- Mandatory training
- Project management ceremonies and requirements
- (God forbid) security and compliance requirements
- Other rules everyone else has to follow
- Often (but not always) the project details are kept under wraps to the broader company.
Problem #1 - It’s cultural poison
It doesn’t matter how pure the motives are, the minute you separate part of the team and tell them they get to operate under different rules you’re going to breed resentment with the core team that is left behind. This is especially true if the project details are kept a secret. In the absence of information people will just make stuff up. What starts as speculation from one person “I think they’re going to build a competitor to XYZ Inc.” quickly turns into rumour “I heard they’re building a competitor to XYZ Inc.”.
Even if the project details are out in the open, people will be resentful that they weren’t picked for the team, that they still have to attend the boring all-hands meeting and the mandatory seminar on ‘giving feedback’ when other people who ostensibly have the same job do not. These feelings can be hard to repair and they destroy the cohesion you get from your broader development team ideally feeling like they’re all ultimately striving for the same goals.
Problem #2 - You’re lying to yourself that it’ll actually help
One thing I’ve learned from actually trying these schemes and failing is that most of the stuff you perceive as slowing you down is there for a reason. In the same vein as my previous post on why AI coding tools won’t necessarily help you ship more product, trying to shortcut a lot of the processes you’ve put in place over the years won’t actually help you get the product out the door. What good is a new feature if the Sales team doesn’t know how to sell it and the Support team doesn’t know how to support it? Most ‘startup-within-a-startup’ type initiatives only focus on the part where the product is built, not the part where you take it to market.
Similarly, some of that other ‘bureaucracy’ is designed so that the execs and other stakeholders know how things are going. Even in a special situation like this they’re going to be very unlikely to forego having any clue how their very special project is going so some of that process stuff is likely to creep back in.
Likewise, if you plan to sell this to your existing customer base from your existing company, you can’t just skip doing SOC2 or whatever other compliance regimes you’re under. You might be able to defer it for a while but you won’t be able to just not do it, so bring that back into scope too.
Problem #3 - You only deliver the easy part
Hopefully you’re familiar with the Pareto Principle aka the 80/20 rule. It shows up in software constantly: the last 20% of a feature consumes 80% of the effort. Hardening, bug fixing, edge cases, integrations. This is the unglamorous work that turns code into a real product. A joke I’ve heard a few times is a variant of “we’re about 80% done, we just have to do the other 80%”. I’m sure you know the feeling.
The danger inherent in a Labs team is that it produces 80% of the feature (the fun part) and then gives it back to the core team to do the “other 80%” (the hard part). This assures resentment from the core team and creates the illusion that the Labs team is fast and everyone else is slow.
And even if the Labs team sticks around to finish the tough parts, the work gets slower and less visible. That makes stakeholders impatient, leading to bad outcomes like:
- the project appears stalled and is cancelled
- the unfinished work ships anyway and lands on a team that never signed up to own it.
Either way, you’ve spread bad vibes without shipping lasting value.
Problems #4 through infinity…
- Misaligned incentives: Labs team gets rewarded for perceived velocity and novelty, core team is rewarded for stability and maintainability.
- Orphaned work: Quick prototypes that turn customer facing without a plan for longer term ownership. Maintenance work piles up with nobody to do it.
- False signals: As I alluded to in Problem #3, if you’ve got a team cranking out 80% finished prototypes that look good in a demo, the Leadership team is going to go looking for the problems that are “slowing down” the rest of the team without fully understanding what’s different about or missing from the works of the special team.
- Duplication of effort: a lower risk problem maybe but sometimes by trying to shed process you have to learn again the hard way why they’re there in the first place by making the same mistakes that other teams made in the company’s past.
It CAN actually be a good idea sometimes - When it can work
A special tiger team can work in a case where there’s a problem that is well defined, well understood, and time constrained. For example, a product I was responsible for wrote a lot of log entries about user activity to the main SQL database (part of the product, not debug logs). We had no archive or deletion capabilities in the product so the disk usage of the database servers just grew unbounded the more the product was used. At the time, we were ‘self hosting’ the database on generic cloud servers and had scaled them up to the largest instances the provider offered just to have enough disk space.
We could project out based on historical usage the rough point where, if we did nothing, we’d run out of space and, consequently, run out of options.
This turned out to be a great job for a small special operations team. It was a containable, solvable problem with a drop-dead date where a fundamental feature (and likely the whole product) would just stop working. We just needed to put some people on it, make them aware of the constraints and goals, and let them run. They solved the problem with plenty of time to spare and the ownership stayed with the team that ‘donated’ a couple of people to the project for a temporary secondment.
A small tiger team can be a great solve for an acute problem.
But it worked for Lockheed - and the Macintosh!
Well, for one, you’re not making aircraft for the military in the 1940s so it’s kind of starting out as an apples to oranges comparison. Secrecy was as big a concern there as velocity, probably bigger. And yes, the Mac was ultimately a success and we’re all grateful for that, but you need to account for survivorship bias. Pulling out high-profile examples where a Skunkworks project was a success does not make up for all of the times when it wasn’t and nobody ever heard of it.
This isn’t a very Chaotic-Good take!
I see your point, and if I’m being perfectly honest, I was once a big believer that a small, secretive side project with little management oversight and few annoying bureaucratic encumbrances was a great way to run a project and had a high chance of success. We just needed to get out of people’s way. My experience trying it a few times, and watching other people try it again and again has taught me otherwise. The ‘chaotic’ part is there, but it doesn’t pass the ‘good’ threshold for me. Done poorly, I’ve seen it wreak havoc with team morale while in the end producing no net benefit to the company or its customers.
What to do instead
Instead of treating innovation as a special case, bake it into your processes:
- Don’t bring fully-formed product designs to your team and expect them to implement what’s in the Figma or the PowerPoint.
- Have a phase at the beginning of a new initiative for experimentation where the Product Managers and Developers work together to define a solution rather than implementing one that’s been pre-decided.
- Use spikes and internal prototypes to flesh out ideas.
- If you can, ship prototype features behind feature flags to carefully chosen subsets of users to figure out what resonates and warrants more investment.
- Use hack-days or hack-weeks to let everyone scratch their various innovation itches and try out new ideas (but beware, these have a tendency to generate backlog rather than destroying it, so be careful about what you do with the outputs. Don’t just add them to the hoarder house.)
Conclusion
All in all, innovation shouldn’t be segregated off to a special team cordoned off from the rest of the org. Working on new, exciting work isn’t something everyone can do all at the same time - someone has to keep the lights on - but it’s something every team should get a chance to do from time-to-time. Spread it around and reap the rewards.
Use a tiger team for acute, time-constrained problems. But don’t mistake them for a solution to chronic issues in your org — those you have to solve the hard way
