Your org chart is a list of skills, and the work stopped arriving in a shape a skill can own.
Seventy-eight percent of the boxes on mine name a skill rather than an outcome. Detection engineering, identity, GRC, cloud security, application security, each box holding people who know one narrow thing extremely well. That structure earned its place honestly, because the work arrived as tasks, and a task belongs to whoever knows that task best.
That logic is coming apart.
As we move from tasks to orchestration, and from deep task knowledge to making sure agents do their job right, the skill that justified the box stops being the scarce thing in the room. What the team owes the business is the only question left worth building an org around.
Watch the boundaries, because that is where this shows up before it shows up anywhere else. Security and infrastructure have run this one for as long as I have been doing the job. One team carries the obligation to protect something and holds no access to it. The other team holds all the access and was never built to protect anything, and the work falls straight through the space between them.
The seam is velocity. Agents cross and blur those boundaries now. People do not, and the mismatch is painful in a way no org chart knows how to express.
Product organizations settled this a long time ago and security never borrowed it. They build durable, persistent teams around something that persists. The team owns an outcome for years while the skills inside it turn over constantly, because the skills were never the thing being organized.
People hear "across many domains" and picture generalists, thin everywhere and deep nowhere. The teams doing this well read differently. One person carries an outcome through identity, through data, through whatever the next quarter drags in, with enough depth in at least one of them to catch an agent handling a piece of it badly. Depth still matters enormously. It just has to sit under an outcome instead of inside a box.
Most security charters cannot answer the question that actually matters, which is what benefit and outcome the team delivers for business value. They list what the team is good at instead. Read three of them side by side and you will learn which products those teams operate and close to nothing about what any of them owe the company.
Here is the part that costs real money. Recruiting runs downstream of the chart, so every requisition open right now describes a skill slot, because the chart it feeds describes skill slots, which means every month of hiring goes deeper into boxes that are already dissolving. I am holding one right now for that reason, until the model settles enough for me to re-assess what skill the role actually needs.
So, here's the MondayMove
Take one team on your org chart and write its charter as a single sentence naming the outcome it owes the business, with no tool name and no skill name allowed anywhere in the sentence. If nothing survives that constraint, you found the team to redesign first.
This is about aligning the security function as a durable product and covering the seams AI is exposing even before you recognize it.
Discussion