Overhauling defence capability, one app at a time

31 December 2022

The UK MOD’s approach to capability development requires an urgent and comprehensive overhaul. We need to equip those who make daily sacrifices and who put themselves in harms way with the right tools and support; to ensure the continued security and prosperity of the UK. Ballistic - a mobile application developed by and for front line operators - gives us a glimpse of what the future might look like. This article has been written by Peter Kennedy, a current serving RAF officer. All opinions are his own.

“People, ideas and things, in that order.” Col John Boyd

I’m thrilled to announce that Dan Leedham and I have been awarded a commendation from the Royal Air Force Deputy Commander Operations in the RAF New Year Honours and Awards 2023! We’ve been awarded this commendation for creating a mobile app called Ballistic. On the face of it, the idea is very simple; a mobile app that can be used to calculate where parachutists should be released from, so they can reach their intended Drop Zone (DZ). But if that really was the beginning and end of the story, I very much doubt one of the most senior officers in the Royal Air Force would take time out of his day to recognise two young(ish) officer nerds.

It feels a little self-aggrandising to write this article off of the back of a commendation, but then I remember why we do what we do, and why we grind through bureaucracy to try and make things better. We do it to give the people who make daily sacrifices and put themselves in harms 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 commendation as a platform to speak up about what I think needs to be done.

This article tells the story about Ballistic, and how our dogged focus on a ‘problems first approach' has shown that there are far better alternatives to the current way which we support and generate capability for those on the front line.

The story of Ballistic

Version 1 of Ballistic was built to replace the excel spreadsheet that was in use for C130J aircrew to calculate an average wind vector so that less time and capacity would be spent on manipulating a spreadsheet with a poor user interface, and so that the pilots could concentrate on mission and safety critical tasks (we were so proud of it, we made this little promotional video about it). Once calculated, this average wind vector would be entered into the aircraft mission computer which in turn would generate the release point; the place in the sky where we turn on the green light and say “get out of the plane!”.

Version 2 built on this idea and took more of the manual calculations away from the pilots. In this case, we fitted a function to so called ‘gross error check’ data. The idea behind the gross error check is to - unsurprisingly - check that no gross errors had been made in transposing information into the aircraft mission computer. The theory goes, that if I’ve entered all of the numbers correctly, then the answer I get from the mission computer (in the form of a range and bearing from the DZ) should roughly equate to a precomputed answer under similar conditions. So the pilot would enter the wind vector into the aircraft, the aircraft calculates the release point, then I check this release point against some other independent data. The problem comes when we look at how this gross error check was being done. Say 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, find the page for the gross error check data for the parachute type I’m dropping, then since the height rows are presented in 2000' increments, and the windspeed in 10 knot increments, I’d have to interpolate between four cells. Let’s not forget that if you were doing this for real, you would be operating an aircraft. Generally this would be a job for the non-handling pilot, so flying the aircraft would be taken care of, but navigation, communication and mission management still need taking care of. Needless to say, parachuting sorties can be quite busy, and this is why we fitted a function to the gross error check data, so it could be added to Ballistic and the answer be presented instantly to the pilot.

At this point, you might 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 for Defence Equipment & Support (DE&S) or Defence Digital, two of the Ministry of Defence’s (MOD) Enabling Organisations? Where was the ‘requirement’ (more on my least favourite word later in this article)? The fact of the matter 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 6 weeks between meeting, and having something we could put into the hands of users to generate value. But working out the minimum but sufficient pipeline to deploy, and approve Ballistic for use took months of graft. Challenging bureaucracy and process to lay this foundation was difficult, and we’ve still got lots of improvements to make, but with some fantastic support from James Palfrey MBE and Luke Flemington DFC BAv MSc along the way, we now have a path to deploy software onto Electronic Flight Bags (EFB) of aircrew on the front line and so we can adapt and iterate quickly. This preparation put us in very good 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…

The UK C130J is due to go out of service with the RAF at the end of July 2023 with the A400M planned to pick up much of the load (literally) and - in time - capability which the C130 fleet has carried in recent decades. As of today, the A400M mission computer is incapable of generating a release point which is flexible enough to support modern high altitude parachuting tactics. There are plans afoot for the A400M mission computer to be upgraded, but the lead times and competing priorities will likely mean that the upgraded software isn’t installed across the entire UK fleet for many months, if not years after the C130J leaves Service. Similarly, the UK C17 is also unable to generate a flexible release point without 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.

