Experience Across Systems

Sixteen years of continuous professional work have taken me through environments that rarely appear in the same professional biography: automotive and food production, smaller-scale aerospace manufacturing, power and industrial infrastructure, automation, IT and cybersecurity, warehousing, logistics, courier networks, and freight and urban transport.

Medicine has also been a significant part of that experience, connected to both my education and professional work.

These environments differ in technology, regulation, scale and the consequences of failure. Yet beneath those differences, the same questions repeatedly appear.

What function must be performed? What makes it possible? Which other functions depend on it? Where are the actual constraints? And what changes elsewhere when one element behaves differently?

My work has never been confined to a single industry or a preferred category of technology. The consistent element is a way of understanding systems: moving between the smallest operational detail and the architecture that determines the behaviour of the whole.

The breadth of experience is not the achievement in itself. What matters is the ability to recognise, reconstruct and design relationships across environments that appear to have very little in common.

Ja-Pojade began with a structural gap in European road transport.

Transport companies needed qualified drivers, often for individual routes or short periods. At the same time, experienced drivers existed outside conventional full-time transport employment. Their qualifications remained useful, but their availability was largely invisible to the market.

The problem was not the absence of people or demand. It was the absence of an effective architecture connecting them.

I designed Ja-Pojade as a complete market system, not merely a recruitment website or mobile application. Its digital platform was one constituent element alongside professional recruitment, qualification verification, commercial processes, contracts, insurance, operational support, marketing and market development.

Each component had a defined purpose. Each was designed around the resources actually available. Their interfaces and dependencies were established so that progress in one part of the system reinforced the others.

The results were disproportionate to those resources.

The system reached approximately 6,000 drivers and 1,000 company-side participants. It developed paid premium recruitment, including practical driving assessment, and an insurance solution addressing risks created by temporary driver assignments.

These results did not emerge from a large organisation compensating for architectural weaknesses with additional capital and personnel.

They emerged from the precision with which individual systems were designed and orchestrated into a functioning whole.

The digital platform made the architecture visible. The architecture made the market function possible.

Not every system is an enterprise, an industrial installation or a digital platform.

Some systems operate directly through human perception.

A fan used during a sauna ceremony is a surprisingly precise illustration. The fan does not create the heat. It changes how heat already present in the environment reaches the people inside it.

Its movement affects airflow, the intensity of heat perceived by the body, the distribution of warm air and the rhythm of the experience.

Timing changes the result. So do direction, speed, repetition and the intervals between successive actions.

But the people experiencing those conditions are not identical components. Their responses differ. The sequence must therefore account not only for physical conditions, but also for observation, feedback and adaptation.

My experience as a sauna master offered an unusually direct encounter with this kind of system: a designed sequence of physical conditions, human responses and decisions unfolding in real time.

The principle reaches far beyond a sauna.

Whether the subject is an industrial workstation, a medical device, a public service or an entire organisation, the system ultimately interacts with people.

Human experience is not merely a consequence of architecture. In many systems, it is one of the functions the architecture must deliberately produce.

An idea can be technically convincing, commercially attractive and supported by capable people while still lacking a viable architecture.

The missing elements may be outside the product itself.

Production capacity. Organisation. Logistics. Financing. Market entry. Procurement. Operating costs. Decision authority. Dependencies between stages of development.

An investment cannot be understood solely through the amount of capital requested or the attractiveness of its projected return. It must be examined as a complete system whose constituent parts have to become operational in the correct sequence.

The same reasoning applies to problems that initially appear outside business architecture.

Affordable housing, for example, connects household expenditure with wages, labour mobility, transport, land, construction capacity, procurement, financing and long-term operation. Changing one element without examining the others may merely relocate the problem.

My architectural approach begins by establishing the function and the conditions required to achieve it.

The objective is then translated into a sequence of achievable states, with resources, dependencies and constraints defined at each stage.

An insufficient budget does not reduce the physical or organisational requirements of a system. It changes what can be built, when it can be built and whether the proposed architecture remains viable.

Capital, timing and execution capacity are constituent parts of architecture, not assumptions placed outside it.

The boundaries of a company are rarely the boundaries of the system in which it operates.

Many functions essential to success belong to independent organisations: customers, suppliers, professional associations, insurers, commercial partners, media and institutions.

A complete architecture must account for those relationships as deliberately as it accounts for its internal processes.

Ja-Pojade provides a concrete example.

Its cooperation with the Pomorskie Stowarzyszenie Przewoźników Drogowych developed beyond an institutional endorsement. The association allocated personnel to support the project, and an external Ja-Pojade office operated through that relationship.

Other relationships connected the venture with transport operators, large companies, industry organisations and specialist media.

A dedicated driver-liability insurance solution was also negotiated with Wiener TU Vienna Insurance Group, creating a form of individual, short-period cover that addressed a practical barrier within the wider transport market.

None of these elements was simply an addition to the software platform.

Each performed a function within the architecture. Each extended what the other constituent systems could achieve.

The photograph of two company presidents shaking hands records one visible moment in that process.

The more important achievement was designing the relationships that made the cooperation operationally meaningful.