Introduction
Ballistic is a mobile app that can be used to calculate the point from where parachutists should be released so that they can reach their intended Drop Zone (DZ). It is being used by the Royal Air Force (RAF) C130 Hercules fleet, and plans are afoot to roll the application out to the A400M and C17. This article tells the story about Ballistic and how our focus on empathy and a ‘problems first approach’ has shown that there are far better alternatives to how we support and generate capability for those on the front line.
People, Ideas, and technology
Ballistic’s success was not all plane sailing. It felt at times that Ballistic was put into service despite, and not because of, the development and procurement system. It is important to remember why we do what we do and grind through bureaucracy to try and improve things. We do it to give the people who make daily sacrifices and put themselves in harm’s way the proper tools and support to ensure the continued security and prosperity of the UK. As such, I’d be wasting an opportunity if I didn’t use this article as a platform to speak up about what I think needs to be done.
Part one – the story of Ballistic
Version 1 of Ballistic was built to replace the Excel spreadsheet used by C130J aircrew to calculate an average wind vector that would be entered into the aircraft’s mission computer that would, in turn, generate a release point – the place in the sky where we turn on the green light and say ‘get out of the plane!’. The spreadsheet had a poor user interface and was difficult to manipulate. Ballistic simplified the process, meaning the pilots could concentrate on critical mission and safety tasks. We were so proud of Ballistic that we made this promotional video about it.
Ballistic Version 2 built on this idea and took more manual calculations away from the pilots. We fitted a function to the so-called ‘gross error check’ data in this case. The idea behind the gross error check is to ensure that no gross errors have been made in transposing information into the aircraft mission computer. The theory goes that if I’ve entered all the numbers correctly, the answer I get from the mission computer (in the form of a range and bearing from the DZ) should roughly equate to a pre-computed solution under similar conditions. So the pilot would enter the wind vector into the aircraft, and the mission computer calculated the release point. Then I would check this release point against some other independent data.
Operating, checking and interpolating
The problem came when we looked at how this gross error check was done. For example, we’re dropping from 13,500ft above ground level (AGL), and the average windspeed was 17 knots. I’d then have to get out my paper copy operations manual and find the page for the gross error check data for the parachute type. Since the height rows are presented in 2,000ft increments and the wind speed in 10-knot increments, I’d have to interpolate between four cells. All whilst operating an aircraft.
Generally, this would be a job for the non-handling pilot, so flying the aircraft would be taken care of. However, navigation, communication and mission management still needs to happen. Parachuting sorties can be busy, so we fitted a function to the gross error check data to be added to Ballistic. The answer will be presented instantly to the pilot.
Why didn’t we use ‘the system’?
You may be wondering why this took the efforts of two junior officers to make an app. Surely the aircraft or procedures should be designed better? Is this not the job of Defence Equipment & Support (DE&S) or Defence Digital, two of the Ministry of Defence’s Enabling Organisations? Where was the ‘requirement’ (more on my least favourite word later)?
The fact is that a problem needed solving for our mates on the front line, so we solved it. Coding the app was by far the most enjoyable part of this, and it took us only six weeks between our first meeting and having something we could put into the hands of users to generate value. But working out the minimum pipeline to deploy and approve Ballistic for use took months of graft.
Challenging bureaucracy and process to lay this foundation were complex, and we still have many improvements. Fantastic support from Astra Appivate and the Air & Space Warfare Centre means we now have a path to deploy software onto Electronic Flight Bags (EFB) of aircrew on the front line. This preparation put us in excellent stead when we were asked whether Ballistic could be made to generate the release point entirely within the app, independent of the C130J mission computer.
Ballistic beyond the Hercules
The UK C130J is due to go out of service with the RAF at the end of June 2023, with the A400M planned to pick up much of the load (literally) and – in time – a capability which the C130 fleet has carried in recent decades. As of today, the A400M mission computer cannot generate a release point that is flexible enough to support high-altitude parachuting tactics. There are plans afoot for the A400M mission computer to be upgraded. Still, lead times and competing priorities will likely mean that the upgraded software won’t be installed across the entire UK fleet for months, if not years, after the C130J leaves service.
Similarly, the UK C17 can only generate a flexible release point by carrying an additional crew member. Although this makes high altitude technically possible on the C17, it completely ignores the global pilot shortage, let alone the years of training and experience required to be safe and competent in the airdrop discipline. Adding another pilot onto the flight deck for every new task is not a sustainable way of doing business.
Ballistic V3.0
Here is where Ballistic V3 enters into the equation. Since we’d already worked out the deployment pipeline, we could encode the release point calculations defined in the USAF Manual 11-231. We were also working with UK test pilots conducting trial activity in the US, which meant we could rapidly integrate these calculations into the app from the UK. In June 2022, Ballistic V3 was approved as an aircraft-agnostic release point calculator. The app isn’t the be-all and end-all for high-altitude parachuting. But I can confidently say that it has played no small part in ensuring that the UK doesn’t have a capability gap once the C130J goes out of service.
We also believe Ballistic is more than just a sticking plaster. Ballistic decouples the release point calculation from the aircraft being flown – C130J, A400M, C17, Chinook, Dakota, Skyvan, MV-22, etc. This means the Duty Holder (the individual legally responsible if things go wrong) has a much clearer understanding of the risk they own. It also means all operators (aircrew, parachute jump instructors, and troops) can all use the same tool and speak the same language, making for more effortless knowledge transfer and slicker mission planning and execution.
That’s all, Folks!
What’s written so far isn’t meant to persuade you that the problems we’ve solved needed solving. We’ve ensured that we are constantly validating our assumptions to ensure this is the case. We must have got something right, not because RAF Digital, Appivate, and our industry partners are now providing some incredible support so that Dan and I are no longer critical dependencies on this capability, but because the people who use Ballistic tell us so. And if anything needs changing, fixing, or improving in the app, we do it. As such, the remainder of this article isn’t about Ballistic or high-altitude parachuting; it’s about the lessons we’ve learnt along the way.
Part two – the problem first approach (and why more of the same just isn’t good enough)
The development of Ballistic has proved that it need not take years nor cost millions of pounds to put world-leading capability into the hands of those on the front line. It is primarily acknowledged that wars of the not-too-distant future will be won just as much by algorithms, software, and data as opposed as they are people and hardware. Many observers have already commented that software has played a vital role in the heroic defence of Ukraine.
It still felt like developing a mobile app for an EFB was seen as a niche activity or a pet project rather than what it should be; a core business. Perhaps there’s an element of my own insecurity peaking through here or my over-protectionism over something I’ve invested so much into, but something has to give. What will it take to address the conclusions of the many National Audit Office reports into UK Defence spending and capability development in a meaningful way?
Empathy, not requirements
I suggest that those developing capabilities focus on empathy, not requirements. Only by truly understanding the problems that front-line operators face can we hope to solve them at the pace of relevance. The alternative – the current status quo – focuses on delivering on ‘requirements’ and maintaining processes, regardless of the outcome. This situation leads to us blindly pushing on with solutions that don’t necessarily solve a problem. We assume that the reductionist approach of breaking a project down into its constituent parts, dishing tasks out to various Delivery Teams and recombining them will consistently deliver the best results. This may be the case for a static world where nothing changes, plans may be meticulously executed, and exquisite capability may be delivered on time and on budget. Still, we do not live in a static world.
Keeping up with change
As the rate of change of almost everything in our world continues to accelerate, whether it be technology, the climate, geopolitics, or society, we can rest assured that as soon as a requirement is written, it almost instantly becomes out-of-date. Yet, that set of requirements will get pushed through the system. People still work extremely hard to make things work, both for their own careers and because they believe it is the right thing to do. This is done without any frame of reference as to whether what they are working on will make a difference, so how should we expect anything to change?
This is why much more of a focus should be given to empathy, constantly trying to understand the actual problems they are trying to solve. Doing so offers people working on capability a yardstick to measure their efforts. If someone can ask themselves the following three questions and answer positively, they should crack on. If not, something needs to change:
- Do I understand the problem I am trying to solve?
- Does the proposed solution solve this problem
- Does what I’m working on help to solve the problem in a meaningful way?
Think big, start small, and iterate fast
Taking a ‘problems first approach’ isn’t a particularly groundbreaking insight. It’s something that I learned from my experience with the Hacking for MOD (H4MOD) programme, where MOD staff can – free of charge to your unit – enrol the assistance of a team of postgraduate students to help understand and define and understand problems they are experiencing before grasping for solutions. The approach practised throughout the H4MOD module is the Lean Startup Methodology: think big, start small, and iterate fast (not the official definition, but my own).
The minimum viable product
By practising empathy, user researchers can put themselves in the shoes of others to truly understand their problems and develop a Minimum Viable Product (MVP). There is no globally recognised definition of an MVP, but for me, it is the smallest possible thing that can be put into a user’s hands, which will generate value or feedback. If the MVP creates value, then great! You’re already solving someone’s problem. If it creates feedback, that’s also good since that feedback can be used to continuously validate and iterate potential solutions or even kill an idea before it becomes too big to fail.
Don’t get me wrong; some incredible people work across the MOD who do precisely what I’m proposing and more. But from my recent lived experience on the front line, it certainly did not seem like any user research was rigorously, continuously and consistently gathered from those who understand many of the problems that need solving better than anyone else. I also understand that what I’ve just said may be a lot easier said than done, but I also know that it’s not only possible but that this approach can deliver outstanding results. Before we propose how we might engender a strong habit of empathy to alter the course of the behemoth that is defence capability development, we should first look at some of the reasons why this might be difficult.
Optimism and cynicism – we’re only human, after all.
There is something in the combination of recruiting, training and experience that does strange things to people in the RAF. We expose our people to incredible opportunities and challenges, which can often be overwhelming. As a result of our limited cognitive and emotional bandwidth (note here that I’m not suggesting people in the RAF specifically have a limited mental or emotional bandwidth, more than all human beings do!), we respond by developing an odd combination of unrealistic optimism and extreme cynicism. One might argue that cautious optimism, combined with careful scepticism, is the very bedrock of the scientific method and human progress. Still, in extreme doses, either can be very dangerous for individuals and the organisations they are part of.
And of the people who exhibit these traits, who do you think gets promoted to the top of our organisations and then go on to make decisions on capability spending? It would hardly be inspirational for our leaders to walk into the room and pronounce, ‘Team, everything is rubbish…’. Again, this isn’t a groundbreaking insight, and anyone familiar with Blackadder will recognise the blind optimism in General Melchett.
‘If nothing else works, a total pig-headed unwillingness to look facts in the face will see us THROUGH’
General SIR ANTHONY CECIL HOGMANAY MELCHETT
A symptom of reasonably strong cynicism can be found in some of the tweets of @NextGenRAF and the Instagram posts of disastra_memes. I find these hilarious, probably because they remind me that when I’m banging my head against a brick wall trying to complete some nonsensical task or trying to work out why I’m being taught how to read a grid reference on a map in a freezing cold lecture theatre (for the tenth year in a row), I’m not on my own; my comrades share my pain.
Listening to the lived experience
I also recognise that their effect can be highly polarising. On the one hand, we have senior leaders talking about how wonderful the future might be; on the other, we have the lived experience on the front line. If those on the front line do not feel like their voices are being listened to, they will be far less likely to articulate the problems they are experiencing and will crack on with what they have to look after themselves and those in their immediate peer group.
My point is that polarisation is an emergent property of social behaviour, and when we’re put under pressure, we respond in different ways. General Melchett and @NextGenRAF aren’t real people, but we must take stock and listen to what they say, as they represent how different parts of our organisation can be perceived. Nobody wakes up and wonders, ‘ how can I make things difficult for other people in my organisation today?’ It feels like that sometimes. Regarding capability development, we’ve ended up in a situation where polarisation has made it very difficult to empathise; that is, it becomes challenging for those who have the power to solve our problems to understand them in the first place.
Progress over process
Organisationally, we need to catch up with the rate of technological change. We have plenty of incredible people scattered around the RAF who are some of the best in the world at what they do. Regarding capability, putting the right people in the right place seems hampered by our rigid hierarchy. We have very little control over how our Enabling Organisations conduct their business. This isn’t personal; it is systematic. But without the right people in the right place or data to base decisions upon, we resort to ‘intuition’ or only have ‘military judgement’ to fall back on.
Enter the HiPPO
Creativity is essential in warfare, but more often than not, in a wicked environment, experience counts for very little. Without data to base decisions upon, we might as well be guessing. To make matters worse, the language of capability development, procurement, and acquisition is so impenetrable that it takes talented people months or even years to understand what is happening around them, let alone develop an understanding of a problem set and deliver solutions. As a result, we fall back on the Highest Paid Person’s Opinion and inappropriately cram everything into processes that aren’t keeping pace with the rate of technological change. We desperately need to acknowledge that processes, policy and even regulations are how we achieve national security, not the ends themselves. If processes hinder progress, we should ruthlessly cut out unnecessary and wasteful steps or entire processes.
Over-regulation
We might expect a reaction to the suggestion of deregulation and removing processes to be one of indignation, and we might hear cries of ‘we need to be seen to be doing something!’. But history tells us that doing things to make us feel safer doesn’t lower the probability or lessen the consequences of an event. Perhaps one of the most significant, most often cited examples of this phenomenon in history is that of the Maginot Line. The construction of the Maginot Line was approved to span the eastern border of France with Germany to deter German aggression. In 1939, its construction was complete, and in 1940, the German army drove around it, through Belgium and into Northern France, where fortifications were much weaker.
The safety net of regulations and processes?
The French government was persuaded to invest 3 billion French francs (~$3.9 billion in today’s money) to do something that proved ineffective based on a feeling of security. As the French were static and inflexible, the Germans developed Blitzkrieg to defeat their adversary easily. Had the French government adequately understood the problem they were faced with and invested in a more flexible, decentralised and manoeuvrable force which posed multiple dilemmas for Hitler, then this may have delayed invasion or even significantly altered the events leading up to WWII. We are chasing theoretical ‘what if?’ questions here, but the point is that regulations, processes and projects that make us feel safe don’t necessarily reduce risk.
We must effectively gather feedback and data to measure, analyse and manage risk to make effective judgements and justify our decisions. Once again, in our wicked world, the alternative is that we are just guessing in the dark, and it is likely that we will put up ineffective barriers in places where our attention would be better focused elsewhere.
PART 3 – a way ahead
The previous section was a bit doom and gloom, but I’ll suggest how to move forward. Before diving back in, let’s look at an overview of what we’ve covered so far. Through Ballistic, we’ve shown that it’s possible to put world-leading capability into the hands of those on the front line, which need not cost millions or take years to develop. I’ve suggested that this was made possible only by truly understanding the problem we were trying to solve and have outlined some of the critical sources of friction we’ve experienced. To round up, I’ll discuss some practical advice on how we might scale the success of Ballistic to other areas of defence capability development.
Closing the gap
To develop empathy and proper understanding with those on the front line, our key proposal is to close the gap between developers and front-line operators. Whether it be physical, cultural or organisational, it is clear that proximity to a problem is critical to achieving a good product-market fit. By pushing developers of capability closer to the front line and physically sitting them down next to those who fly, fight and support, they will inevitably develop a deep understanding of the problems they are trying to solve.
By closing the gap, it will be far easier to garner feedback and validate whether a potential solution being developed will solve a problem being experienced. If not, the solution can be adjusted or scrapped altogether before becoming too big to fail.
Acting on continuous feedback
Closing the gap between developers and operators to gather continuous and honest feedback on capability should be done actively and by default, not passively or by exception. There are many ways in which feedback could be garnered; interviews, group conversations, debriefing, surveys, etc., but regardless of the mechanism by which feedback is gathered, it needs to be done continuously, honestly, and it needs to be acted upon. When feedback is acted upon, this might not be through implementing a specific suggestion but should at least explain why an idea might not be the best solution to a problem. If someone engages with this process and receives no feedback, they will likely become disenfranchised with the process and not wish to waste their own time providing feedback in the future.
The onus on closing the gap should be placed mainly on those developing capabilities, but front-line operators also have a vital role. If problems are not articulated clearly by those on the front line, we should not expect them to be magically solved.
‘If you CAN’T measure it, you CAN’T manage it.’ PETER DRUCKER
Data – tedious but vital
Front-line feedback is a special form of data on base decisions, but not the only significant source. It seems painfully apparent to type this out, but I think it’s necessary to state it explicitly. Our findings should be based on objective data that is continuously gathered rather than subjective opinion or anecdotal evidence. To do this, the RAF and MOD must build and own their data pipelines and understand what modern data management looks like (this means more than completing the banal Defence Information Management Passport DLE training). It does not mean that we should pay a consultancy firm to take a snapshot of the current state of affairs to base all subsequent decisions, albeit it’s likely that consultancies will be very useful in helping us to build these pipelines in the first place.
Let’s look at a typical example of this in practice: providing adequate service accommodation. Everybody knows that safe shelter and hot water in service accommodation are fundamental in supporting our people and fulfilling the foundation of Maslow’s hierarchy of needs. However, it doesn’t seem as if anyone clearly understands the extent of the issues plaguing our ageing infrastructure, nor does anyone propose an acceptable solution to resolve it.
DIO, data and warm showers?
If we can’t guarantee a hot shower for those we entrust to engineer, support and operate our exquisite capabilities, how can we expect to recruit and retain the best talent? I dare say that DIO is looking into this issue – and has probably been doing so for years – but without a continuous stream of data reporting the performance of boilers, central heating systems and showers across the estate, how could anyone possibly be expected to make decisions on where to fund improvements, explain priorities and argue for further investment? It would be like going to the bank to ask for a loan and answering the question ‘what are you planning on spending the money on?’ with ‘I don’t know’.
We’re not discussing novel or emerging technology that will lead to victory in a peer-on-peer state conflict. Still, if we can’t get data management right here, I don’t imagine we’ll fare too well when it comes to version control of the weights of a neural network used to make or inform some decision in the kill chain. This is my point if you’re involved in capability development and don’t know what the previous sentence means. Data management is tedious and challenging, but it’s impossible to overstate its importance when making decisions about capability development.
Insourcing and Entrepreneurship for Digital
As we enter the spring of 2023, the lines between the real and virtual worlds become increasingly blurred. Actions in one can profoundly impact the other, and we should expect to see more weird and wonderful emergent phenomena as this blurring inevitably continues throughout this decade. One such phenomenon is the power and influences that individuals and small groups with the right combination of skills, tools and enthusiasm can exert on the world. Regarding military capability, the current state of affairs starkly contrasts the dynamics of the 20th century, in which power and influence were primarily held by companies that owned equipment and intellectual property to build planes, tanks, weapons and ammunition.
We find ourselves in a time where any military person that understands the problems they are experiencing better than anyone else can solve many of them by writing software and need not rely on the procurement and acquisition process for everything. When physically building stuff at scale, we need to leverage industrial power. However, this need not exclusively be the case regarding digital capabilities, where more nuanced combinations of military-industrial teams might be possible and even desirable. I’ve made a case for closing the gap between developers and front-line operators, but if these two roles can be identical, all the better! This is precisely how Ballistic came into being and, in my humble opinion, how it became a success.
Upskilling our people
Over 3000 people have completed the JHubCoding Scheme set up in 2019 to financially incentivise military personnel and civil servants in the MOD to learn to code. The RAF has also established the Future Chief of the Air Staff Fellowships to fund masters level education in subjects such as Data Science, Artificial Intelligence, Cyber Security and Sustainability. These are two examples of how we are upskilling our people meaningfully, but the framework doesn’t yet exist to employ these people gainfully.
There have been some truly heroic efforts to establish organic software development capabilities and professionalise this activity. Still, to unlock our people’s true potential, we need to throw away some of our archaic thinking and, with it, some of our ideas around rank, position and experience. If you ask a group of people how they became coders, no two people will give you the same answer. This is because the digital, data and technology field is so vast and fast-moving that people develop the technical skills they need to work on the projects they are involved with at the time. The work being led by RAF Digital to professionalise organic digital, data and technology development in the RAF is an opportunity that we cannot afford to delay.
Summary
With spring upon us, we should take the opportunity to consider new beginnings. If we spend more time nurturing or fighting the system instead of delivering value to the people who make daily sacrifices and put themselves in harm’s way, then perhaps we’re doing something wrong. I think we are getting this wrong in a lot of ways. But I’m also optimistic that by being brave, throwing away outdated thinking, and closing the gap between developers and front-line operators, we stand a good chance of accelerating how we develop a capability to the pace of relevance.
Endnote
The Ballistic Team, Peter Kennedy and Dan Leedham were awarded a team commendation from the Royal Air Force Deputy Commander Operations in the RAF New Year Honours and Awards 2023.
Peter Kennedy
Peter is a Royal Air Force C130 Hercules pilot