The seam was always there.

The org chart most of us are recruiting into right now was designed for a kind of work that no longer arrives.

Strip the tools and the skills out of a team's charter and look at what survives. For most security teams nothing survives, and that is the finding, because a charter that goes to zero under that constraint was describing a capability all along and never once described an obligation.

Security org charts mostly inherit decisions somebody made about thirty years ago. Split the work by what a person has to know. Put the firewall people together because firewalls are their own body of knowledge, put the identity people together for the same reason, and let each group get deep. That logic was correct. It was correct because work in that era arrived as tasks, tasks are knowledge shaped, and the fastest way to finish a task is to hand it to the group that already knows how.

The model then survived four platform shifts without anyone seriously reopening it. Client server, virtualization, cloud, SaaS. Every one of them changed the tools inside the boxes and left the boxes exactly where they were. The boxes felt permanent because they kept working, and they kept working because one assumption underneath them kept holding, which is that execution was the expensive part and expertise was the thing that made execution cheap.

AI did not break the boxes. It broke the assumption.

When an agent runs the task, execution time falls toward nothing. What does not fall is the time work spends crossing a boundary. A handoff still needs a ticket, a queue, somebody with context on the sending side, somebody willing to accept it on the receiving side, and a meeting when those two disagree about where the scope actually ends.

Every one of those costs was already there. They just used to be a rounding error against a number the work itself dominated.

Now they are the number.

This is where the seam shows up, and the seam was always there. Responsibility for an outcome has to stop being somebody's job at the exact point where two skill groups meet, because that is what a boundary is. For thirty years that cost almost nothing, since slow work leaves enough slack for a person to notice the gap and route around it socially.

Somebody walks down the hall. Somebody remembers who to call. The organization papers over its own design every day and nobody writes it down as a defect, because the fix arrives faster than the problem does.

Speed removes the hallway.

I have watched that particular gap open between the same two groups more times than I can count. Both of them are staffed correctly against their own charter. Neither charter contains the outcome, so the outcome lives in the space between two documents that are each internally consistent and each silent about the thing that matters. For three decades that stayed survivable, because the work moved slowly enough that two competent people could close it by knowing each other. A social fix for a structural defect works fine until the day it has to work inside an afternoon.

Now put an agent in that space and watch what it does. The agent holds the access, because it runs on the infrastructure side where the access lives. It executes in seconds. The judgment about whether it should have executed sits on the security side, which cannot see the action and has no hands on the system where it happened.

Nothing about the seam got wider. The thing crossing it got enormously faster, and a gap you used to close with a phone call is now a gap that closes after the fact or not at all.

That is the collision worth naming. Durable business value on one side, a skill model built thirty years ago on the other, and the velocity of AI is what finally put them in the same room. Skill aligned models cannot move fast enough now. Product aligned models are self contained enough to move at the speed of what AI is doing, and that is the entire argument.

A team's delivery speed is set by how many boundaries its work has to cross, not by how fast the people inside it work. AI collapsed the work and left the crossings untouched. So the crossings are the delivery time now, and a model optimized for depth inside a box is optimizing the part that stopped costing anything.

Call it the crossing cost. Nothing else in a security program got more expensive this decade while everything around it got cheaper, and almost nobody tracks it, because it never appears on an invoice and no tool reports it.

It shows up as human frustration first. Then as variation in results and tactics between groups that are each doing their own job correctly. Mostly it shows up as business value arriving late, and often enough as business value that stalls outright and never arrives at all.

Software organizations hit this first and worked through it in public, which is why the answer already exists and security never went and got it. The QA department, the DBA group, the release engineering team. Every one of them was defensible on skill grounds, every one of them held genuinely scarce expertise, and every one of them dissolved anyway once continuous delivery made the crossings cost more than the specialization ever saved. The skills did not go away. The skills walked into the product teams and stayed there, attached to a thing that persists instead of to a box that describes what somebody knows.

