Make It So: The New Operating Model for Software Teams

So if the layoff story is mostly over-hiring correction, software demand is still climbing, and AI just collapsed the cost of building, what does the new operating model actually look like?

It looks a lot like the bridge of the Enterprise.

Picard sits on the most powerful ship in the fleet. The Enterprise can simulate any system, recall any record, run any probability calculation, fold space at warp nine. Picard never writes a line of code. He never fights an engine, never runs a sensor sweep, never pilots through an asteroid field. His job is to absorb the recommendations of his crew, weigh them against the situation, and make the call. "Make it so."

That's the new operating model for a software team. It is not a metaphor for the model. It is the model.

The bridge crew is small. Each seat has a domain. Worf runs tactical: security, reliability, the things that absolutely cannot fail. Geordi runs engineering: the platform, the infrastructure, the deep technical interior of the ship. Riker is the executive officer: the doer, the manager, the person who turns the captain's call into action. Each of them is irreplaceable in their own domain because each of them brings judgment to that domain. None of them are doing rote work. The ship's computer absorbs all of that. The crew exists to make the calls the computer cannot.

Now the same picture, in a 2026 software org.

The captain becomes the Project Lead — the editor-in-chief, the person who decides what the team is building and why and for whom. Worf becomes the Product Owner, the customer's voice in the room, asking what the model missed: which edge cases, which user contexts, which parts of the actual job-to-be-done that the spec quietly skipped over. Geordi becomes the Senior Software Engineer, but doing the work senior engineers always wanted to do: system design, architectural judgment, making sure the integration actually holds when the agents have shipped a thousand small pieces of code. Riker becomes the Product Designer, and this is the role that changes the most. The designer who used to spend most of the week moving pixels around in Figma now spends that time talking to customers, watching them work, and translating "make it so" into workflows that solve real human problems. Data is, fittingly, the AI agent layer itself.

What's striking about this team is that every human on it is now working at the top of their license. The senior engineer isn't writing boilerplate; they're making the call on architecture. The designer isn't moving rectangles around in Figma; they're sitting with customers and watching them work. The product owner isn't transcribing requirements; they're spotting what the model missed. The project lead isn't herding tickets; they're making editorial calls about what's worth shipping. AI absorbs the lower-leverage work in each role, and what's left is the part of the job that requires judgment, taste, and human context. That's the upside that gets buried under the layoff headlines.

There's one more character on the bridge worth pausing on, and it's the most important one for our purposes. Lieutenant Commander Data is an AI. He is, in raw computational terms, the most capable being on the ship. He can run more probabilities, recall more records, and process more sensor data than every other crew member combined. And he defers, every single episode, to Picard's command. The reason isn't deference for its own sake. It's that the things Data can't do (humor, intuition, ethical judgment, the why question, the moral weight of a hard call) are exactly the things a captain has to bring. Data is the AI character done right: not a rival, not a replacement, but a teammate whose enormous capability becomes meaningful when it's paired with humans who fill the gaps. That's the partnership model we're building right now, not us against the machines but us with the machines.

What you'll notice across all five seats is that they meet at the customer. The senior engineer's architectural calls are now informed by direct exposure to the user's workflow, not just the spec. The designer is in the customer's office, not just in Figma. The product owner is doing real qualitative research, not just grooming a backlog. The project lead is closer to the user than any single domain expert, because the editorial calls require the full picture. AI didn't blur the disciplines into one mush. It freed each practitioner to actually do the parts of their discipline that always mattered most, and those parts converge on the human being you're trying to help. The new senior skill, the one I'd bet on hardest if I were hiring today, is the ability to ask "why are we building this for this person?" earlier and more clearly than anyone else in the room. Soft skills became hard skills the moment the rote work got cheap.

Why This Wasn't True Five Years Ago

The bridge crew model isn't new in the abstract. Captains, generals, surgeons, executive chefs, orchestra conductors: humans have organized small teams around a single accountable decision-maker for a long time. What's new is that this model now works for software teams that ship code, which is something that has never been true before.