Here is where Ballistic V3 enters into the equation. Since we’d already worked out the deployment pipeline, we were able to encode the release point calculations defined in the USAF Manual 11-231 and working with Andy Carter out in the US, we could rapidly integrate these calculations into the app from the UK. To cut a very long story short, in June 2022 Ballistic V3 was approved for use as an aircraft agnostic release point calculator. The app isn’t the be all and end all when it comes to high altitude parachuting, but I can say with confidence that it has played no small part in ensuring that the UK doesn’t have a capability gap while the A400M mission computer plays catch up. Not only this, but we see Ballistic as more than a sticking plaster solution. By decoupling the release point calculation from the aircraft, it does not matter what aircraft we’re dispatching from (C130J, A400M, C17, Chinook, Dakota, Skyvan, MV-22, etc), the duty holder (the person who is legally responsible if things go wrong) stands half a chance of understanding the risk they are owning and all operators (aircrew, parachute jump instructors and troops) can all use the same tool and speak the same language, making for easier knowledge transfer and slicker mission planning and execution.

What’s written so far isn’t meant to persuade you that the problems we’ve solved needed solving. We’ve made sure that we are constantly validating our assumptions along the way to ensure this is the case. We must have got something right, not because RAF Digital are now providing support so that Dan and I are no longer critical dependencies on this capability, and so it can be supported by the organisation. We know we’re getting it right because the people who use Ballistic tell us so. And if there’s anything that needs changing, fixing or improving in the app, we do it. As such, the remainder of this article isn’t really about Ballistic, or high altitude parachuting, but it’s about the lessons we’ve learnt along the way that we think it’s imperative for our Enabling Organisations to learn if they wish to truely support those who fly and fight on the front line.

If you came here to read about the story of Ballistic, then you’re pretty much up to speed! There’s a few more details and if you would like to discuss high altitude parachuting and mobile app development in more depth, then please feel free to reach out and message me on LinkedIn. However, if you’re not yet satisfied, and would like to engage in a professional conversation about how the MOD turns taxpayers money into security, then please read on.

Problems first approach

More of the same isn’t good enough

Through the development of Ballistic, we have proven 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 largely acknowledged that wars of the not too distant future will be won by algorithms, software and data as opposed to hardware alone. In fact, it is argued that software has played a key role in the heroic defence of Ukraine already. But it still feels like developing a mobile app for an EFB is seen as niche activity, or as a pet project and not what it should be; core business. Perhaps there’s an element of my own insecurity peaking through here, or my overprotectionism over something I’ve invested so much in to, 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

My suggestion is for those developing capability to focus on empathy, not requirements. Only by truly understanding the problems that front line operators face can we have any hope of solving them at the pace of relevance. The alternative - that is, the current status quo - is that focus is given to 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 deliver the best results. This may well be the case for a static world where nothing changes, where plans may be meticulously executed and exquisite capability may be delivered on time and on budget. But clearly we do not live in a static world. As the rate of change of almost everything in our world continues to accelerate, whether it be technology, the climate, geopolitics, and society, we can rest assured that as soon as a requirement is written, it almost instantly becomes out of date. Yet still, requirements 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 actually make a difference, so how should we expect anything to change. This is why I believe much more of a focus should be given to empathy. To constantly seek understanding of the actual problems that we are trying to solve. By doing so, this offers people working on capability a yardstick to measure their efforts against. If someone can ask themselves the following 3 questions, and answer positively, then they should crack on. If not, something needs to change.

1. Do I understand the problem I am trying to solve?
2. Does the proposed solution solve this problem?
3. Does what I’m working on help to solve the problem in a meaningful way?

The idea of taking a ‘problems first approach’ isn’t a particularly groundbreaking insight. In fact, 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 practiced throughout the H4MOD module is the Lean Startup Methodology; that is, think big, start small, iterate fast (not the official definition, but my own). By practicing empathy, user researchers are able to put themselves in the shoes of others to truely understand their problems and develop a Minimum Viable Product (MVP). There is no globally recognised definition of what an MVP is, but for me, it is the smallest possible thing that can be put into the hands of a user which will generate value or feedback. If the MVP generates value, then great! You’re already solving someone’s problem. If it generates feedback, then that’s also good, since that feedback can be used to continuously validate and iterate potential solutions, or potentially even kill an idea before it becomes too big to fail.

