SWAT (Special Weapons and Tactics) teams are highly specialized police teams that are often called in the most difficult situations. They’re an uniquely trained and cohesive team that’s highly performant in short and dangerous situations.
In my career as a software developer in big companies and CTO in several startups, I have been part of the SWAT equivalent in the software world: The Advanced Development team.
Most software developers like to be part of these teams every now and then. They often work on very interesting new problems using new technologies that have the potential to significantly improve the business they’re in.
These teams are great at thinking outside the box, looking at problems from different angles, extremely flexible in adapting to changes and learnings from users and customers. They understand the business assumptions that need to be tested and create products or features quickly to get them tested. While their experience does force them to think about a possible future scale, this is not their main priority.
Any company hoping to innovate needs to have access to this type of structure in their team. However, it’s not always easy or feasible to gather or keep this group of people around for the next time you need to do an innovation push.
The goal is to create something good enough that can help validate business or technical needs and assumptions. Often this requires a few iterations with multiple contact points with users. Often the team works with the product owner to refine the needs and revisit assumptions after each iteration.
Products and features can’t constantly be in innovation mode. At some point, when an experiment works, it needs to be perfected, optimized, and maintained. This is not the purpose of an AD Team. While the product or feature moves to transition, transitioning the team is not always a good idea.
In most cases, these are small teams (3-5 members) that know each other well, are curious, multidisciplinary, and experienced. Most team members can work pretty independently and are able to adapt to changing circumstances very quickly.
Usually there’s a tech lead that can help lead decisions around which tech stack to use, what gets built and what doesn’t and high level architecture decisions on how the parts fit together.
The team is usually very independent, getting only very high level business needs and assumptions to be tested from the product owners.
AD work is often a bit chaotic as it’s ever changing with moving goal posts and it has an irregular cadence. You can’t structure it in 2-week sprints and a flexible Kanban board is a much better way to manage it.
The earlier a startup is, the more their team needs to be an AD Team. At the beginning of the startup journey, they’re in a race against time (i.e. diminishing runway) to validate as many assumptions as possible. Some of these assumptions are technical (i.e would this work?) and some are business (i.e. would anybody pay for this?)
As the startups successfully validate them, they will start to spin up more traditional development teams to optimize and maintain their already proven products.
It’s common in a more mature startup to see some features in AD mode and some in maintenance mode. The more the product matures, the less AD is needed.
But wait! A company should never stop innovating…
Companies with successful optimized products need to constantly be watching their back for small nibbler companies that attempt to disrupt their markets. An AD Team that experiments in adjacent areas or even completely new ones is perfect to keep their business from fossilizing.
The experiment could be a new feature of an existing product (i.e. add an SDK for 3rd party developers), a companion product (i.e. a mobile app) or a completely new product category.
It’s very difficult to source your AD Team from inside your existing team working in your current product for several reasons:
This is why it is a great idea to source your AD Team from a software development consultancy. Like SWAT teams, these teams have worked together and go from challenge to challenge bringing with them mounts of experience that your company will immediately benefit from.
While not impossible, building this work dynamic and keeping it running inside a product company is very very difficult as the needs of your business will inevitably transition between modes of working.
At Nieve, we have been parts of product startups, big companies and have participated in many AD type projects. We’re passionate about designing and creating software experiments and MVPs to help you validate your assumptions and clear the innovation road for you. Let’s get in touch!