# From today to tomorrow > What an engineer, an analyst, a product manager, a manager, a director, a VP, an SVP and the C-suite each change into in an AI-accelerated company, and what... Updated: 2026-09-06 · Author: Alan Wizemann What each level of the company changes into. Two things are true of every row: the person often does not change, the job does, and the discomfort is concentrated in the middle, among the people whose work was coordination, prioritization and translation – who are also the people the model most needs, in new form. A few words do a lot of work below, and they are worth a sentence each. A card is one outcome, big enough to matter to the executive team and small enough for one team to ship. The board is the single board of work where every card sits (not the board of directors), which is how the company sees who is waiting on whom. A shared piece of the company – the customer, the order, the product; I call it a primitive – is a thing one team owns and everyone else builds on, and the catalog is the company's own list of everything it has built, who owns it and who uses it. A balance metric is the promise that fixing one thing will not quietly break another, a spend envelope is a team's people, tokens and cloud in one visible number, and the control plane is the small central group that owns the standards, the permissions, the visibility and the money across all of it. ## Engineer: From code author to builder or steward ### Today Sits in a central engineering organization, receives requirements, works in sprints, writes and reviews code. Identity is craft: the code is the work. ### Tomorrow Directs agents that write the code and judges whether what was built is right, not just whether it works. Either a domain builder embedded in an ownership team, or a primitive steward who owns a shared piece of the company – its data, contract, security and history. Deep engineering still exists; it is scarcer and more valuable than before. Lets go of: Code authorship as identity; the sprint rhythm; being the gate between the business and what gets built. Measured on: Outcomes live and in use; consumers of what they build; balance metrics held; spend within envelope. ## Domain professional: From requester to builder ### Today The analyst, the operator, the specialist who never wrote code. Knows the domain better than anyone, and gets things built by writing a request and waiting a quarter. ### Tomorrow Given a safe place to build and permission to build on the data they can already see. Starts with personal things (a report, a view, a small agent); the first time something they built is promoted to shared and someone else improves it is the moment the model becomes real. Often the person who understands what "done" means, because they are the user. Lets go of: The request-and-wait posture; private tools nobody can build on. Measured on: Outcomes shipped; shared things others consume; balance metrics held. ## Product manager: From requirements to ownership ### Today Interviews stakeholders, gathers requirements, writes the spec, orders the backlog, negotiates the roadmap, and represents each side to the other. ### Tomorrow The requirements ritual evaporates, because the stakeholder and the builder are now one team. What remains is the part that was always the point: knowing what the outcome should be, judging whether what was built achieves it, and holding the metric. Becomes the domain owner or ownership team lead – or, in the control plane, the owner of the board and the standard for what a card is. Lets go of: The spec; the backlog as the unit of work; the roadmap; translating between two sides that are now one. Measured on: Outcomes live; metrics held; consumers of the domain's shared things. ## Manager: From coordinator to owner ### Today Coordinates: status, resourcing, dependencies, the sprint, the roadmap slice. Translates, negotiates for capacity, reports upward. Measured on keeping the team busy and the stakeholders calm. ### Tomorrow The coordination work evaporates, because the board does it and the daily build review replaces the status meeting. What is left is ownership, and the manager either steps into it or does not. The ownership team lead owns a set of outcomes end to end, runs the daily build review, owns the team's spend envelope, and develops builders rather than allocating them. This is the level where "the person changes, not the title" is most tested. Lets go of: Status reporting; resource negotiation; coordination meetings; being needed as a translator. Measured on: Cards shipped live; outcome and balance metrics; spend within envelope; reuse of what the team publishes. ## Director: From portfolio manager to domain leader ### Today Runs a function or several teams, prioritizes a portfolio against a budget line, manages stakeholders, approves things: gates, reviews, exceptions. ### Tomorrow Prioritization becomes ordering cards on the board, which is faster and more visible. The program office dissolves into the board's dependency chains. Becomes the leader of a domain organization (Product Lifecycle, Customer, Order) with the primitives, the ownership teams, the spend envelope and the outcomes beneath, or a control-plane lead owning one of its five jobs company-wide. Lets go of: Functional turf; headcount as power; approval gates; the program office. Measured on: Domain capability growth – consumers of its primitives across the company; domain outcomes and balance metrics; spend envelope. ## Vice President: From function head to domain executive ### Today Runs a large function with its budget, its org design and its quarterly planning, and negotiates with the other functions. Technology is something another VP provides. ### Tomorrow The function is re-aligned around the things it actually operates on: the sales leader now also owns the CRM and customer support, which used to sit under IT and finance. The domain executive owns one or more domains completely – people, primitives, agent units, spend – and sits on the governance body, deciding often and without politics against the vision and the guardrails. The largest personal change on this page, because the function that defined the title is the thing being re-aligned. Lets go of: "IT does that"; annual and quarterly planning; the requirements handoff; the function as identity. Measured on: Domain outcomes and balance metrics; company-wide reuse of the domain's primitives; spend; speed from idea to live. ## Senior Vice President: From program sponsor to orchestrator of a unit ### Today Runs several functions or a business unit with a P&L. Sponsors large programs, owns long-range planning, chairs steering committees, arbitrates between functions. ### Tomorrow Sponsors the proof – the first domain, the first card, the quarter of patience – and stands up the governance body for the unit. Then runs the division or region as a fractal of the whole, with its own board and its own domains rolling up to headquarters, allocating spend envelopes to domains rather than budgets to functions. Lets go of: Steering committees; program reviews; annual budget negotiation; arbitrating between functions that no longer exist as such. Measured on: Capability growth of the unit; outcomes and balance metrics across its domains; overhead reduction; experimentation rate. ## The C-suite: From executing strategy to orchestrating capability ### Today Sets strategy, runs the function heads, negotiates the annual budget, and spends most of its time on execution and speed: why is this late, what is blocking that. Adopts AI function by function, because that is how requests arrive. ### Tomorrow Grants the four things asked of a chief executive (the approach, the patience and money for the proof, a few people under a new leader, and an agreement about what follows success), names the transformation leader, and becomes the governance body. Decides what goes on the board and in what order, governs often on evidence, reads the registry to understand how the company actually works, and worries about capabilities rather than speed. Each seat has a specific version of this: the CEO owns the vision and guardrails the platform checks against, the CFO the spend envelopes and metering, the CTO or CIO runs the operating system rather than a department, the COO finds that the board is the operation, and the CHRO owns the new roles, the ownership training, and the identity system that is now the permission system. Lets go of: Speed anxiety; status decks; the annual technology budget; function-by-function AI adoption; the CIO as advisor. Measured on: Capability growth; speed to market; experimentation rate; overhead reduction; balance metrics held company-wide. ## Roles that do not exist yet Four roles appear in this model that most companies do not have. They are where "hire a small number of people who can lead and understand this" actually lands. The transformation leader runs the control plane through the change – discovery of the domain architecture, the choice of the first card and the first domain, the change management for leaders taking ownership. That person reports to the chief executive, almost certainly as a hire or an interim, because the role requires having seen this work. The domain owner is the director- or VP-level leader who accepts sole ownership of one of the things the company operates on, usually an existing leader with a changed remit. The primitive steward is the technical owner of a shared piece of the company (its data, its contract, its security, its history and its consumers), drawn from the best of the current engineers and data people. And the domain builder is the person, engineer or not, who turns a domain owner's intent into working things daily. That is mostly existing people, trained in ownership and in directing and judging what agents build. ## Careers, promotion and pay The ladder in the old model was headcount and budget: you rose by managing more people and more money, and neither means much when building is abundant and spend is metered. The ladder in the accelerated organization is scope of ownership and dependence – what you own, how many outcomes it produces, how many teams and units consume what you publish. The catalog reports all of it, which means promotion cases stop being narratives and start being evidence. None of this is cosmetic, and I would not raise it if it were. Every transformation I have run changed titles, structures and reporting lines, and pushed ownership and responsibility to a lower level than the organization was used to, with new titles to match. Managers rarely lost status when they lost headcount, because status now came from what they owned. The message to everyone from the first day was the one that has proven cheapest and truest: we are looking for the people already here to rise to this, and we will train them, because finding them inside always costs less than hiring them. ## What the organization evolves into The company does not jump from the first column to the last. It moves through stages, and each one is stable enough to live in for a while. It starts functional and quietly accelerating: the inherited org chart, with people building on their own in every department and the risk rising invisibly. Then it stands up a first domain with one card, one board and one daily build review, while everything else continues as before, and domains multiply from there as the next cards pull them in. Leaders keep their titles while what sits under them changes, the central engineering organization shrinks into primitive teams and the control plane, and budgets become spend envelopes. Eventually the company is run on the board, with domain organizations of human and agent units side by side and a governance body of the C-suite or its direct reports. The org chart looks like bubbles connecting everywhere, and the catalog is the truer picture. The honest note belongs here too. The earliest of those stages is simply where most companies already are, and the two that follow I have lived in pieces and in pre-AI form, across the transformations behind this work. The last one is the destination the model describes, and it has not yet been run end to end at scale. This map is a description of where the road goes, and the proof is how a company finds out whether it wants to travel it – a decision I would rather you make with a working example in front of you than with a document. --- Canonical: https://alanwizemann.com/accelerated-organization/role-map