Don’t get me wrong, I know there are some incredible people who work across the MOD and do exactly 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 being 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 exponential 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.

Friction

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 some 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 cognitive or emotional bandwidth, more that 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 itself, but 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 make decisions on capability spending? It would hardly be inspirational for our leaders to walk into the room and pronounce "Lads, everything is rubbish...". Again, this isn’t a groundbreaking insight, and anyone familiar with Blackadder will recognise the blind optimism in General Melchett played by Stephen Fry.

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 absolutely 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. But 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, and 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 just crack on with what they have to look after themselves and those in their immediate peer group.

My point here is that polariastion 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. I don’t think anybody wakes up and wonders “how can I make things difficult for other people in my own organisation today?”, it just feels like that sometimes. When it comes to capability development, we’ve ended up in a situation where polarisation has made it very difficult to empathise; that is, it becomes very difficult for those who have the power to solve our problems to actually understand them in the first place.

Progress over process

Organisationally, we are failing to keep pace with the rate of change of technology. We have plenty of incredible people scattered around the RAF who are some of the best in the world at what they do, but when it comes to capability, because of our large, rigid hierarchy and because we have very little control over how our Enabling Orgnisations conduct their business, it’s almost impossible to put the right people in the right place to make the right decisions. Without the right people in the right place, or data to base decisions upon, we resort to ‘intuition’ or so called ‘military judgement’. In a wicked environment, experience counts for very little and 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 going on around them, let alone develop an understanding of a problem set and deliver solutions. As a result, we fall back to the Highest Paid Persons Opinion (HiPPO) and inappropriately cram everything into processes which are nurtured by those who have built their careers around project management and politics. We desperately need to acknowledge that processes, policy and even regulations are the means by which we achieve national security, not the ends themselves. If processes are hindering progress, then we should be ruthless in cutting out unnecessary and wasteful steps, or even processes in their entirety.

Over regulation

