Running One Company Across Two Continents Without Breaking It

A two-continent company doesn't break in a dramatic way. It breaks quietly — two teams slowly building two different versions of the truth, two roadmaps that no longer line up, two sets of priorities that each look reasonable in isolation. By the time you notice, you're not running one company anymore. You're arbitrating between two.

I run Dronehub across exactly this kind of split: a manufacturing and R&D base in Poland, near Rzeszów, plus US market entry that I started through the GENIUS NY accelerator in Syracuse, New York. I live the split personally too — Ukrainian national, Polish resident, US permanent resident. My thesis after years of this is unglamorous: what holds a cross-continent operation together is not founder heroics or a great culture deck. It's ruthless process design and automation. Heroics are what you fall back on when the process is broken.

Why does a two-continent company quietly split into two?

The failure mode is not conflict. It's drift. Two locations, six timezones apart, each doing competent work, each accumulating its own context that the other side never sees. The Polish team knows things about a production run that the US side learns three weeks late. The US side has a customer conversation that never makes it back into the engineering backlog. Nobody did anything wrong. The information just never crossed the ocean, because crossing the ocean required a meeting, and the meeting kept getting pushed because of the timezone gap.

Once that drift compounds, you get the visible symptoms: duplicated work, contradictory priorities, a "them versus us" tone in how each side talks about the other. People start to believe the other continent doesn't get it. The instinct is to fix this with more communication — more standups, more all-hands, more syncs. That makes it worse. You're adding synchronous load to a system whose core problem is that synchronous communication doesn't scale across a six-hour gap.

The real fix is structural. You make shared reality the default and private reality the exception. Everything that matters lives in one place both continents can see, and keeping a private version of the truth has to cost more than writing it down. Get that right and the drift has nowhere to accumulate.

What do you centralize, and what do you localize?

This is the central design decision, and most founders get it backwards. They centralize the wrong things — control, approvals, day-to-day decisions — and localize the wrong things — data, standards, what "done" means. That produces a bottleneck in one location and chaos in the other.

My rule: centralize the things where divergence is expensive and silent; localize the things that are physically bound to a place.

Centralize:

• The single source of truth. One system of record for the roadmap, the metrics, the customer reality, the engineering state. Both continents read from and write to the same place.
• Standards and definitions. What "shipped" means. What "qualified lead" means. What a P1 incident is. These can't be allowed to fork, because forked definitions are invisible until they cause a fight.
• Financial truth and the roadmap. One set of numbers and one prioritized list of what the whole company is doing. Not a Polish list and an American list.

Localize:

• Physical production. Hardware gets built where the machines and the people who run them are. In our case that's Poland, where the Dronehub group includes JFACTORY, its precision-manufacturing arm in Jasionka — CNC machining, fiber-laser cutting, 3D printing. You don't centralize a machine shop.
• Regulation and legal filings. Each jurisdiction has its own rules, and pretending otherwise is how you get fined.
• Hiring and customer relationships. These are relationship-bound and place-bound. The person closing a US conversation should be close to it.

The clean way to say it: centralize information, localize physical and relational reality. The Dronehub group being a multi-entity Polish group of companies isn't an accident — it's deliberate structure that lets each entity do what its geography is good at while still rolling up to one operating picture. If you find yourself centralizing a decision a local team could make faster and better with the same data, you've drawn the line in the wrong place.

How do you turn the timezone gap into an asset instead of a tax?

Poland and US Eastern run about six hours apart. You get a few hours of genuine overlap and a long stretch where one side is asleep. Most teams treat this as pure friction. I treat the asleep hours as throughput.

The mechanism is asynchronous handoff. Work is written down — state, blockers, what's needed next — so that when the other timezone wakes up, it can pick the work up cold, without a call. Done well, the company never fully stops. Poland advances something during their day, hands it off in writing, and the US continues it during theirs. That's not a compromise; it's a structural advantage a single-timezone company doesn't have.

For this to work, one rule has to be absolute: no decision should be blocked waiting for a live conversation. If something only moves forward when two specific people happen to be awake at the same time, that's a process defect. Either the decision rights are in the wrong place, or the context needed to decide isn't written down where it should be. I treat every "we'll discuss it on the next call" as a small failure — a thing that should have been decidable async and wasn't.

The few hours of overlap are precious, so I protect them. Overlap time is for the things that genuinely need synchronous bandwidth — hard tradeoffs, relationship repair, fast back-and-forth on something ambiguous. It is not for status updates. Status is the easiest thing to make async, and it's usually what eats the overlap if you let it.