Why? Because the economics changed. I've called this the semiconductor product theory in past writing.¹ A new tool only drives adoption when the improvement is large enough to justify the cost of changing habits; the activation energy required to push an electron from a low state to a high state has to clear the gap, or nothing changes state. For most software workflows, custom-built tools were maybe a few percent better than the spreadsheet, occasionally 20% on the high end, at a hundred times the cost to build and maintain. The activation energy never cleared. Organizations stayed on Excel because Excel was the rational choice.

AI changed the math. The implementation cost of purpose-built software collapsed. The improvement over Excel jumped from a few percent to an order of magnitude. The activation energy finally cleared. Adoption follows.

Baumol, Inverted

For most of software's history, building software behaved like the service-industry side of William Baumol's "cost disease."² The labor was the product. Engineers were expensive. The cost of producing a feature was high and rising. The non-scalable input (people who could write code) tracked broader wage growth, so the cost of building anything in software kept getting more expensive even as the rest of the economy got more productive.

AI inverts this. Software production is now scaling like manufacturing. Cost per unit of output is collapsing, and it's collapsing fast. The constraint that used to bottleneck every product team (not enough engineers to write all the things we wanted to build) is loosening dramatically.

What stays expensive in this new world? Not the implementation. Implementation is approaching free. What stays expensive is the judgment about what to make. The human call on which problem is worth solving. The customer empathy that lets you see a workflow nobody else sees. The taste to know when a feature is good enough, when it's overshot, when it's just adding noise. The product instinct to recognize that the agent has built the thing perfectly to spec, and the spec was wrong. Those things don't get cheaper when AI gets better. If anything, they get more valuable, because there are now ten thousand more features being built by ten thousand more teams, and the bar for "is this any good" is rising as fast as the volume.

This is what I mean by Baumol, inverted. The classical disease said costs rise in non-scalable sectors because the scalable sectors got cheap. The inverted version says: in a world where the scalable thing has gone radically cheap, the non-scalable thing isn't a cost burden. It's the most valuable input you have. Time spent making the right call is now worth more, not less, than it was five years ago. Time spent fighting syntax is worth nothing, because the syntax-fighting just got automated.

Whose Neck Is On The Line

Every bridge needs someone in the captain's chair, and the captain's chair has a name on it. Not "the model." Not "the agent layer." A name. A face. A person who can be praised, blamed, promoted, fired.

A car company doesn't get to say "the assembly robot did it." A hospital doesn't get to say "the diagnostic system did it." Whatever happens inside the building, the person whose name is on the door is answerable. The next decade of software products will be built by humans directing AI agents that ship code, write copy, send emails, charge credit cards, and make decisions on behalf of customers. Some of those decisions are going to be wrong. Some are going to cause real harm. Some are going to land in court. When that happens, "the model decided" isn't going to be a defense. It's going to be evidence of negligence.

This is the structural reason humans stay in the loop. Not because the work is too hard for AI to do; AI is going to do most of the work. The structural reason is that only a human can be held responsible. You can't sue an LLM. You can't fire a model. You can't praise an agent at the company all-hands. Responsibility is a property that only attaches to someone with skin in the game: a name, a face, a paycheck, a reputation, a license, a future. The agent doesn't have any of those things. The editor-in-chief does.

That's the role we're all sliding toward, regardless of title. Designers, developers, project managers, founders: every one of these people is going to wake up in a few years and realize that their actual job is to be the editor-in-chief of work made by their agents. They review. They approve. They override. They sign their name to it. They take the call when something breaks.

The deeper version of this argument (where the responsibility gaps are, how the law is starting to catch up, what professional ethics looks like in an AI-augmented practice) is its own essay, and I'm working on it. Responsibility Gaps, coming soon.

The operating model is clear. The bridge crew is small. Each seat brings judgment in a domain. The agents handle the rote work, and the humans absorb the consequences. That's the partnership.

The question this whole series started from is now sharper: if this is the new operating model, how do you actually win in it? Especially if you're early in your career, watching the headlines, wondering what the play is. That's Part 3.