In 2016, I gave a TEDx talk built around a simple question: is technology really progressing everywhere?
The answer, even then, was clearly no. Technical capability was advancing quickly, but its effects were arriving unevenly. A person could carry a powerful computer in a pocket while working inside an institution that still depended on paper forms, disconnected databases, manual handoffs, and procedures designed decades earlier. Society could possess extraordinary tools without making them available in the places where they might matter most.
At the time, I described this as the technology gap. The phrase captured the distance between what was technically possible and what people or institutions could actually use.
I did not see it then as a framework that would connect the next decade of my work. That continuity is easier to see in retrospect. After years spent building and deploying software in difficult government environments, working on AI and acquisition at GovSignals, and studying the practical limits of robotics, the earlier idea now seems incomplete.
The technology gap
Technological progress is usually described through breakthroughs: a new model, chip, drug, robot, or manufacturing process. These expand the frontier of what can be done.
But the frontier is not the same thing as an institution’s operating reality. Although it should be.
A capability can exist long before an institution becomes capable of using it. The reasons are rarely captured in a product demonstration. The buyer may not know the capability exists. The operator may not understand it. The institution may not trust it. The purchasing process may not fit it. The product may not integrate with existing systems. The workflow may not change. The system may work in a controlled setting but fail under ordinary operating pressure.
This is why advanced technology and obsolete practice can coexist for long periods. The contradiction is only apparent. Invention and adoption are governed by different systems.
The technology gap was never only about access to devices. It was about the uneven ability of institutions to absorb change. A technically advanced society can still have large parts of its economy operating below the level its own inventions make possible.
That gap has become more important, not less.
Invention is no longer the only bottleneck
Invention remains difficult. Scientific discovery, engineering, product development, and basic research still require rare talent, capital, discipline, and time. The point is not that invention has become easy.
The point is that invention alone is increasingly insufficient.
AI has reduced the cost of producing software, analysis, and technical work. Compute is available through global infrastructure. Capital can form rapidly around promising technologies. Open-source software and published research spread knowledge faster than before. Small teams can create capabilities that once required much larger institutions.
Yet the rate at which organizations change is far slower.
As William Gibson astutely pointed out, “The future is already here—it’s just not very evenly distributed.”
A model can improve every few months while a procurement cycle takes years. A software product can be updated daily while the surrounding workflow remains fixed. A robot can demonstrate a new behavior in a laboratory while reliable use in a warehouse, hospital, home, or public facility remains distant.
The result is a growing imbalance. We can generate technical possibility faster than institutions can convert it into operational performance.
That conversion is deployment.
Deployment is often treated as the final stage of innovation: the work that happens after the important technical problem has been solved. In practice, deployment is its own system, with its own constraints, expertise, infrastructure, and failure modes.
The distance between a prototype and a program is institutional, not merely technical.
The deployment chain
A useful way to think about deployment is as a chain:
- Discover
- Understand
- Trust
- Buy
- Integrate
- Operate
- Measure
- Improve
Each stage depends on the one before it, and failure at any stage can stop a technically strong product from producing value.
An institution must first discover that a capability exists. It must understand what the capability does, where it fits, and what tradeoffs it introduces. It must trust the vendor, the technology, the data, the security, and the likely outcome. It must have a way to buy the product. It must integrate the product into technical systems and operational processes. People must use it correctly under real conditions. The institution must measure whether it works. Then the product and workflow must improve based on what reality reveals.
The chain is not linear. Trust affects purchasing, integration changes understanding, and operations reveal new requirements. But it clarifies why deployment cannot be reduced to one function.
Deployment is not merely sales. A contract does not create use.
It is not merely implementation. A system can be installed without changing performance.
It is not merely procurement. A compliant purchase can still produce a poor operational result.
It is not merely regulation, change management, customer success, or operations.
Deployment is the complete system that connects capability to sustained use.
Many organizations are optimized around only one or two links. Researchers create capabilities. Companies build products. Procurement teams run compliant processes. Integrators connect systems. Operators keep them functioning.
The deployment problem often lives in the gaps between them.
Government technology has a name for one of these gaps: the valley of death. Many companies receive prototype funding and prove that a capability works, but never reach a production contract or sustained program. The technology does not necessarily fail. The transition system does. A funded prototype can die between demonstration and fielding because budgets, requirements, ownership, contracting, and operational adoption never align.
What UNIT taught me
I co-founded UNIT Innovations and spent approximately a decade building and deploying technology in government and correctional environments.
Those environments made the deployment problem difficult to ignore. A sound product could still fail because it did not fit the operating environment. The buyer was often not the user, and the user might have had little influence over selection. A simple demonstration still had to survive existing policy, staffing, hardware, security, reporting, and accountability structures.
Reliability mattered more than novelty. A feature was useful only if it worked during an ordinary shift, under imperfect conditions, with real users, limited time, and consequences for failure.
Institutional constraints could not be dismissed as resistance to innovation. Some existed for good reasons; others were outdated. Most were embedded in workflows that could not be replaced by announcing a better interface.
What mattered was not whether the technology was possible. What mattered was whether the surrounding institution could absorb it.
This changes how a product gets built. The workflow becomes part of the product. Implementation decisions become product decisions. Training, trust, accountability, and operational fit affect outcomes as much as technical architecture. The useful question is not, “Does the software work?” It is, “Can this system be made to work repeatedly here?”
At UNIT, that sometimes meant designing against the ways an operating workflow could be gamed. We added a 60-second kick-out timer and other controls that made it harder to game the system and helped ensure required checks were completed on time. The feature was not technically glamorous. It mattered because the software had to support the real operating standard, not merely record an idealized workflow.
The experience also revealed a basic asymmetry in technology markets. Product teams can see the future state clearly because they live inside the new capability. Operators see the transition cost because they live inside the current system. Both perspectives are rational. Deployment requires designing the bridge between them.
Government acquisition as deployment infrastructure
Government provides one of the clearest examples of the deployment problem. Public institutions often have significant needs, available budgets, and access to strong commercial technology. Yet the machinery connecting those ingredients is slow, fragmented, and difficult to navigate.
An operational need must become a requirement. Budget, acquisition, contracting, security, integration, staffing, and program ownership must align. Failure at any point can separate money from capability.
Acquisition is not merely administrative overhead. It is infrastructure through which government converts intent and money into real-world capability.
This is central to the work of GovSignals, where I serve as co-founder and Chief Product Officer. The opportunity is not simply to make paperwork faster. It is to improve the machinery connecting needs, markets, decisions, contracts, and execution.
AI can structure information, identify capabilities, compare requirements, reduce repetitive friction, and support better execution. Its useful role is to strengthen accountable acquisition professionals and operators, not replace them.
The same principle applies when bringing a team into a company. When GovSignals acquired Turingon, the deployment work was integrating the team into GovSignals with clear roles and standard operating procedures so people could operate effectively as part of one company.
The physical deployment problem
Robotics makes the same problem visible in physical form.
A robot can perform an intelligent behavior in simulation or in a controlled demonstration without being ready for dependable use in the world. Simulation can establish that a behavior is possible. It cannot, by itself, prove that the behavior will survive contact with reality.
The physical world introduces perception errors, latency, hardware variation, contact, wear, safety constraints, and environmental uncertainty. A floor, object, lighting condition, motor, camera, or network delay may differ slightly from training. Those differences compound.
A single successful run is not enough. The machine must perform repeatedly. It must recover from variation. Its behavior must be measurable. Failures must be diagnosable. The cost of evaluation must be low enough that the system can improve.
Simulation proves possibility. Reality tests capability.
This is one reason I support sports robotics research and remain interested in a broader question: what conditions would have to exist for robots to become economically widespread?
The answer is not only better models or cheaper hardware. Widespread robotics will also require evaluation systems, training infrastructure, standard tasks, reliable integration, safety processes, maintenance networks, and clear economic use cases.
Intelligence became easier to demonstrate before it became easy to operate.
Simulation-to-reality is therefore another version of the deployment problem. The invention is a policy that can perform a task. The deployment challenge is the system that makes the task repeatable on real hardware, in real environments, at an acceptable cost.
At HIM, the gap became concrete when Adam learned Nick Kosir’s dance for a live appearance at News Corp. The motion existed in simulation, but the team was still getting it production-ready on real hardware ten minutes before walking into the building. The public demonstration lasted only a few minutes. The deployment problem was everything required to make the behavior reliable enough to perform on demand, in an unfamiliar environment, at a fixed time.
Deployment compounds
The strongest argument for deployment is not that it produces immediate use. It is that deployment creates the conditions for further progress.
A deployed system encounters reality. It produces data about actual behavior, actual users, actual failure modes, and actual value. That data improves the product. Repeated use creates trust. Trust lowers the cost of future adoption. Integration creates infrastructure that can support additional capabilities. Standards emerge. Operators develop expertise. Buyers become better at evaluating what works. Vendors become better at delivering it.
Deployment compounds.
This compounding is difficult to reproduce in a laboratory. Important requirements appear only after a capability enters operations. Users behave differently than expected. Edge cases become common. Value may come from a different workflow. Some features prove irrelevant; others become essential.
A deployed capability can improve through contact with reality. An undeployed capability remains a possibility.
This also explains why institutions and companies with real operating distribution can become more important as technical production gets cheaper. When many teams can create software, models, or robotic behaviors, the scarce asset may be the system that can evaluate them, purchase them, integrate them, and make them perform reliably.
Deployment also produces institutional memory. A second implementation can reuse connectors, legal structures, training, evaluation methods, security decisions, and operating knowledge. What once required extraordinary effort can become routine.
That transition—from exception to routine—is how technology changes an institution.
An undeployed invention is still an option. A deployed system becomes an institution.
There is a danger in overstating this. Deployment does not rescue weak technology. Repetition does not make a bad product good. Some inventions are not ready, not useful, or not economically viable. But technical quality and deployment capability are complements. A strong invention without a path to use can remain irrelevant. A strong deployment system can identify, improve, and scale the inventions that survive reality.
Progress is not measured only by what can be built, but by what can be made to work repeatedly.
What should be built
If the deployment problem is becoming more important, then a larger share of technical and institutional effort should focus on the systems around invention.
We need better evaluation before and after purchase; better integration between new technology and existing operations; better ways to establish trust without freezing markets around incumbents; and better acquisition, implementation, reliability, and feedback systems.
We also need organizations designed to scale proven capability rather than merely announce it.
This does not imply that every valuable company will be a “deployment company,” or that invention will become less important. The most valuable systems may combine both: strong technical capability with an unusually effective path into real operations.
The agenda is broader than software. Government may need new acquisition infrastructure. Robotics may need shared evaluation environments and sim-to-real systems. Other fields will require different forms of trust, integration, regulation, financing, and workflow change.
The common question is the same: what must be true for this capability to work repeatedly in the real world?
That question should shape product design earlier. It should shape investment decisions. It should shape how governments modernize. It should shape which technical bottlenecks receive attention.
The next phase of progress will not come only from producing more intelligence, more software, or more machines. It will also come from improving the institutions that decide what to use and the operating systems that make use possible.
Conclusion
A decade ago, I was interested in the gap between the technology society possessed and the technology many institutions actually used. That gap remains, but its structure is clearer now.
Invention creates possibility. Deployment converts possibility into performance.
My goal is to build the systems through which research, products, and capital become broadly useful. That means taking discovery, trust, acquisition, integration, operations, measurement, and improvement as seriously as the initial breakthrough.
We will continue to invent faster. Whether that produces corresponding progress will depend on whether we become equally serious about making invention work.