A company needs to enter a regulated market.
What role does it need?
A lawyer?
A product manager?
A compliance specialist?
A security architect?
A local market expert?
A data privacy professional?
A technical writer?
The honest answer is: probably some portion of all of them.
Another company needs to reduce customer onboarding from eight weeks to two.
What role owns that?
Implementation?
Engineering?
Customer success?
Operations?
Product?
Data?
No single title captures the complete problem.
A manufacturing company wants to introduce AI into its maintenance operations.
Should it hire an AI engineer?
That person may understand models but not industrial equipment.
Should it hire a reliability engineer?
That person may understand machines but not data architecture.
Should it hire a transformation leader?
That person may understand change but not model evaluation.
Again, the outcome does not require one role.
It requires a composition of capabilities.
This is how work actually behaves.
It crosses functions.
It changes as the initiative progresses.
It requires different levels of expertise at different moments.
It combines technical production, domain understanding, decision-making, communication, governance, and verification.
Yet organizations continue responding to work through roles.
A problem enters the company.
The company translates it into headcount.
Headcount becomes a job description.
The job description becomes a title.
The title becomes a search query.
Recruiters look for people who held similar titles elsewhere.
Candidates present résumés organized around previous roles.
Managers interview for fit.
Finance approves a permanent cost.
Human resources assigns a level.
Months later, the organization hires a person.
Then it discovers that the work does not fit neatly inside the role.
This is not an occasional hiring mistake.
It is the predictable consequence of using the wrong abstraction.
Roles are useful administrative containers.
But they are poor representations of work.
Roles are fiction.
Capabilities are real.
The Role Was Invented to Make People Manageable
A role is not meaningless.
It serves several important purposes.
It gives an employee a place in the organization.
It establishes a compensation range.
It defines a reporting relationship.
It creates expectations.
It supports recruitment.
It enables workforce planning.
It provides a career path.
It tells others, approximately, what the person does.
Without roles, large organizations would struggle to administer thousands of employment relationships.
The problem begins when the administrative container is mistaken for the underlying capability.
A title such as “Senior Product Manager” appears precise.
But two people with that title may possess entirely different strengths.
One may excel at customer discovery.
Another may be strong in commercial strategy.
One may understand enterprise integrations.
Another may be excellent at consumer experience design.
One may know how to lead through ambiguity.
Another may be highly effective in a mature product environment.
One may work well with AI-assisted research and prototyping.
Another may have deep regulatory expertise.
The title hides these differences.
It compresses a multidimensional human being into a standardized label.
This compression is useful for administration.
It becomes dangerous when leaders assume that the label reliably predicts what the person can deliver.
The role is a map.
Capability is the territory.
Too many organizations manage the map and wonder why they cannot navigate the terrain.
Work Has Never Respected Job Titles
Consider what happens during a serious production incident.
The organization does not begin by carefully preserving role boundaries.
It asks:
Who understands this system?
Who has seen this failure before?
Who can access the environment?
Who can identify the cause?
Who can make a decision?
Who can communicate with the customer?
Who can restore service safely?
The person who resolves the issue may not be the most senior person.
They may not have the most impressive title.
They may not belong to the team formally responsible.
They possess the capability required at that moment.
Crises reveal organizational truth because urgency strips away administrative fiction.
The same thing happens in startups.
A founder may sell, recruit, write requirements, review design, negotiate contracts, support customers, and make product decisions.
An early engineer may perform architecture, operations, security, customer support, and technical sales.
The roles are broad because the organization has not yet developed enough structure to separate them.
As the company grows, the work is divided into departments and titles.
This division creates focus and specialization.
But it also makes the organization forget that the outcome still depends on the capabilities connecting those divisions.
The work did not become role-shaped.
The company merely drew boundaries around it.
A Job Description Is a Guess About the Future
Every job description is a forecast.
It predicts that:
-
A particular bundle of work will continue to exist.
-
The bundle is large enough to justify a full-time employee.
-
One person can perform its different components.
-
The required capabilities will remain relatively stable.
-
The work belongs in a particular department.
-
The title will attract the right candidates.
-
The organization understands what it will need months from now.
Sometimes this forecast is accurate.
Frequently, it is not.
A company may hire a data scientist and later discover that the real bottleneck is data engineering.
It may hire a project manager when it actually needs an outcome owner with authority.
It may hire an AI engineer when it needs workflow redesign and domain validation.
It may hire a salesperson when the problem is weak positioning.
It may hire more developers when architecture and decision latency are slowing delivery.
The role becomes a proposed solution before the problem has been properly decomposed.
Once the person is hired, the organization becomes invested in making the role useful.
The work is then shaped around the employee rather than the employee being selected around the work.
This is expensive.
It is also unfair to the person.
They joined under one expectation and may later be judged against another.
Titles Hide Capability Gaps
Suppose a company says:
“We have a strong engineering team.”
What does that mean?
Does the team understand distributed architecture?
Can it modernize legacy systems?
Can it operate in a regulated environment?
Can it troubleshoot production incidents?
Can it work directly with customers?
Can it evaluate AI-generated code?
Can it secure cloud infrastructure?
Can it improve developer experience?
Can it communicate trade-offs to executives?
The title “engineer” answers none of these questions.
Likewise, saying “we have a marketing team” does not reveal whether the company possesses:
-
Category design
-
Product positioning
-
Demand generation
-
Brand strategy
-
Editorial depth
-
Performance marketing
-
Customer research
-
Partner marketing
-
Sales enablement
Organizations often believe they possess a capability because a department exists.
But a department is an administrative fact.
Capability must be demonstrated.
This creates a recurring execution failure.
Leadership assumes the company can perform a type of work because an appropriate role appears on the org chart.
The work is assigned.
The person or team lacks a specific capability within the role.
The gap is discovered late.
The organization blames execution.
In reality, it confused title coverage with capability coverage.
Résumés Describe Where People Have Been, Not Necessarily What They Can Do
The résumé is the natural companion to the role.
Organizations define a role.
Candidates respond with a chronological history of previous roles.
Recruiters compare titles, companies, industries, years of experience, and keywords.
This process creates an appearance of rigor.
But a résumé is an indirect signal.
It tells us:
-
Where someone worked
-
How long they worked there
-
Which titles they held
-
Which responsibilities they chose to describe
-
Which achievements can be summarized persuasively
It does not reliably show:
-
The complexity of problems they solved
-
The degree of autonomy they had
-
The quality of their judgment
-
How they handled uncertainty
-
Whether they created the result or merely participated
-
How they worked with others
-
Which capabilities remain current
-
How effectively they use AI
-
Whether their past environment made success easier
-
How their capability transfers to a new context
Two people can have nearly identical résumés and radically different abilities.
One may have designed the system.
The other may have maintained a small component.
One may have led the customer relationship.
The other may have attended the meetings.
One may have made difficult decisions.
The other may have operated within established instructions.
Titles conceal these distinctions.
Brand-name employers can conceal them further.
A prestigious company name may signal that a candidate passed a difficult selection process.
It does not prove what that person personally delivered.
A capability system should ask a different set of questions.
What outcomes has this person produced?
Under what conditions?
Which capabilities did the work require?
What evidence exists?
What was their contribution?
How was quality verified?
Which capabilities can they apply now?
That is more difficult than scanning a résumé.
It is also far more useful.
Years of Experience Are an Especially Crude Proxy
“Ten years of experience required.”
The phrase appears objective.
But what does it mean?
Ten years can represent ten years of increasing complexity, judgment, and responsibility.
It can also represent one year of learning repeated ten times.
A professional may have five years of experience but have operated across unusually difficult environments.
Another may have fifteen years but remain dependent on familiar tools, processes, and organizational support.
AI makes years of experience even less reliable.
A person who aggressively learns and uses modern tools may expand their productive capacity quickly.
Someone with a long history may become less relevant if they do not adapt.
This does not make experience unimportant.
Deep pattern recognition matters.
Judgment often comes from living through consequences.
Domain understanding cannot always be accelerated.
But the number of years is not the capability.
It is one possible signal.
Organizations use years because they are easy to count.
Capability is harder to observe.
The future of work will reward systems that can make capability more visible without reducing it to another simplistic score.
Capabilities Are More Granular Than Skills
The words “skill” and “capability” are often used interchangeably.
But capability is broader.
A skill is an ability to perform a task.
Capability includes the ability to apply skills, judgment, tools, knowledge, access, and relationships to produce an outcome in context.
A person may know Python.
That is a skill.
Can they design a reliable data pipeline for a regulated financial environment, work with incomplete requirements, select appropriate trade-offs, communicate risk, and deliver a maintainable system?
That is capability.
A person may understand digital marketing.
Can they diagnose weak demand, sharpen positioning, design a campaign, work with sales, measure results, and change direction when the data contradicts the original hypothesis?
That is capability.
A person may be able to use an AI model.
Can they determine where it is appropriate, create reliable workflows, validate outputs, protect sensitive information, and recognize where human judgment remains necessary?
That is capability.
Skills matter.
But work succeeds through capability.
The distinction is essential because AI can increasingly supply or accelerate individual skills.
It can draft.
Analyze.
Code.
Translate.
Summarize.
Generate.
The value of the human moves toward combining these tools with context, responsibility, and judgment.
Capability Exists in Context
A person is not equally capable in every environment.
Someone may perform brilliantly in a startup and struggle in a large enterprise.
Another may excel inside a mature organization and feel lost without process.
A leader may succeed when surrounded by strong operational teams and fail when required to build from scratch.
A consultant may be excellent at diagnosis but less effective at implementation.
A technical expert may perform well independently but struggle in customer-facing work.
Capability is not merely something a person possesses.
It emerges through the interaction of:
-
The person
-
The problem
-
The environment
-
The team
-
The tools
-
The authority
-
The information
-
The constraints
This is why hiring based on titles and interviews produces uneven results.
The organization tries to assess a person in isolation.
But outcomes are produced through systems.
A candidate may be highly capable yet fail because access, decision rights, management, or organizational context are poor.
Another may appear exceptional because the surrounding system is unusually strong.
A capability-based model must examine fit without reducing people to interchangeable parts.
The question is not only:
“Can this person do the work?”
It is:
“Under these conditions, with these collaborators, tools, and responsibilities, can this person help produce the required outcome?”
Capabilities Can Belong to Teams, Not Just Individuals
Some capabilities do not exist inside one person.
They exist in the interaction between people.
A product engineering team may possess a shared capability to release reliable software quickly.
No individual owns the entire process.
The capability emerges from:
-
Technical judgment
-
Trust
-
Clear communication
-
Shared standards
-
Complementary skills
-
Familiar tools
-
Effective review
-
Operational discipline
Replace one person and the capability may remain.
Replace several and it may disappear.
This is why assembling individually impressive professionals does not guarantee a strong team.
The organization has acquired individual skills but not necessarily collective capability.
Traditional hiring evaluates people one at a time.
Execution often depends on combinations.
Which people have worked effectively together?
Which strengths complement one another?
Where are the gaps?
How much coordination will be required?
Can the group make decisions under pressure?
Can it maintain quality without constant supervision?
The unit of capability may be an individual.
It may also be a pair, a pod, a team, a community, or a human-agent system.
The role model struggles to represent this.
It assumes capability can be hired one box at a time.
AI Makes Capability Even More Composite
A professional using AI is no longer operating only through personal knowledge and effort.
Their capability may include:
-
Domain experience
-
Judgment
-
Access to proprietary information
-
Ability to instruct agents
-
Ability to validate outputs
-
Knowledge of workflow automation
-
Selection of appropriate tools
-
Understanding of risk
-
Ability to combine machine output with human context
Two people with the same title and similar experience may produce very different results because one has learned to orchestrate AI effectively.
This does not mean prompting becomes the defining skill of the future.
Prompting is only one interaction technique.
The deeper capability is orchestration.
Can the person:
-
Break a problem into components?
-
Decide what should be automated?
-
Provide sufficient context?
-
Evaluate uncertainty?
-
Detect plausible but incorrect output?
-
Route work to specialists?
-
Maintain accountability?
-
Improve the system over time?
AI turns capability from an individual property into a combined system.
The human contributes judgment, context, responsibility, and direction.
The machine contributes speed, scale, pattern recognition, and production.
The surrounding organization contributes data, authority, governance, and purpose.
The outcome depends on the combination.
This makes the traditional role even less informative.
“Analyst” does not tell us whether the person manually performs every task, operates a sophisticated agent workflow, or can design the entire analytical system.
The One-Person, One-Role Model Creates Artificial Scarcity
Organizations often say talent is scarce.
Sometimes it is.
But role-based hiring can manufacture scarcity.
Suppose a company creates a job requiring:
-
Industry expertise
-
Data science
-
Enterprise sales experience
-
Product strategy
-
Regulatory knowledge
-
Team leadership
-
Excellent communication
-
Ten years of experience
The person exists mainly in imagination.
The company may spend months searching.
It may reject excellent candidates who possess most, but not all, of the requirements.
The initiative remains delayed.
A capability-based approach might produce a different design.
One internal leader owns the outcome.
A domain expert contributes several hours each week.
A data specialist handles model design.
An experienced enterprise seller supports commercial strategy.
An AI workflow performs research and analysis.
The required capability is composed rather than forced into one impossible role.
This does not always reduce cost.
It often increases precision.
The organization stops searching for a mythical employee and begins designing the execution system the outcome requires.
Role Inflation Is a Symptom of Bad Abstraction
Job descriptions tend to grow.
A role begins with a reasonable mandate.
Stakeholders add requirements.
Human resources adds competencies.
Managers add desirable experience.
Leadership adds strategic responsibility.
The final job description describes several people disguised as one.
This happens because every adjacent capability is added to the role rather than composed around the work.
Then compensation becomes difficult.
The title becomes inflated.
“Manager” becomes “Senior Manager.”
“Director” becomes “Global Director.”
“Head of” appears where no team exists.
Organizations use title seniority to attract people capable of navigating broad ambiguity.
But the title does not solve the design problem.
It merely hides it.
The person joins and discovers that success depends on capabilities, authority, and resources that were never included.
Role inflation often reflects execution responsibilities without execution architecture.
Careers Become Trapped Inside Role Ladders
Roles do not only organize work.
They organize ambition.
Employees are taught to progress from:
Analyst to senior analyst.
Engineer to senior engineer.
Manager to director.
Director to vice president.
Advancement often requires moving into management.
Status becomes associated with larger teams, broader budgets, and higher titles.
This can pull exceptional specialists away from the work where they create the most value.
A brilliant engineer becomes a reluctant manager.
A strong designer becomes an administrator.
A domain expert spends more time managing headcount than applying expertise.
The organization gains another management layer and loses a practitioner.
Capability-based careers would allow people to progress through:
-
Greater complexity
-
Stronger judgment
-
More valuable outcomes
-
Deeper expertise
-
Broader orchestration
-
Higher trust
-
Expanded decision authority
-
Proven ability to develop others
A person could become more economically valuable without accumulating direct reports.
AI makes this redesign urgent.
If small teams can produce more, managerial status cannot continue depending primarily on team size.
The future expert may oversee fewer people while governing far greater productive capability.
Titles Create Status Hierarchies That Distort Collaboration
Roles are not neutral labels.
They carry status.
Senior titles receive attention.
Junior titles are expected to defer.
Certain functions dominate decisions.
Others are treated as support.
This can distort execution.
A junior employee may possess the most relevant knowledge but hesitate to challenge a senior leader.
A specialist may identify a critical risk but be excluded because the function is considered peripheral.
An external contributor may be ignored despite having deeper experience.
A famous company name or prestigious title may carry more influence than evidence.
Capability-based execution does not eliminate hierarchy.
Someone must decide.
Accountability must be clear.
But authority should be connected more directly to the decision being made.
The person with relevant capability should have meaningful influence, regardless of where they sit on the org chart.
This is especially important in complex work, where no leader can personally possess all required knowledge.
Roles Encourage Boundary Protection
Once a person is assigned a role, they develop expectations about what is and is not their responsibility.
This protects against overload.
It also creates boundaries around outcomes.
“That is not my job.”
“That belongs to another team.”
“We completed our portion.”
“These requirements were not in scope.”
These statements may be reasonable.
But customers and business outcomes rarely care about role boundaries.
The work must still be completed.
When every person protects their role, the gaps become organizational debt.
High-performing environments often contain people willing to cross boundaries temporarily.
But relying on personal heroism is not sustainable.
The better solution is to organize around the outcome and make the required capabilities explicit.
Then contributors can understand where their responsibility begins, where it ends, and how the pieces connect.
The role remains useful.
It no longer becomes a wall.
Capability-Based Work Is Not the Same as Treating People Like Components
There is a danger in capability language.
Organizations may begin describing people as collections of skills that can be plugged into work like software modules.
This would be a mistake.
People are not APIs.
They have aspirations.
Relationships.
Identity.
Energy.
Health.
Values.
Learning needs.
Economic obligations.
A person’s contribution cannot be understood only through tasks delivered.
The role model is flawed, but it provides certain human benefits:
-
Belonging
-
Stability
-
Community
-
Recognition
-
Development
-
A coherent professional identity
A capability-based system must preserve and improve these benefits.
Otherwise, it becomes another mechanism for extracting flexible labor while transferring risk to individuals.
The goal is not to make people interchangeable.
It is to see them more completely.
A title compresses a person.
A capability record can reveal:
-
What they know
-
What they have delivered
-
How they work
-
What they want to learn
-
Which environments help them succeed
-
Which responsibilities they are trusted to hold
-
How their capability is evolving
That is more human than reducing someone to a job title and years of experience.
But only if the system gives the person agency over how they are represented and deployed.
Capability Must Be Demonstrated, Not Merely Claimed
A capability-based economy will require evidence.
Otherwise, titles are simply replaced with self-declared skill lists.
Evidence can include:
-
Verified outcomes
-
Work samples
-
Technical assessments
-
Customer feedback
-
Peer validation
-
Repeated delivery history
-
Certifications where relevant
-
Observed decisions
-
Contributions to shared assets
-
Performance under real constraints
But evidence must be interpreted carefully.
A successful outcome may result from a strong team, favorable timing, or substantial organizational support.
A failed outcome may occur despite excellent individual work.
Capability verification should not become simplistic scoring.
The goal is to improve signal.
Not create an algorithmic caste system.
A mature system should distinguish between:
-
Participation
-
Contribution
-
Ownership
-
Review
-
Decision authority
-
Verified completion
It should also allow people to demonstrate emerging capability rather than being permanently trapped by past work.
Organizations Need Capability Maps, Not Just Org Charts
Most leaders know how many employees they have.
They may not know what the organization can actually do.
A capability map should answer:
-
Which capabilities are essential to strategy?
-
Where do they currently reside?
-
How deep are they?
-
Which depend on one person?
-
Which are available only through vendors?
-
Which are becoming obsolete?
-
Which are emerging?
-
Which can be supported by AI?
-
Which require stronger governance?
-
Where do critical gaps delay outcomes?
This is more valuable than simply knowing departmental headcount.
A company may have 200 engineers and still lack the capability to modernize a particular legacy platform.
It may have a large marketing department but no one capable of category creation.
It may have a transformation office but insufficient change-management capability.
It may have numerous AI pilots but no reliable model-evaluation capability.
Capability maps reveal the difference between organizational size and execution readiness.
Capability Planning Changes the Hiring Question
Traditional workforce planning asks:
How many people do we need?
Capability planning asks:
What must we be able to do?
That leads to a richer set of choices.
Should the capability be:
-
Developed internally?
-
Hired permanently?
-
Accessed through a specialist?
-
Provided by a partner?
-
Automated?
-
Shared across teams?
-
Embedded in a platform?
-
Assembled temporarily around an outcome?
The answer depends on several factors.
Strategic importance
Does the capability define competitive advantage or carry enduring accountability?
Frequency
Is it continuously required or episodic?
Scarcity
How difficult is it to access?
Context dependency
How deeply must the contributor understand the organization?
Risk
Does the work involve sensitive decisions, data, or consequences?
Rate of change
Will the capability remain relevant?
Verifiability
Can the outcome be clearly evaluated?
This framework produces better decisions than automatically opening another requisition.
The Future Team Will Be Composed, Not Merely Staffed
Staffing begins with positions.
Composition begins with outcomes.
Suppose the objective is:
Introduce an AI-assisted claims process while reducing processing time and maintaining regulatory compliance.
A staffing approach may request:
-
Two AI engineers
-
One business analyst
-
One project manager
-
One QA engineer
A capability composition approach asks:
-
Who understands claims operations?
-
Who owns the business outcome?
-
Who understands the regulatory constraints?
-
Who can redesign the workflow?
-
Which AI capability is appropriate?
-
Who can integrate the systems?
-
Who validates model behavior?
-
Who handles exception design?
-
Who ensures operational adoption?
-
Which capabilities are needed continuously?
-
Which are needed only at specific stages?
The resulting team may contain fewer people.
Or more.
But each contributor has a clearer reason to exist.
The unit is not filled because a template says every project needs those roles.
The execution system is composed because the outcome requires those capabilities.
Capability Composition Reduces Handoffs
Role-based work tends to pass through functions.
Business analysis defines.
Design designs.
Engineering builds.
Quality assurance tests.
Security reviews.
Operations deploys.
Training prepares users.
Each function may perform well.
The outcome still suffers from translation loss.
Capability composition can bring the necessary perspectives together earlier.
Security does not arrive at the end.
Operations does not discover the system during deployment.
Users are not asked for feedback after development.
The team forms around the complete outcome.
This does not eliminate specialization.
It reduces sequential isolation.
Capabilities interact while the work is still shapeable.
That improves both speed and quality.
Capability Must Include Authority
Organizations often assemble the right expertise but still fail because nobody can make decisions.
A group may contain strong capabilities but remain dependent on senior approvals outside the team.
This is why capability cannot be defined only as expertise.
Execution capability includes:
-
Knowledge
-
Skill
-
Tools
-
Access
-
Decision rights
-
Accountability
A team without authority can advise.
It cannot fully execute.
The outcome owner must have a clear mandate.
Contributors must know which decisions they can make.
Escalations should be defined.
Governance should establish boundaries before work begins.
Otherwise, the organization possesses capability in theory but cannot activate it.
Capability Must Include Verification
A person may produce an output.
That does not prove the outcome is correct.
AI makes this distinction more important.
Generated code may compile but remain insecure.
A report may be polished but contain flawed reasoning.
A workflow may operate but produce unfair results.
A design may look attractive but fail accessibility requirements.
Capability composition must include the ability to verify.
This may require:
-
Peer review
-
Automated testing
-
Domain validation
-
Customer acceptance
-
Security controls
-
Independent audit
-
Performance evidence
The organization should not ask only:
“Who can do this?”
It should ask:
“Who can prove that it has been done correctly?”
Execution without verification is activity.
Virtual Delivery Centers Are Capability Containers
A Virtual Delivery Center is often misunderstood as a virtual office or remote team.
Its deeper value is that it provides a governed environment in which capabilities can be assembled around ongoing work.
The VDC can include:
-
Core internal leaders
-
External specialists
-
Delivery teams
-
AI agents
-
SaaS tools
-
Customer systems
-
Governance rules
-
Financial controls
-
Verification mechanisms
It does not need to preserve one fixed team forever.
The composition can change as outcomes change.
A security specialist may join for a critical phase.
A domain expert may contribute intermittently.
An AI agent may automate a repeatable workflow.
An internal product owner may remain throughout.
The VDC provides continuity around changing capability.
This distinction matters.
The traditional organization creates continuity by keeping the people fixed.
A VDC can create continuity through governance, context, systems, and outcome ownership while allowing the capability mix to evolve.
From Résumé Matching to Outcome Matching
Most talent systems match people to jobs.
A future execution system should match capabilities to outcomes.
That requires understanding both sides more deeply.
The outcome must be decomposed into:
-
Required knowledge
-
Production skills
-
Judgment
-
Domain context
-
Decision authority
-
Collaboration needs
-
Risk level
-
Duration
-
Verification criteria
The contributor must be understood through:
-
Demonstrated capability
-
Delivery history
-
Contextual experience
-
Collaboration patterns
-
Availability
-
Learning goals
-
Trust and permissions
-
Human-agent leverage
The match becomes more precise than:
“Has this person previously held the same title?”
This could make opportunity more accessible.
A person without a prestigious title may demonstrate relevant capability.
Someone from a different geography or industry may be considered because evidence matters more than pedigree.
A professional may contribute to work that uses only part of their capability rather than waiting for a full-time role that matches their entire profile.
But this promise depends on good governance.
Poorly designed matching systems can reproduce bias under a technical appearance.
Human review, transparency, and the ability to challenge decisions remain essential.
Capability Portability Could Change Economic Opportunity
Today, much professional reputation remains trapped inside employers.
A company knows that an employee is valuable.
The external market sees only their title and résumé.
When they leave, they must reconstruct credibility through interviews and references.
A capability-based system could make verified contribution more portable.
A person might carry:
-
Outcomes delivered
-
Roles played in those outcomes
-
Skills demonstrated
-
Reviews completed
-
Decisions trusted
-
Systems operated
-
Collaborators who validate the work
-
Learning and certification
-
AI workflows they can govern
This could reduce dependence on elite institutions and employer brands.
It could also allow people to work across multiple execution environments without starting from zero each time.
The person’s economic identity becomes larger than one job.
This is potentially liberating.
It is also sensitive.
Who owns the data?
Who can see it?
Can a poor outcome permanently damage someone?
How are contextual factors represented?
Can people correct inaccurate records?
Capability portability must be designed around dignity and consent.
The Role Will Not Disappear
Roles will remain useful.
Organizations still need employment contracts, reporting relationships, compensation systems, and clear responsibility.
People benefit from professional identities.
Customers appreciate knowing who they are dealing with.
The argument is not that every title should be eliminated.
It is that the role should no longer be treated as the fundamental unit of execution.
A person may have a role inside the permanent organization.
They may contribute different capabilities across multiple outcomes.
Their role provides continuity.
Their capability portfolio provides precision.
The org chart shows the stable structure.
The execution graph shows the active work.
The two can coexist.
What Leaders Should Do Now
Stop translating every problem into a role
Before opening a requisition, define the outcome and decompose the capabilities it requires.
Audit capability, not just headcount
Knowing that a department has thirty people does not tell you whether it can deliver the next priority.
Replace inflated job descriptions with capability choices
When a role contains several unrelated expert requirements, consider composing the capability rather than searching for an impossible candidate.
Make contribution evidence visible
Track outcomes, decisions, reviews, and verified delivery—not only titles and tenure.
Build expert career paths
Allow people to increase impact and compensation without accumulating management layers.
Include AI in capability planning
Assess which tasks can be accelerated, which judgments remain human, and which verification capabilities become more important.
Give outcome teams authority
Expertise without decision rights does not create execution capability.
Protect human agency
Use capability systems to expand opportunity, not to reduce people to scores or interchangeable units.
The Real Question Is Not “What Is Your Role?”
The more important questions are:
What can you help make true?
What problems have you solved?
Under what conditions?
What judgment can you be trusted to exercise?
Which tools and agents can you operate responsibly?
Where do you need support?
What are you learning?
What evidence demonstrates your capability?
These questions see more of the person.
They also create a clearer connection between people and outcomes.
The role tells the organization where someone sits.
Capability tells the organization what becomes possible because they are there.
Work Needs Capabilities, Not Boxes
The role was an effective answer to an earlier problem.
It helped organizations acquire, organize, and administer human effort at scale.
But the world of work is becoming more dynamic, cross-functional, automated, and episodic.
Outcomes increasingly require combinations that no single role contains.
AI is separating tasks from jobs.
Specialists are needed intermittently.
Teams form across organizational boundaries.
Titles reveal less about productive capacity.
The old model responds by creating more roles, longer job descriptions, larger teams, and more complicated coordination.
The better response is to begin with reality.
Work arrives as an outcome.
The outcome requires capabilities.
Those capabilities may exist in employees, specialists, teams, partners, software, AI agents, or combinations of them.
The organization’s task is to compose them, govern them, and verify the result.
This does not diminish the human being.
It can free people from being trapped inside narrow labels that fail to represent what they can contribute.
It can open opportunity to those whose capability is stronger than their pedigree.
It can give experts meaningful careers without forcing them into management.
It can allow organizations to access what they need without pretending every temporary requirement is a permanent job.
It can create a more honest relationship between work and workforce.
Roles will remain.
But we should stop confusing them with reality.
The title is an administrative convenience.
The résumé is an imperfect history.
The org chart is a static map.
The outcome is real.
The capability required to produce it is real.
Everything else is a container.
Roles are fiction.
Capabilities are real.