Why is automation, not headcount, what actually holds it together?

Here's where most people reach for the wrong tool. The two-continent coordination problem feels like a people problem, so the instinct is to hire coordinators — someone in each timezone whose job is to keep the other side informed. It works for a while. Then it doesn't, because coordinators scale linearly, they become single points of failure, and they burn out sitting between two clocks.

My operating rule, the same one I teach in my AI-education work: if I do something twice, I think about automating it. If three times — I automate it. Across two continents, almost every coordination task is recurring by definition. The status sync that has to happen every morning for the other timezone. The report regenerated for each side. The routing of a customer issue to the right person regardless of which continent is awake. The reminder that fires when a handoff is overdue. Every one of those is a script or a workflow, not a job.

The deeper reason I favor automation over heroics is that heroics hide broken process. When a person stays up until 11pm to push something across the gap by hand, the work gets done and the broken process underneath it stays invisible — until that person leaves, gets sick, or simply runs out. Automation is the opposite. When you try to automate a handoff and it's hard, the difficulty is telling you something true about where your process is messy. So you fix the process, and then the automation is easy. The act of automating is also an audit.

I'd rather spend a full day building the pipe than spend every week of the year shoving things through it manually. That math is overwhelmingly in favor of building the pipe, and it gets more favorable the longer the company runs. None of this requires exotic tooling — it requires the discipline to notice the third repetition and stop doing it by hand.

Why keep building in Poland while selling into the US?

Because the two continents are genuinely good at different things, and the entire point of a cross-continent company is to use both rather than averaging them out.

Poland gives Dronehub a deep, affordable engineering base, access to European R&D programs — we've coordinated work under Horizon 2020 and run projects with the European Space Agency and the European Defence Agency — and an in-house manufacturing capability most hardware startups would envy. I built that base as a Ukrainian founder in Poland's aviation cluster, and you don't casually relocate it. The machines, the suppliers, the engineers, the institutional relationships — that's years of accumulated reality bolted to a specific place.

The US is where a very large market and a deep pool of capital sit. That's why I went through GENIUS NY in Syracuse for market entry rather than trying to sell into the US from a desk in Poland — and it's the same logic behind building my next company, Oswin AI, in the US from the start. Being a US permanent resident through my EB1A green card is part of what makes operating on the ground there workable rather than theoretical.

So the structure writes itself: build where building is cheap and deep, sell where the market and money are. The hard part isn't choosing the two locations. It's connecting them with enough process that they behave as one company instead of two pen pals. If you'd rather see the strategic tradeoffs in detail, I wrote about where to build, raise, and sell across the US and EU separately.

What kind of CEO does this actually require?

A specific one, and not the kind most people picture. I describe myself as "Tony Stark, not Elon Musk" — meaning a builder and an engineer first, someone whose instinct is to get into the system and fix the mechanism, not to be the company's public face. That self-image isn't vanity. It's the operating style a two-continent company demands.

A celebrity-CEO model fails across continents because it's inherently centralized around one person being present and visible. You can't be present on two continents six timezones apart. The builder model works because a builder's instinct, when something breaks, is to fix the system so it stops breaking — to look at a painful handoff and design it away rather than personally bridge it every time. That's exactly the disposition that keeps a distributed company whole.

The CEO's real job here is to be the guarantor of the single source of truth and the single set of standards — the one person who refuses to let the two sides fork into two realities. Everything else gets pushed down to where the data and the context already live.

What this means and where I'd start

If you're scaling one company across countries or continents, the most useful frame I can give you is this: your enemy is silent drift, not loud conflict, and you beat it with structure, not effort.

Where I'd start, concretely:

1. Pick your single source of truth and make private versions of reality more expensive than shared ones. If a fact only lives in one continent's heads, it doesn't exist.
2. Draw the centralize/localize line on purpose. Centralize information, standards, money, and the roadmap. Localize physical production, regulation, hiring, and customer relationships.
3. Make async the default. Treat every decision blocked on a live call as a defect to fix, and protect your few overlap hours for the things that genuinely need them.
4. Find your third repetition and automate it. Every recurring cross-border handoff is a workflow, not a person. The difficulty of automating it is a free audit of your process.

You don't hold a two-continent company together by working harder than the gap. You design the gap out. If you want the longer arc behind how I ended up operating this way, the about page has the timeline — and the contact page is open if you're building something similar.