UNIT.City — місце, де люди працюють... КРАЩЕ! Обирай свій простір просто зараз 👉
Марія БровінськаWork
8 June 2026, 09:00
2026-06-08
“We don’t have two weeks for a sprint.” How Ukrainian miltech learned to work without legacy, endless meetings, and corporate bureaucracy
There’s a long-standing joke in civilian IT that any project sooner or later turns into a struggle with legacy code, endless approvals, and a calendar filled with sonnets and status meetings. Large companies spend years building processes that are supposed to make development predictable, but often slow it down so much that months pass from the appearance of an idea to its implementation.
Ukrainian miltech today lives in a different reality. When a product is tested not in a focus group, but in real combat conditions, and a request from the military can come in the evening with a requirement to receive a solution the next day, the usual corporate rules begin to work differently. That is why defense technology companies are gradually forming their own development culture — faster, tougher, and much less tolerant of processes for the sake of processes.
dev.ua spoke with representatives of SKIFTECH, Himera, BlueBird, DevDroid, WIY LLC, The Fourth Law, and Odd Systems to understand how modern defense tech teams actually work, whether they need Scrum and PM, how they use AI, and why combining hardware and software remains one of the industry’s most difficult engineering challenges.
There’s a long-standing joke in civilian IT that any project sooner or later turns into a struggle with legacy code, endless approvals, and a calendar filled with sonnets and status meetings. Large companies spend years building processes that are supposed to make development predictable, but often slow it down so much that months pass from the appearance of an idea to its implementation.
Ukrainian miltech today lives in a different reality. When a product is tested not in a focus group, but in real combat conditions, and a request from the military can come in the evening with a requirement to receive a solution the next day, the usual corporate rules begin to work differently. That is why defense technology companies are gradually forming their own development culture — faster, tougher, and much less tolerant of processes for the sake of processes.
dev.ua spoke with representatives of SKIFTECH, Himera, BlueBird, DevDroid, WIY LLC, The Fourth Law, and Odd Systems to understand how modern defense tech teams actually work, whether they need Scrum and PM, how they use AI, and why combining hardware and software remains one of the industry’s most difficult engineering challenges.
PM at miltech is not a meeting coordinator, but a person who drives the product
From the outside, it may seem that miltech is in almost startup chaos: the front line constantly generates new requests, products change literally on the fly, and there is no time for hours of discussions. But the reality turned out to be more complicated.
All the companies that dev.ua spoke with have product or project teams, and the role of the PM here is often even broader than in classic IT.
SKIFTECH notes that it is impossible to do without PM even in military technologies, but the level of responsibility here is much higher. Managers do not just manage projects, but work with products that will be used by the military, so a delay or error can have much more serious consequences than in civilian software.
BlueBird also says that a PM at miltech is much more deeply immersed in development and technical processes than his colleagues at many IT companies. A significant part of the work is related to coordinating hardware and software teams, prioritizing tasks, and making quick decisions.
In turn, The Fourth Law and Odd Systems admit that some of the classic PM functions have been divided between Product Owners and Engineering Managers. The former are engaged in the search for ideas, the formation of hypotheses and prioritization, the latter — in implementation and technical solutions.
And DevDroid says that today they lack precisely managerial personnel. «We are not even actively recruiting programmers or technical specialists in R&D, because we understand that without a sufficient number of people who can manage processes and projects, we will simply run into a management bottleneck,» explains DevDroid R&D Director Oleg Fedoryshyn.
Why Scrum often loses out to reality on the front lines
There has long been an unspoken rule in civilian IT: the bigger the company, the more processes. Sprint planning, retrospectives, status meetings, coordination between teams, coordination between managers. Over time, all this often becomes overgrown with additional layers of bureaucracy.
In miltech, the situation is different. In particular, Skiftech says that when a product operates in conditions of constantly changing requirements, dozens of hours of sync meetings become a luxury. Instead, short syncs, direct communications, and quick solutions work.
«In defense tech, the ‘receive feedback — make changes — check’ cycle can last days or even hours,» the company explains.
That’s why most of the companies surveyed use Agile approaches, but almost none work by the book. BlueBird says that teams remain Agile, but without «corporate Scrum in a vacuum.» Processes are adjusted to the engineers and the actual speed of development, not the other way around.
DevDroid went even further. «Classic Scrum doesn’t work well in our conditions. Kanban is closer to us now, because tasks can appear literally yesterday,» says Oleg Fedoryshyn, the company’s R&D director.
He gives a telling example. If the military needs to implement a new scenario for using equipment tomorrow or add an element of autonomy for a specific mission, the team cannot say: «We have a sprint now, we will come back to this in two weeks.» «They need a solution today or at most tomorrow, so the reality of the front dictates a completely different speed of work. We do not have two weeks for a sprint,» he says.
However, this does not mean the absence of processes. On the contrary, almost all of dev.ua’s interlocutors emphasize: it is impossible to create complex technological products without processes. But processes should help make decisions, not hinder them.
MVP works. But «ship now, fix later» doesn’t
At first glance, it may seem that miltech lives by the canons of classic startup culture: quickly made, quickly tested, quickly fixed. This is partly true. All companies talk about rapid iteration, constant testing and hypothesis testing. But almost all of them emphasize at the same time: the principle of «ship now, fix later» works very limitedly in military technologies.
In particular, SKIFTECH explains that an error in defense tech can cost much more than in a typical software product, so speed always has to be balanced with reliability.
Instead, Himera describes the approach differently: «For us, it’s more like test now, fix now. Solutions should be constantly tested in real conditions, and changes should be implemented as quickly as possible based on practical user experience.»
That is why MVP in miltech usually does not mean a «raw product», but a minimally sufficient solution that can already be safely tested in the field.
One of the most interesting features of Ukrainian defense tech is the short path between the engineer and the end user. The best QA in the industry is a military man who tests the product tomorrow. The Fourth Law calls this one of the main advantages of the industry. A prototype created today can be tested the next day. And feedback from people who use the product directly in real conditions often turns out to be much more valuable than any laboratory or usability tests.
In fact, the front became a user, QA department, and product analytics for Ukrainian defense-tech teams at the same time.
AI is everywhere. But he’s not a senior engineer yet
Another topic on which companies were surprisingly unanimous is that AI is gradually becoming an integral part of engineering work.
SKIFTECH directly states that companies that do not integrate AI in the coming years risk losing competitiveness.
BlueBird specialists actively use Copilot, Cursor, agentic coding, synthetic data and simulation environments. In turn, The Fourth Law engineers work with both general models such as GPT and Gemini, and with their own neural networks for computer vision and autonomous systems tasks.
However, the most pragmatic view of AI was expressed in DevDroid.
«Today, AI for us is more like a very strong junior specialist who can help figure things out, speed up work, or take on some of the tasks. But it’s not yet a confident middle and definitely not a senior,» says Fedoryshyn.
This is especially noticeable in embedded development and working with low-level hardware, where models can still hallucinate or confidently suggest solutions that do not exist in reality.
The hardest part starts where hardware and software meet.
This is where, according to almost all of the interviewees, the usual rules of classical IT end. While a software product can be updated several times a day, hardware is subject to completely different laws. Production, components, logistics, testing, testing grounds, and field trials cannot be accelerated in the same way as the deployment of a new version of the application.
Himera says the main difficulty lies in the need to synchronously develop two worlds with completely different rates of change. And SKIFTECH emphasizes that any change in software can affect the behavior of sensors, electronics, power consumption, or communication.
The Fourth Law calls the creation of complete hardware-software systems, where each component influences the others, the most interesting engineering task of modern miltech. And DevDroid adds that it is at such moments that the role of human experience becomes especially noticeable. After all, when the system behaves unpredictably, and the problem needs to be looked for at a training ground in the rain, under stress and limited time, it is not the tools that become decisive, but the engineering intuition and experience of the team.
Without unnecessary processes
If you try to reduce dozens of responses from various Ukrainian defense-tech companies to one thought, it will sound quite simple: miltech does not work without processes. It works without unnecessary processes. All the usual IT tools remain in place here. There are PMs, Jira, GitLab, Agile practices, retrospectives, and planning. But each of these elements is tested for practical value. If a process helps create a quality product faster, it stays. If it begins to exist for its own sake, it is removed.
However, the main difference between defense tech and classic IT lies even deeper. In civilian products, a mistake often means an unhappy customer, a lost contract, or a drop in conversion. In military technologies, the price of a mistake is much higher. That is why Ukrainian miltech teams are simultaneously forced to move faster than most IT companies and be much more careful with the quality of solutions.
In fact, the front has become the most demanding product manager, QA engineer, and user for Ukrainian miltech at the same time. This means that between a decision made today in the office or laboratory and its verification in the real world, sometimes not months or even weeks, but only a few days pass.
«I can’t even tell a girl where I work.» How security is arranged in Ukrainian DefTech companies and why when joining the defense industry, you need to be prepared to become a keeper of secrets