We might expect a reaction to the suggestion of deregulation and removing process 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 actually lower the probability or lessen the consequences of an event actually occurring. Perhaps one of the largest most often cited example of this phenomena in history is that of the Maginot Line. The construction of the Maginot Line - a heavily fortified wall - was approved to span the eastern boarder of France with Germany to deter German aggression. In 1939 its construction was largely complete and in 1940 the German army simply drove around it, through Belgium and into Northern France where fortifications were much weaker. The French government were persuaded to invest 3 billion French francs (~$3.9 billion in today's money) to do something that proved to be ineffective based on a feeling of security. As the French were static and inflexible, the Germans developed Blitzkreig to easily defeat their adversary. Had the French government properly understood the problem they were faced with and invested in more flexible, decentralised and manouverable force which posed multiple dilemmas for Hitler, then perhaps this may have delayed invasion, or even significantly altered the events leading up to WWII. We are of course chasing theoretical ‘what if?’ questions here, but the point is that regulations, processes and projects that make us feel safe don’t necessarily lead to a reduction in risk. We need to be able to effectively gather feedback and data to measure, analyse and manage risk to make effective judgements and to 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.

A way ahead

The previous section was a bit gloom and doom, but I’ll soon make some suggestions on a way 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 key sources of friction which we’ve experienced along the way. 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

In order to develop empathy and true 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 key 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 that is being developed will actually solve a problem that is being experienced. If not, the solution can be adjusted or scrapped all together before becoming too big to fail.

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, debrief, 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 implementation of a specific suggestion, but should at least be an explanation of why an idea might not be the best solution to a problem. If someone engages with this process and they in turn receive no feedback, then 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 mostly on those developing capability, but front line operators also have an extremely important role to play here. Put simply, if problems are not articulated clearly by those on the front line, then we should not expect them to be magically solved.

Data

“If you can’t measure it, you can’t manage it.” Col Henry Willi

Front line feedback is an especially valuable form of data to base decisions upon, but not the only important source. It seems painfully obvious typing this out, but I think it’s necessary to state explicitly. Our decisions should be based on objective data that is continuously gathered rather than subjective opinion or anecdotal evidence. To do this, the RAF and MOD will need to build and own our own 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 snap shot of the current state of affairs to base all subsequent decisions upon, 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 topical example of what this might look like in practice; the provision of hot water in service accommodation. Everybody knows that hot water in service accommodation is pretty fundamental in supporting our people and fulfilling the foundation of Maslow’s hierarchy of needs. However, it doesn’t seem as if anyone has a clear understanding of the extent of the issues which plague our ageing infrastructure, nor does anyone seem to be proposing an acceptable solution to resolve it. Put bluntly, we can’t guarantee a hot shower for those who we entrust to engineer, support and operate our exquisite capabilities, so how can we possibly expect to recruit and retain the best talent? I dare say that the Defence Infrastructure Organisation 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 talking about novel or emerging technology that will directly lead to victory in a peer-on-peer state conflict, but 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 which is used to make or inform some decision in the kill chain. If you're involved in capability development and you don't know what the previous sentence means, this is exactly my point. Data management is boring and difficult, but it’s impossible to overstate how important it is when it comes to making decisions about capability development.

Insourcing and intrapreneurship for digital

As we step into 2023, the lines between the real and virtual worlds are becoming increasingly blurred. Actions in one can have a profound impact on the other, and we should expect to see more weird and wonderful emergent phenomena as this blurring inevitably continues throughout this decade. One such phenomena is the power and influence that individuals and small groups with the right combination of skills, tools and enthusiasm can exert on the world. When it comes to military capability, the current state of affairs stands in stark contrast to dynamics of the 20th century in which power and influence was largely held by companies who owned equipment and intellectual property to build planes, tanks, weapons and ammunition.

Stepping in to 2023 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 prime contractors for everything. Clearly, when it comes to physically building stuff at scale, we need to leverage industrial power, but this need not exclusively be the case when it comes to digital capabilities where more nuanced combinations of military-industrial teams might be possible and even desirable. I’ve made the case for closing the gap between developers and front line operators, but if these two roles can be one in the same, then all the better! This is exactly how Ballistic came into being and in my humble opinion, how it became a success.

Over 3000 people have completed the JHubCoding Scheme which was set up in 2019 to financially incentivise military personnel and civil servants in the MOD to learn to code. Further, the RAF has established the Future CAS Fellowships to fund masters level education in subjects such as Data Science, Artificial Intelligence, Cyber Security and Sustainability. These are but two examples of how we are upskilling our people in a meaningful way, but the framework simply doesn't yet exist to gainfully employ these people. There has been some truly heroic efforts to establish organic software development capabilities and to professionalise this activity, but to unlock the true potential of our people, 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 field of digital, data and technology 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 simply cannot afford to delay.

Some things

So I’ve written about how we might go about putting our people first, and some ideas about how we might do that. I’ll now conclude with a very short section talking about the third and final of Boyd’s priorities. Things. These are some of the the things which I’ll be working on throughout 2023 after thinking deeply about our people, and the ideas which we might implement to support those on the front line.

Apps

After the success of Ballistic, we're aiming to deploy another app called Moment - a weight and balance calculator app for the C130J - very early in January. From there, we will seek feedback on the app to see a) what people like and dislike about it and to b) see whether the app will have utility for other fleets such as the C17, Shadow and P8. Dan and I recently made contact with colleagues from the French Air Force who have made a similar app for the A400M called CargoReady, and so we’ll be working out the utility of this, and whether it’s worth deploying the app to the UK A400M fleet. There are a couple of other apps that are in the backlog, but their utility hasn’t yet been validated, so I won’t ramble on about these just yet.

Electronic Flight Bag (EFB)

Over the last couple of years working on software development, it has become clear that the guidance for adoption of EFB in the MOD is almost non-existent. The Air Mobility Force has what I believe to be a really great solution - albeit, there are always improvements to make - and so I’ll be working to share all of the hard learned lessons which we’ve learnt with the Combat Air, and ISTAR Forces to ease their path to adoption of EFB.

Summary

Stepping into the new year, everyone who works in capability development should consider whether they truly understand the problems they are trying to solve, or whether they are either plugging a solution without a problem, or just turning the handle because "that's the way we do things around here". If we find that we spend more time nurturing or fighting the system itself as opposed to delivering value to the people who make daily sacrifices and put themselves in harms way, then perhaps we're doing something wrong. I for one 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 by closing the gap between developers and front line operators, we stand a good chance of accelerating to the pace of relevance.