A client committed to refreshing its entire product ecosystem: a dozen interconnected products, hardware through firmware through a software platform, rebuilt in twelve months, converging on one date. The structure carrying that load was the one built for the running business. A functional hierarchy, lightweight project coordination, and the same organization supporting released products in the field with long service cycles. Ownership was unclear, decisions queued in the hierarchy, and the projects drifted. The question was never whether the people could move faster. It was whether the structure would let them.
The hardest development programs are no longer single products. Companies now commit to ecosystems and platforms, and an ecosystem is a harder thing to build than a product: a dozen concurrent projects, each with its own technical risk and its own dependencies on the others, all with one public date. Measured against Steven Wheelwright’s research at Harvard on the four forms of development organization, most established companies bring the first two forms to that commitment: the functional hierarchy, where work lives in the functions and no one is accountable for a project end to end, and the lightweight team, where coordinators report progress without the authority to change it. Every decision of consequence travels up a function, across the organization, and back down. That path length, multiplied across a dozen projects, is the program’s real schedule risk. Speed rises left to right across Wheelwright’s spectrum, and so does ownership.
The proposal: move the program outside
Our proposal was the fourth form, the one Wheelwright’s spectrum ends on and the one lateralworks has run since 1988: a fully autonomous program, chartered outside the corporate hierarchy for the duration of the mission. It is the fastest known way to organize new product development, and it is a complete organization in miniature. A Steering Arm of two or three senior executives above it, governing rather than managing. One Program Director with a direct line to the Steering Arm and every project resource reporting in, so the responsibility is real rather than nominal. A Project Triad running each project: a Project Lead who owns the plan and a Technical Lead who owns the engineering, under a Product Boss who owns what the product is. And cross-functional core teams doing the work, staffed on loan from the functions. The structure controls the definition of the product, its development, and its manufacturing through launch. It does not sell it. The running business stays with the hierarchy.
The Navy model
The operating model is the one the military has used for centuries. A sailor on a deployed ship reports to the captain of the ship for the duration of the mission. Home port and the base commander still exist, and the sailor returns to them when the mission ends. Nobody on a deployed ship radios the base to ask permission to trim a sail. Everyone on the program deploys the same way: for the duration of their project they report to their triad, and when the project completes they migrate back to their function, carrying what they learned with them. The loan is explicit. Named people, named projects, named durations. And the cultural claim buried in the mechanics is worth stating plainly: inside a functional structure, projects are jobs. This structure turns them into a deployment, and people work differently on a mission than they do on a job.
Why autonomy is speed
A program moves at the speed of its slowest decision path. Everything else is mechanics. Inside a hierarchy, information moves vertically: up for permission, across for coordination, down for direction. Inside an autonomous team, the engineer and the buyer and the firmware lead sit on the same team, and a question that takes a week to route through two functions takes an hour across a table. A team that owns its outcome also controls its work before the fact rather than reviewing it after; control systems layered on top of a program do not generate speed, they generate reporting. And the freedom compounds. We score empowerment on a five-level scale, and every level above “act, report routinely” inserts a wait into the critical path. A multi-project program makes thousands of decisions a year. Shorten the average decision by days and the delivery date moves by months. That is the return on fast decision-making, and it is the cheapest schedule acceleration available to any company.
The client’s hierarchy was not idle or badly run. It was doing its other job: supporting products in the field with long service cycles, and sustaining work is interrupt-driven by nature. A field escalation outranks roadmap work every time it arrives. The host, the functional organization that provisions programs with people and money and equipment, is measured on control and staffed for the running business, which is exactly why a dated mission cannot live inside it. Put the mission inside the host and it inherits every interrupt and waits in the host’s queue. Put it outside, with the host provisioning it, and both do what they are built for.
Eyes open
Wheelwright is candid that the autonomous form has known costs, and so are we. An empowered team can build the wrong thing faster; the Product Boss owns the definition and the Steering Arm reviews at release gates, where the voice of the customer gets its formal say. Standards and reuse can decay; the Technical Lead holds the functional thread, and the loan model returns the knowledge home. The form’s known weakness is reintegration, and the Navy model answers it by design: return to home port is written into every loan from day one. And a loan honored with a name on paper while the person keeps their old job is not a loan. The failures we have seen with this model were boundary failures, where the host reached back in. They were not team failures.
A CEO decision
The structure cannot be adopted from the middle of the organization, because its whole point is to change where authority sits. It asks four decisions of the CEO: approve it for the mission and the mission only, charter the Program Director in writing with explicit decision rights, confirm the Steering Arm and its cadence, and name the loans, because staffing is where the model becomes real or becomes theater. The charter is the ship’s commission. It is what the Program Director points to the first time someone routes a decision the old way. From a standing start the structure stands up in thirty days: week one, Steering Arm confirmed and charter signed; week two, loans named and backfill planned; week three, triads standing and baseline planning underway; week four, the program baseline reviewed and the weekly cadence running.
The model is well traveled. lateralworks ran these practices on the Philips Velo in the 1990s, and the engineering executive who led that program, Tony Fadell, carried them to Apple and built the iPod. Most recently we applied the same structure on a core display technology inside a major consumer AR glasses program. Across more than 200 programs since 1988, the pattern holds: when the team owns the outcome and sits outside the host’s queue, it moves.
Keep the org chart for the business you have. Build a ship for the business you are trying to create. Put the team on the ship, name the captain, and let the mission run.
Related reading: Fast autonomous teams, Integrated Core Team, The Product Boss owns the product; the Program Manager owns the plan, What is the host?, The host interrupt, Freedom to act, What is the R.O.I. of fast decision-making?, and The FTTM execution system.