There’s a reason Special Forces bypass traditional military hierarchy, and it’s the same reason high-performing tech teams should too.
Being French and having an interest in organizational structures and cultures, it was logical that I ended up learning about how the French military is set up. I spent time learning about how the French Special Forces operate in particular, and I realized that their organizational model had surprising similarities with a particular team model that I encountered in large organizations, bringing valuable utility.
The French Special Forces, or COS in French which stands for Commandement des Opérations Spéciales, are composed of 4,400 military personnel drawn from the various branches: ground forces, air force, navy, and some commando units. They also rotate in and out between the COS and their original army corps.
One particularity of the COS is that it doesn’t report to any army general, and instead, it is directly under the French President, who can make a military decision to deploy all or part of those 4,400 personnel whenever he feels like it to accomplish any objectives, wherever France has interests. This is also how the American and British Special Forces are set up, directly under the U.S. President and U.K. Prime Minister. This direct connection to the top of the state is necessary due to the often political nature of the missions given to special forces units, but also because it allows for quick decisions and a rapid feedback loop, and it has the extra benefit of preventing the watering down of objectives and intentions that almost always happens when something has to be passed through reporting lines.
During my time as a Senior Tech Director at adidas leading the web ecommerce channel, I led an organization through two layers of management, and I began to realize that it was nearly impossible for me to steer anything at a granular level. Managing through two layers of hierarchy felt like trying to steer a ship by whispering instructions to someone two decks below. By the time the message reached the ground, it was often diluted, misinterpreted, or just too slow. And I made the conscious decision not to go and talk directly to engineers in teams, because then I would be bypassing the chain of command and making all the managers in between feel useless, but also I would be spending too much time on operational tasks when my role required a more high-level and strategic overview.
At the same time, when I took over the organization there was an existing Web Core team consisting of 3 to 5 loose devs, who reported to various people who themselves reported to Directors under me (in a disorganized matrix fashion). This team’s scope was to own some of the central artifacts of the web channel, such as the in-house React-based JavaScript framework, and some other dependencies and integrations. I also happened to have one Principal Developer reporting to me in search of a new adventure. After thinking about different options and pitching to him the idea that I would pivot the team and that he could lead it by having all engineers report to him. He liked the idea and jump onboard, acting as Engineering Manager for the Web Core team, while still having a role of Principal Engineer and being hands-on.
And from that moment on, something changed. Suddenly, instead of waiting for alignment across layers of management or with my Product counterparts, I could rely on this Core Team as a new tool in my arsenal to directly deploy engineering power where it was needed most, and I could do it instantly because all I had to do was align with the Principal Engineer in charge. It felt like switching from a slow-moving bureaucracy to a precision strike force. The difference was night and day.
I’ve seen a similar model and structure work well at Booking.com between 2018-2020, when a VP of Tech in the Accommodation Business Unit had one Principal Developer and a team of rogue Senior Engineers reporting directly into him. They would go on and work on pure technical endeavors such as refactoring and replatforming projects, and because this team was a dedicated capacity, its work happened without impacting the delivery train of the feature teams that were more guarded by Product leadership. Whenever that team was done rebuilding a critical service, for example to improve performance at scale for a particular capability, they would then hand over the service to an existing team whose job was then to run and maintain the service, and that rogue team would go on to their next endeavor and repeat that process.
Obviously, this model makes more sense for larger tech organizations—at least 100 engineers—because if you’re running a smaller organization, you would have a hard time politically justifying spending five developers on projects that you decide on alone. And my experiences at Booking.com and adidas were for tech departments ranging from a few hundred to a thousand engineers.
And to clarify, it’s not like I was learning about French Special Forces and had an idea to create a hands-on team directly under me. I’m simply pointing out the similarities in terms of operational setup and utility across two seemingly very different contexts, the military and technology organizations. What I believe we’re witnessing is yet another occurrence of convergent evolution, this time found in organizational structure. And if we dig further back into history, I would argue that the Praetorian Guard was just another incarnation of this model.
In discussions I had with colleagues, I heard someone reference to the OCTO model, aka “Office of the CTO,” which is an engineering team reporting to a tech executive and meant to work on low hit rate and long-horizon projects. This is different from the model I described just now. If you want to learn more about OCTO, you should check out Episode 16 of the FAQS podcast in which Jason Warner, ex GitHub CTO, talks about GitHub OCTO (and you can watch these two clips (link 1 and link 2).
If you want to dig more into the history and setup of the French Special Forces, I recommend the excellent content from the Musée de l’Armée which hosted a focused exhibition on the French Special Forces in 2022, and is available on YouTube. It’s obviously in French, but you can turn on the automated translation to follow along.
Before I conclude, I want to leave you with the following: the model of having a team of dedicated engineers under a VP of Tech or Senior Tech Director isn’t just theoretical, it works. It worked at adidas and at Booking.com. It’s how the world’s most elite forces operate under extreme conditions. This is because in high-stakes environments, hierarchy kills velocity.
Insights to take away from this story:
- For high-stakes projects, minimize layers between leadership and execution where possible.
- Ensure rapid feedback loops between decision-makers and technical execution.
- Create an elite team of top engineers for high-impact, cross-team work, that reports directly to you.
- Shield feature teams from disruptive infrastructure or transient work by allocating this work to a separate unit.
- If you ever implement such a team setup, then take the time to explain all of the above to everyone in your org and among your direct stakeholders, so that everyone around you understands why it’s happening and what’s your goal with this.
Be First to Comment