From a Team of One to a Defense AI Program: Building ORBIS's AI Department

In August 2020 ORBIS had no AI capability: no team, no standards, and no delivery record. I started the department as its only engineer. By the time I left in January 2026 it was a core team of ten engineers working inside programs of more than thirty people, spanning company departments, contract subject-matter experts, U.S. Navy and DoD sponsors, submarine-construction shipyards, a university partner, and companies in the United States and abroad.

The ten engineers were the center of the work. Most of what made it hard, and most of what made it succeed, happened in the relationships around them.

The scope was an ecosystem

A defense AI program has more stakeholders than an org chart shows. Our models went into products other engineering groups owned, were fielded by operations teams, were validated by experts the company brought in by contract, and were reviewed by government sponsors who had to defend the decision to use them. Business development turned results into proposals and pitches, and company leadership funded the department one decision at a time.

Leading at that scale meant my job was mostly translation and alignment. The project managers running each program worked under my direction, so I was leading leaders as well as engineers. I worked directly with the C-suite on strategy, funding, and headcount, briefed customers and audiences of up to 200 people, wrote technical proposals, coordinated contractors under the same standards as the core team, and made sure engineers heard requirements directly from the people who held them.

How it grew

Growth came in four overlapping phases, and each one changed what the department needed from me. In the first I was the engineer. By the last I was setting direction across concurrent programs and representing the work to the Navy, partners, and prospective customers.

The defect-recognition program carried the most visible numbers: three consecutive DoD contracts worth about $7 million and approval for integration into submarine-construction shipyard workflows. It ran alongside additional multimillion-dollar DoD programs in image segmentation, anomaly detection, predictive analytics, and maritime sensor analysis, a ship-state forecasting platform, and locally secured language models for environments where cloud AI was not allowed.

Hurdles, and what we did about them

Every result on this page started as an obstacle. These are the ones that shaped the department most.

What servant leadership meant in practice

I built the department around servant leadership: the leader owns the conditions around the work so capable people can exercise judgment on consequential problems. In practice that came down to a handful of mechanisms.

• I owned the environment. Priorities, resources, customer alignment, and organizational friction were mine. Engineers owned their areas and were expected to explain their assumptions, test their conclusions, and surface risk early.
• I led leaders, not only engineers. Project managers ran the day-to-day of each program under my direction. They needed different things from me than engineers did: clear decision rights, cover with the customer, and early notice when priorities changed.
• Engineers saw the whole problem. They met the customer, learned the existing workflow, and knew what failure would cost. An engineer who understands the mission can tell when an elegant solution creates operational friction.
• I hired for range. Applied AI crosses data acquisition, evaluation, software integration, security, and domain validation. Engineers with depth plus range could follow a problem across layers instead of handing it off.
• Research time was protected and justified. About a third of capacity went to research without an immediate customer. I documented how those experiments became funded programs so the allocation survived budget reviews, and that research produced the copyrighted IP that became the company's main research revenue engine.
• Headcount followed delivered value. Each hire expanded something customer-funded programs had already proven, which kept leadership's trust and gave every new engineer meaningful work on arrival.
• Failures were reviewed as systems. When something went wrong we examined the data, requirements, architecture, and decision path. Fixing the mechanism kept people willing to report uncertainty early.
• Everyone taught. Engineers taught each other and learned from the domain experts, which spread expertise and reduced dependence on any one person, including me.

Standards before the team needed them

As the core team approached ten and programs passed thirty people, shared context stopped being enough. Evaluation practices, deployment requirements, security controls, and architectural decisions had to be written down so they did not depend on the conversations where they started. I also deliberately developed other leaders inside the team, so several people could make sound decisions, brief stakeholders, and carry a program forward without me in the room.

What it added up to

• A department founded by one engineer, grown to ten core engineers, leading programs of 30+ across departments, contractors, and government partners.
• Three consecutive DoD contracts on defect recognition, about $7 million, plus additional multimillion-dollar DoD programs.
• DoD approval for integration into submarine-construction shipyard workflows, and inbound requests from commercial organizations to deploy the technology.
• Copyrighted AI and machine-learning IP that became the company's primary research revenue engine.
• About $10,000 in hardware cost removed from every maritime unit sold, and a three-year university STEM program with $80,000 in initial revenue.
• A 5 out of 5 performance rating in each of five consecutive years.

The model I would bring to the next organization is the one described here: earn scope with delivered evidence, put engineers in direct contact with the people who hold the requirements, write the standards down early, and build a team that can run without its founder.