Federal

The One-Person Product Team Is Here. Federal Programs Aren't Built for It Yet.

Coinbase is experimenting with single-person teams that combine engineering, design, and product management, backed by fleets of AI agents. The model is real. The question for federal programs is what it does to accountability, compliance, and continuity.

6 min read·October 9, 2026AIEngineeringTeam StructureDevSecOpsFederal Acquisition
The One-Person Product Team Is Here. Federal Programs Aren't Built for It Yet.

On May 5, 2026, Coinbase CEO Brian Armstrong told employees the company was cutting about 14% of its workforce and changing how it builds products. One line in his email got more attention than the layoffs:

"We'll also be experimenting with reduced pod sizes, including 'one person teams' with engineers, designers, and product managers all in one role."

He described the people he wanted to keep as "AI-native talent who can manage fleets of agents to drive outsized impact," and he capped the organization at five layers below the CEO and COO. (Fast Company)

Two weeks later, Meta moved about 7,000 employees into new AI-focused groups ahead of cutting roughly 8,000 jobs. Its chief people officer described the new structure as "flatter," with "smaller teams." (Bloomberg via The Star)

This is no longer a fringe experiment. The default size of a product team is shrinking, and at the edge it is shrinking to one. For anyone who builds or buys software for the federal government, the useful question is not whether this is coming. It is what has to be true for it to work, and what breaks when it doesn't.

What Actually Changed

Product organizations split into product managers, designers, and engineers for a reason: producing specs, mockups, code, and tests was expensive, so it was cheaper to have specialists produce them and pay the cost of handing work between people.

AI agents collapse the cost of producing those artifacts. A capable engineer can now draft a requirements outline, generate interface options, write the code, and scaffold the tests in an afternoon. The handoffs that justified three roles start to look like overhead.

But a one-person team is not three jobs merged into one. It is one person's judgment directing many producers. What stays scarce is knowing what to build, recognizing when the output is wrong, and being willing to put your name on it. As we argued in Hire a Person, or Give Your Best Engineers More Tokens?, AI is a multiplier, and it multiplies whoever it is applied to. The one-person team only works when that person already has senior judgment across all three disciplines.

Where It Works

The model is strongest when the work is well bounded and the surrounding platform does the governing:

  • Internal tools and workflow automation with a clear owner and a small user base
  • New features inside an established product with a mature design system and test suite
  • Prototypes and proofs of concept, where speed matters more than durability
  • Modernization tasks with a defined target, such as migrating a known workload

In each case, much of the work the missing roles used to do has moved into the environment: pipeline checks catch what a second engineer would have caught, the design system enforces what a designer would have enforced, and the backlog structure carries what a product manager would have tracked.

Where It Breaks

Strip a team to one person and four problems show up quickly.

The review ceiling. One person can only responsibly review so much agent output. Past that point, more agents produce more unreviewed code, not more value. The bottleneck moves from writing to reading.

A bus factor of one. When the only person who understands a system is on leave or leaves the company, the knowledge goes with them. A chat history with an AI assistant is not documentation.

Separation of duties. Federal security controls assume the person who writes a change is not the only person who approves it. NIST SP 800-53 includes separation of duties (AC-5) for exactly this reason, and configuration management controls expect reviewed, authorized changes. A true team of one cannot satisfy that on its own.

Quality nobody owns. Accessibility, usability, and plain-language content are easy to skip when no one's job is to check them. Section 508 conformance does not review itself.

The Federal Mismatch

Most federal IT contracts still staff by role. A typical staffing plan names a program manager, engineers, and a UX designer as separate labor categories, each with its own qualifications, and time-and-materials orders bill hours against those categories. A one-person team that does all three jobs does not map cleanly onto that structure, and key personnel clauses make it harder still.

Outcome-based contracting changes the equation. On a firm-fixed-price task order, the agency pays for the result, and the contractor decides the shape of the team that delivers it. As small, AI-assisted teams become normal, expect evaluations to shift from how many people a vendor proposes to what evidence it can show: pipelines that enforce security and accessibility checks, test coverage, authorization artifacts, and documentation the government can keep.

For contracting officers and program managers, that is the real implication. Headcount stops being a reliable proxy for capacity. Evidence of governed delivery becomes the better one.

What Makes Small Teams Safe

Coinbase is right that teams are getting smaller. In our experience delivering federal platforms, four practices decide whether a smaller team is an advantage or a liability:

  1. Put governance in the platform, not the people. Security scanning, SBOM generation, automated 508 testing, and controlled container promotion should run as pipeline gates that no team, however small, can skip. Then a smaller team inherits the controls instead of having to remember them.
  2. Build alone, ship in pairs. One person can own a product. Production-bound changes still need a second set of eyes. A two-person rule for release keeps separation of duties intact without rebuilding the old org chart.
  3. Write the handoff as you go. Runbooks, architecture decision records, and recorded walkthroughs should be deliverables, produced continuously. Agents can draft them. A person should approve them.
  4. Staff for continuity. The smaller the team, the more every departure costs. Keeping the same people on a mission matters more in a team of two than in a team of twenty.

The Bottom Line

The one-person product team is a real shift, and federal programs will feel it through outcome-based contracts before they see it in staffing plans. It works when the platform carries the governance and the person carries the judgment. It fails when speed outruns review, and when everything the team knows lives in one head.

The smaller the team, the more two commitments matter: build systems the government can own after you leave, and keep the people who built them on the mission. Built to hand off. Staffed to stay.

Related resources

Sources

Back to Insights