Product organizations landed on durable, persistent teams for exactly this reason, and the word carrying the weight is durable. A staffing arrangement dissolves the moment its project closes. A durable team is supposed to outlive the technology it happened to be standing on when somebody chartered it, the same way a well designed asset is supposed to outlive the engineer who specified it. That property is the whole reason the disruption of building one is worth absorbing, and it is the property a skill aligned box has never had, because a box named after a body of knowledge dies with the body of knowledge.

Now the uncomfortable part, and it is worth sitting in it, because this is where most people reading recognize their own program.

The skill model is enormously appealing and almost none of the appeal is about effectiveness. It is legible, and it maps cleanly onto certifications, onto career ladders, onto how people introduce themselves at conferences, onto the search filters a recruiter actually uses.

You can write a requisition for a detection engineer and several hundred people will know within four seconds whether the word describes them. Try writing one for a person who owns the security outcome of a payments platform across whatever domains that outcome touches, and watch what comes back through the pipeline.

The skill model is easy to staff, easy to budget, easy to defend in a board meeting where somebody asks whether you have application security covered. Durable ownership gives you none of that and it is still the right answer.

What it costs the business shows up in how people talk to us. Somebody on the business side put it to me plainly: "I need a solution that meets my needs, not an overly opinionated perception of why my need is wrong."

Read that as a complaint about attitude and you will miss it. Route one need through five skill boxes and you get five opinions, each correct inside its own domain and none of them holding the outcome, so what comes back is an argument rather than an answer. The structure produces the opinions. Nobody in those boxes is being difficult.

The wrong version of this goes one of two ways, and both are common enough that you have probably seen them. The first is a reorg that redraws the chart, renames the boxes into product sounding names, and changes nothing about who owes what to whom. Six weeks of anxiety, the same seams, new labels on them.

The second one is worse and better disguised. A team gets told it now owns an outcome, and it gets exactly the same headcount, the same skills, and no authority over the three other groups the outcome actually runs through, so ownership becomes a word that means accountability without control. People learn fast from that one. They learn not to volunteer.

The version that works starts much smaller than a reorg, and I say that because I have been running it rather than recommending it. I kept the teams in skill alignment and aligned them inside a product operating model over the top. Re-drafted the charters. Covered the seams, then ran the whole result back against our security frameworks to validate completeness, because an outcome charter that quietly drops a control is worse than the skill box it replaced.

It is an increment, not a reinvent. Yet.

That sequence matters more than it looks. Leaving the skill alignment in place buys you the thing a reorg spends first, which is the willingness of people to try it, and the charters do the real work while the boxes stay where everyone can find them. Let the seams show once the charters are written. The seams showing is the point, and you want to know where the crossings actually are before you spend political capital redrawing anything.

The second order effect arrives in recruiting, and it arrives faster than people expect. Once one team has a real outcome charter, the next requisition written against it stops naming a skill slot at all. The hiring manager finally knows what the person will own. That one req reads differently to candidates, and the candidates it attracts are different people. Do that four or five times and the recruiting pattern has changed without anyone announcing a new talent strategy, which is the only way that kind of change has ever actually happened.

Two places this gets hard and neither has a clean answer. The first is the specialist who spent twenty years becoming the deepest person in one lane and reads all of this as a demotion. That reading is not paranoid. A ladder built on depth in a single domain has no rung for somebody who carries an outcome across four, and if you move the model without building the rung, you will lose the exact people whose judgment holds the outcome together. Build the rung first.

Audit is the other one. A control matrix wants a named owner per control and an outcome team maps onto that badly. You will end up maintaining a translation layer between how the work is organized and how it gets attested, and that is an honest cost to carry rather than a reason to stop.

This is the seam these models start to cover, and that is the honest case for them. A durable team with the outcome written into its charter does not have to negotiate the gap, because the gap is inside the team.

None of this needs a program or a budget or a reorg deck. It needs one sentence written under a constraint, and then the willingness to look at what the sentence exposes.

This is about changing security before it is changed.