>

>

Yana Shkvarovska on how a request from the front becomes an engineering task — in Defender Media

Accelerator

Yana Shkvarovska on how a request from the front becomes an engineering task — in Defender Media

Yana Shkvarovska on how a request from the front becomes an engineering task — in Defender Media

Defence Builder Press Service

0 MINUTE READ

Yana Shkvarovska, Director of the Defence Builder Accelerator, has written for Defender Media on how a request from a military unit becomes an engineering task, and what a team should check before its first field test.

The op-ed describes how the accelerator works with military requests, from the first conversation with a unit to a product's readiness for the field. The most recent of those conversations took place in Donetsk region, where Shkvarovska and Roman Pohorilyi, co-founder of DeepStateUA and a member of the Defence Builder Advisory Board, worked with brigade and battalion commanders, operators and heads of repair workshops. Each of them sees a different part of the system, and a realistic engineering task appears where those three views meet. What does not work is asking what solution a unit needs: that question jumps straight to a product and skips the problem. The questions that do work are about the task, the required result and the conditions the solution has to work in.

A request from a single unit stays a field signal until other units describe the same need. Only then is it checked for technical feasibility and against solutions already available on the market, and only after that does it become a direction for the cohort. Directions are set as hypotheses for six to twelve months, and the list is reviewed regularly — tactics, countermeasures and component availability change faster than a product reaches the field.

The brief that follows should cover at least the required effect, the integration context, the constraints, the load on the operator, the expected behaviour on failure and the verification scenario, with success criteria agreed before testing begins. The basics get checked before the main technology: transport, repeatable start-up, deployment time, operator workload and, where relevant, predictable behaviour if communication is lost. A failed field test creates value only when the team records what failed, under which conditions and what has to change before the next iteration. The worst outcome is repeating the test with nothing changed.

Read the full op-ed in Defender Media.