Key Learnings from Distributed Cyberphysical Programs

Software teams went remote practically overnight. Cyberphysical programs couldn’t.

As we approached one year of highly distributed teams and remote work, I spent meaningful time helping multiple clients in different industries manage significant disruption to their operating model while minimizing the growing pains of adjusting to a new way of working. These clients weren’t building apps. They were building complex, hardware-driven systems in highly regulated, often classified environments.

The constraints were real: you can’t classify a Zoom call. You can’t ship hardware to a home office. And you can’t skip an integration test because the team is working from different time zones.

Here are the major learnings that continued to enable success through 2021 and beyond.

Learning 1: Enabling Success in a Distributed World Requires Investment

One client worked on highly sensitive classified materials tied to national security interests. The complexity of building cyberphysical systems in a secure environment compounded the challenge immediately: not one person is capable of building everything that needs to be built, and the work has to be done in secure facilities.

Getting distributed right required investment not just in teleworking infrastructure, but in a secure network that made it possible to even discuss the work from a distance. This wasn’t a quick configuration change. It was a dedicated program that enabled two dozen other programs to talk about their work without requiring everyone to be physically present at a secure facility during a pandemic.

The lesson: distributed capability doesn’t happen accidentally. It requires a deliberate investment, and that investment pays returns across every program that depends on it.

Learning 2: Distributed Doesn’t Always Mean No Contact, and That’s Okay

Even with every investment in remote infrastructure, we were not able to move to a fully remote operating model. A significant portion of the work involved hardware. People needed to be onsite.

So we put policies in place to enable safe onsite presence: hand sanitizer stations, temperature checks before entering secure facilities, and clear protocols that allowed people to do the work that couldn’t be done remotely without putting the entire team at risk.

The lesson: don’t let perfect be the enemy of good. The goal isn’t full remote. It’s the right model for the work, executed responsibly.

Learning 3: Not Everybody Needs to Do Everything at Once

Once we accepted that some work required physical presence, we had a choice about how to manage that. The answer was staggered scheduling.

Rather than sending whole teams to a worksite at the same time, we worked in shifts. Different individuals and small groups rotated through onsite time, ensuring a consistent onsite presence without concentrating the risk. If one person became ill, the entire team wasn’t exposed simultaneously.

This approach kept us operational. It minimized risk. And it required a different kind of planning discipline: who needs to be onsite for what, in what sequence, and with what handoffs to the team members working remotely that day.

Learning 4: Digital Modeling and Prototyping Saved Our Ability to Deliver

Staggered schedules helped with safety, but they also had a side effect: lead times on complete physical builds started going up. With fewer people onsite at any given time, the serial work of hardware integration slowed down.

The response was to reduce our dependence on physical prototypes throughout the development cycle. An investment in digital modeling and prototyping enabled us to maintain design fidelity and catch integration issues without requiring a physical build at every stage. Physical prototypes became reserved for key development milestones rather than continuous checkpoints.

In an ideal world, you have physical prototypes throughout program execution. But in a distributed, constrained environment, digital modeling kept us effective at a distance and actually reduced overall risk by catching problems earlier in the development process.

The lesson: constraints force innovation. The shift to digital modeling was something many programs had resisted before 2020. Those that embraced it came out ahead.

Learning 5: Strategic Planning Requires Dedication Across Business Functions

Before the shift to distributed work, quarterly planning sessions were informal: individuals dropped by as needed, we compressed everything into a day or two, and we moved on. That model broke immediately under the pressure of distributed coordination.

What we learned is that strategic planning requires dedicated time to get right, and you can’t get it right without the right people not just available, but actually present and engaged. We moved to three and four day planning sessions to accommodate virtual collaboration and time zone differences. And we required representation from all major corporate functions necessary to successfully execute the program, not just the engineering teams.

When procurement isn’t in the room during planning, roadmaps get delayed. When legal isn’t involved early, authorizations become emergency requests. When finance doesn’t understand the dependencies, resource decisions get made with incomplete information. Strategic planning isn’t just a delivery exercise. It’s a cross-functional alignment exercise, and it needs to be treated that way.

The Longer View

The last year was not easy, but it created opportunities for growth that wouldn’t have emerged under normal operating conditions. The organizations that invested in the right infrastructure, accepted hybrid models, staggered their physical presence, embraced digital tools, and committed to real cross-functional planning came out of it with stronger operational foundations than they had going in.

The challenges of distributed cyberphysical work are not unique to a pandemic. Large, complex, hardware-driven programs will always face geographic distribution, classification constraints, and the friction of coordinating across organizational and institutional boundaries. The learnings from this period don’t expire. They’re the foundations for operating successfully in the strategic cyberphysical space for years to come.