Code like Commandos.
What software engineers can learn from submariners and special forces.
At first glance there might not seem be a lot of similarities, but some recent reading has thrown up some very important parallels between how we go about our business, and how some of the most elite war-fighters go about theirs.
Jottnar is a young British company that has made an immediate impact on the outdoor clothing industry, making exceptionally highly-regarded mountaineering clothing. They’ve only been going a few years, but their gear has already become essential kit for professional climbers, Alpine guides and mountain rescue services.
The two founders are ex Royal Marine Commandos and in a recent blog post they reflected on the lessons they learned starting a company from scratch, and how that compared to their military training.
Transferable skills are transferable
“Tommy and I came from the Marines knowing how to plan and execute. We could set a vision, align ends, ways and means, measure everything appropriately and then communicate our ideas reasonably clearly. We also knew that mission success, properly defined, is going to feel the same everywhere.”
Most our clients have told us that the clinching factor in awarding us work has been the strength of our process, as much as our expertise with any given technology. Knowing how to plan and execute a project is an essential foundation we share, and like the Commandos we train our teams to learn and improve from every sortie. Measuring everything appropriately – and testing everything with rigour – is also a fundamental part of our Agile process.
Commandos draw lines of advancement, and constantly assess their progress towards their final objective. When they get to each point they assess they success and review the best way to get to the next point. If the planned way ahead is still viable they push on with the plan to the next line, but if not, they regroup and make another plan to get to where they need to go.
We build applications the same way, incrementally, building workable software on successful sprints and adapting and adjusting as we progress.
Jottnar founder Steve also explained that “The Marines demanded we be both jacks-of-all-trades and unusually masters of them too. They employed us across all sorts of areas, changing us in our roles every two years. This demanded super quick reorientation and learning of new things in order to be effective.”
But what we say first and foremost is “the right ones for your project.”
Whilst that obviously means that you don’t bring a knife to a gunfight, the more important point is that with experience comes expertise. We start by making sure that we understand the project, both in terms of business objectives and resources, and in terms of the technical landscape in which the application is going to have to work.
Royal Marines are trained to use everything from fighting knives to artillery, so that when the time comes they can quickly employ the right tools. Whilst not every Marine might be an expert in explosives, there will be someone in the Troop who is. They are not just trained to understand the finer principles of blowing things up well, but more importantly, they are trained how to judge when it’s right to blow it up, or when to silently take it out.
Likewise, we hire developers who not only have deep expertise in specific technologies, but who understand the wider principles of engineering and problem-solving. That essential mindset means that we can learn, and use, both emerging platforms and legacy systems with speed and clarity.
There is no right way
Steve admits that, “I wasted mental energy looking for the ‘right way’ in the early days, as if there were a doctrinally ordained aspect to it. ….The Marines don’t ask you to work like that. So how do we now choose the (possibly) optimal way? By being conscientious, by making defendable assumptions, by postponing decisions until we have to make them (a tricky art but it allows more data to accrue), and by making our short-term actions align with our long-term objectives. The Marines do ask you to work like that.”
And of course we ask our teams to work like that too. Aligning short-term sprints with long-term objectives is one of the keys to Agile development, as is learning from the data and test results you accrue along the way.
“Hire good people, give them the right tools and training, then get out of their way,” is one of those maxims beloved of management consultants, probably unwittingly, because it’s how special forces teams operate too. The officers set objectives and the NCOs plan and execute the mission. But that takes a structured environment where everyone understands the objectives, has the tools and training required, and the confidence – instilled in them by management – to use their skills to get the job done.
USS santa Fe
“Don’t move information to authority, move authority to the information.”
In his excellent book, Turn The Ship Around, David Marquet tells how he honed this idea because he didn’t know what he was doing. He spent a year training to take command of USS Olympia, an American nuclear submarine, only to be told two weeks before that he was now going to USS Santa Fe – a completely different submarine.
Naval command was based on the Captain giving orders for everything and the crew doing what they were told, but Marquet found himself having to redefine his leadership because he didn’t know the vital specifics of how the boat operated. From this he developed the idea of ‘intent based leadership’ – allowing the crew to decide what was the right thing to do, and allowing himself simply to be the safety net checking that their actions were both safe and aligned with the objectives.
The teams doing the work always have more information than management, so he gave them the authority to use that information to determine the best course of action. Rather than ordering the engineers to change oil filters, he let them choose the best time to do that noisy job (i.e. not when the sub was running silent in attack).
Marquet quickly found that giving his crew this power created a tightly-focussed team of leaders rather than followers. Individuals were not just encouraged, but forced to think everything through methodically, and take command of their actions. People got the right things done without waiting to be given an order.
The twin pillars of his Intent Based Leadership are ‘Competence and Clarity. To empower the crew to make the right decisions took organisational clarity and technical competence, and that’s how we structure our projects too.
Well trained developers, working to a clear brief, have the freedom to make the right decisions with minimal management scrutiny. It’s not a free for all; it’s a very tightly run exercise, but when skillful teams know what they are doing and why, they have the ability to use their expertise and experience to get the work done faster, better and often with a degree of innovation that a more prescriptive regime would forbid.
Create the environment for thinking
Marquet’s new leadership style not took the Santa Fe from worst in the fleet to best, but it revolutionised the way the US Submarine force trained its Commanders too.
Both the Royal Marines and American submariners create an environment where their Troops and crews must be thinkers and not followers. Brute force is their ultimate tool, but as Archimedes’ levers proved, force only works if you apply it with intelligence and expertise.
These principles can be applied to any organisation or business, but as Marquet points out, it took time to establish an environment where his crew felt safe using their brains independently. You can’t switch it on overnight.
At Dootrix we hope we’ve created a thinking environment, by continually refining our processes, learning from failures and successes, and by building a culture of constant independent learning. We set tight, objective driven frameworks and then give our designers and developers the freedom to lead the way.
Subscribe to our newsletter for free advice delivered to your inbox on a fortnightly basis.
Agile perspectives: the planning meeting
As a scrum master, I am usually asked all kind of questions about agile as a methodology. Some people explain to me why agile doesn’t really exist and […]