Why operational domain understanding can strengthen teams, shorten the path to delivery and make defence capabilities easier to bring into use.
We are at a time when the Danish Armed Forces must translate major investments into capabilities that work in practice. New IT systems, equipment, infrastructure and complex procurement programmes must be developed, integrated and delivered at pace. This places significant demands on the technical specialists and suppliers tasked with delivering them.
Alongside all the technical questions, I believe we also need to ask another question: Do we sufficiently understand the operational reality in which the solution must function? Operational domain understanding can make the difference between a technically successful delivery and a capability that can actually be used from the outset. It can help a team ask the right questions earlier, avoid unnecessary detours and reach a better outcome sooner.
Lessons from the IT industry
I come from the IT industry and have spent my career providing specialist expertise for major IT projects, including within critical infrastructure and cybersecurity. I have seen what happens when strong development teams build against extensive requirements without gaining sufficient insight into the processes and situations their solution is intended to support. In some projects, it only became apparent late in the process that parts of the system did not fit the way users actually worked. Significant elements then had to be changed when development was already well advanced. In other cases, needs and workflows had shifted while the system was being built, leaving aspects of the solution outdated before it even entered use.
When I began my career, projects typically followed a traditional waterfall approach: requirements specification first, followed by development, and finally testing and handover. User involvement and user experience (UX) were not always priorities from the outset. Sometimes, the ambition was largely to modernise what already existed: the same processes and screens in a new technical package. But skilled developers and new technology cannot, on their own, determine which workflows make sense for users. That knowledge must come from people who understand the domain and can challenge assumptions while there is still an opportunity to change direction.
Fortunately, over the past 15 years, I have also witnessed a different approach emerge. Agile methods, including Scrum, have made continuous feedback, iteration and closer contact with users a more natural part of many development processes. This does not mean that requirements specifications have become redundant, or that every project should be organised in the same way. For me, the lesson is rather that a good plan and a good requirements specification cannot stand alone: An understanding of the users and how the solution will be used must remain part of the project throughout, including when circumstances change.
A new industry — and a familiar challenge
It is with these experiences behind me that I have entered the defence industry over the past six months. I am still new to this domain and have great respect for the many skilled companies and people already working in it. At the same time, I have come to appreciate how different and complex the operational context is. Workflows, security requirements, readiness, decision-making processes, existing systems and equipment are interconnected in ways that an external supplier may not necessarily understand. This is not limited to IT. It also applies to installations, logistics, physical infrastructure, systems integration and major equipment procurement programmes.
I see many suppliers with strong technical expertise and innovative solutions. Many also have substantial defence experience. My point is therefore not that the industry generally lacks understanding, but that operational insight can be a scarce resource, particularly when many major projects need to be delivered simultaneously. That makes it important to use it where it can have the greatest impact. Not every team needs a former member of the armed forces. But a team of engineers, developers, technicians and project managers should be able to draw on people who understand both the operational task and how to work within and navigate the Danish Armed Forces.
From requirements to use — throughout the process
Imagine, for example, a team developing a deployable technical capability. The team may have expertise in networking, power supply, integration, mechanical engineering and documentation. But who challenges the assumptions about setup time, transport, staffing, maintenance and use under pressure? Who asks how the capability will work alongside existing systems, or what happens if the usual support is unavailable? These are illustrative questions, but they show why operational experience does not belong solely at the start of a project or in the final test. It should be available throughout, allowing the team to seek advice, adjust the solution and assess its choices against how the capability will actually be used.
A solution is not necessarily operationally usable simply because it works technically. Testing must therefore also reflect the people, situations and constraints the solution has been designed for. And implementation does not begin only at handover: Training, operations, maintenance, workflows and organisational readiness should be considered during development. Otherwise, the recipient may be left with a product that requires substantial changes or an unexpected implementation effort before it delivers value. In projects moving at pace, early and ongoing input from people with operational experience can help prevent precisely these kinds of surprises.
The right knowledge at the right time
I believe that combining technical expertise with operational domain understanding makes the whole team stronger. The person bringing operational experience should not take over the work of the engineer or developer, but can help translate needs, ask different questions and identify the trade-offs that only become apparent in real-world use. This can reduce misinterpretations, make onboarding easier and lessen dependence on individual key people. At Pro Defence, this is precisely the kind of collaboration we want to support: making relevant domain knowledge available to the teams and suppliers tasked with translating ambitions and investments into operational capabilities.
I am not seeking to tell the defence industry that I have all the answers after six months in the sector. Rather, I want to bring experience from another field into the conversation. When investments are substantial and the pace is high, we should ask ourselves whether the people who understand the operational reality are being involved early enough and often enough. Not just to approve a finished product, but to inform and improve decisions throughout the process. That is how I believe we can reach solutions sooner that are both technically strong and effective when they really need to be used.
Domain understanding is not an alternative to technical expertise. It is a prerequisite for getting more out of it.