Engineering Without the Gridlock: How Small Teams Move Fast and Solve Big Problems

07 Jul, 2025 Innovation

In early 2025, the Air Force’s Blue Horizons program tasked TILT Autonomy to design and build an autonomous surface vehicle (ASV) capable of finding and recovering downed Airmen in the ocean. This was an extremely demanding project, but TILT successfully delivered a working prototype in just three months.

By Mark Jacobsen // Director of R&D at TILT Autonomy

One key to our success was building a tight, focused team around the project. In this post I will discuss our preference for keeping our project teams lean, and why this can confer such an advantage.

The Challenge of Managing Complexity

We knew this would be an exercise in complex systems engineering. Almost every capability would involve numerous subsystems.

Consider raft docking, for example. Once MARV conducted its search and located a raft, it would need to fuse multiple sensor inputs to estimate the raft’s location, continually slew a FLIR camera to track the raft, then seamlessly transition to a separate stern-facing camera to monitor the docking. Control algorithms would tell the autopilot precisely how to maneuver, and our lower-level autonomy stack would convert autopilot servo outputs into signals to custom TILT autonomy modules. Those modules, in turn, would drive actuators to control the boat’s engine, throttles, and other subsystems. A remote ground control station would monitor the docking, show progress to a human operator, and afford opportunities for human takeover if necessary. The boat would also report its sensor picture back to a TAKServer, allowing higher headquarters to monitor its activities.

Every piece of this was hard, but the paramount challenge would be managing complex integration. That has technological and human aspects.

Engineering projects rise or fall on human organization. Teams that successfully master complexity can work miracles; teams that don’t typically enter death spirals that grind product development to a halt.

At TILT, we believe that lean, focused teams offer the best organizational form for early-stage systems engineering.

Conway’s Law

Conway’s Law states that an organization’s structure largely determines the architecture of a product. Different contexts require different organizational styles, and good managers know how to organize teams to deliver the desired result.

The basic idea is that boundaries arise between teams because communication is difficult. A solo developer can hold an entire project in his head, but when a project gets spread across people and teams, any change requires communication and coordination. If you split a project between three teams in different cities (or even different floors), you will almost certainly get a product architecture with three different modules.

Good developers will modularize their system and thoughtfully develop stable interfaces, which allow each team to freely make changes within their own domain. However, “breaking changes” will inevitably occur at interfaces, especially during the early stage of product design when teams are still learning, experimenting, and refining their design. The extensive need for communication can dramatically slow down development or even stall it entirely.

When you multiply this challenge across large teams (or worse, multiple teams), the complexity can become overwhelming.

Organizing for Gridlock

Conway’s Law illustrates why so many government-led engineering projects fail. Big organizations often invite too many stakeholders into a project, parcel out work across numerous performers, and create high barriers between teams.

For example, when I worked on counter-UAS systems, government routinely designed systems that integrated modules from a dozen or more companies and government teams. Each performer participated via a separate contract (or subcontract) and had distinct costing and intellectual property concerns. Product changes required cooperation among performers who barely knew each other, and many changes required modifying contracts.

Because government needed all these modules to work together, it spent tremendous time up front on interfaces and protocols. This put the cart before the horse. Before it ever began building a system, the government repeatedly invited all these performers to planning meetings, where countless engineers, lawyers, and program managers argued over protocol and interface design. With so many people in the room, discussions went in endless circles without decisions.

The projects unsurprisingly saw low development velocity, significant system integration problems, and tremendous pain at the many interfaces.

Some teams never manage to integrate their complex systems at all. One common symptom of this breakdown is the “many screens” problem. A human operator must sit in a nest of computer screens, all displaying different software applications, because nothing interoperates.

The “many screens” problem is not usually technological; it is organizational.

The Virtue of Lean Teams

Decades of human experience have yielded best practices for how to organize for early-stage, experimental innovation. Product development teams should start small, work in a close-knit and well-resourced environment free from bureaucratic impediments, iteratively develop a just-good-enough product in partnership with early customers, automate everything that can be automated, and continuously test and deploy.

A small, well-protected team can freely experiment, dynamically alter designs, and work across the full tech stack without significant impediments. Only as a design stabilizes and finds product-market fit should a company scale the team around it.

Kelly Johnson, one of our heroes at TILT, embodied this philosophy in his legendary Skunkworks division, which developed novel aircraft like the U-2, SR-71, and F-117. We try to follow his example.

TILT previously helped other DoD clients convert two manned platforms into optionally manned vehicles. These were one-off projects, but we kept a larger vision in mind as we developed our technology.

Rather than hand-wiring our first prototypes, we embraced Design for Manufacturing practices to develop a series of high-quality reusable modules for automating commercial vehicles. Modules typically featured anodized aluminum enclosures, high-quality connectors, printed circuit boards (PCBs), and IP-67 waterproof ratings. The team proceeded through multiple iterations, but iterating meant spinning new PCBs and ordering new enclosures. This meant a higher up-front cost, but also put us on a long-term trajectory of possessing high-quality reusable modules that could be produced at scale by contract manufacturers. Extensive automation and low touch-labor requirements also meant we could keep our team small, and our engineers could focus on the work that mattered most.

This investment laid the foundation for MARV. When TILT began the Blue Horizons project, we could use our existing autonomy modules as a foundation. TILT’s first autonomous vehicle conversion took eight months; with MARV, automating a new type of civilian boat took just weeks.

From the beginning, we designed MARV as a system. A single computer, running one primary software application, served as the integration point for all the higher-level software on the vehicle. It communicated directly with the FLIR camera, the SIMRAD radar, the autopilot, the computer vision system, and the ground control station. Nearly all the code lived in a single monorepo. Developing this architecture took a great deal of work, but once the major pieces were in place, complex new features could be implemented relatively quickly. We wrote the raft docking code in just a few days, even though it involved numerous systems, because all the needed interfaces were accessible by one team in one place.

MARV did have one crucial boundary: the link between the lower-level and higher-level autonomy stack. Unsurprisingly, this boundary is where most of our initial friction played out. We also spent longer than planned implementing a power system and troubleshooting the onboard network, which is unsurprising given that these systems touch numerous other modules on the boat. Fortunately, working through these issues was straightforward. The project team could all fit on the boat at once, allowing us to troubleshoot issues face-to-face in real time. Given our flexible roles, we could also dynamically reallocate individual effort as needed to swarm on pain points. We resolved most issues quickly.

Blue Horizons was the ideal government partner, because the faculty share our enthusiasm for small dedicated teams. The Air Force and Space Force give Blue Horizons fellows significant time, money, and top cover, and entrust them to execute prototypes without interference. For the duration of the project, we reported to a team of just three Fellows who were passionate about the project, liked to move fast, and emphasized building over talking.

Conclusion

Organizing to develop technology requires a keen understanding of tradeoffs. There is rarely a single right answer, but rather a tradespace of possibilities that fare better or worse in specific contexts. A single company or product team might evolve through numerous forms over a product’s lifecycle.

Still, the history of innovation is clear: when developing new technology, starting lean is usually a virtue. For complex systems, Conway’s Law implies we should organize with as few stovepipes or contractual boundaries as possible. As a design stabilizes and a product matures, an organization can evolve to support its unique needs.

This philosophy paid off quite well as we developed MARV. We are proud of what we accomplished in just a few months, and grateful to Blue Horizons for making it possible.