Work without Jobs and the missing link between skills and work
Work without Jobs proposes looking beyond the job as a whole and brings into view a layer that skill architectures often overlook: the work that needs to be organized.
An organization can build a precise catalog, map skills to roles, and assess thousands of profiles. Yet when a new priority emerges, assignment begins once again with a familiar question: which job should own it?
The capability data exists, but it has no concrete unit of demand to connect with. We know something about people and something about positions. What is missing is a description of the work at enough resolution to bring the two together.
The official description of Work without Jobs, by Ravin Jesuthasan and John W. Boudreau, proposes a “new operating system for work” that deconstructs jobs into their components and reconstructs them in combinations tailored to contributors’ capabilities. MIT Press, Work without Jobs (opens in a new tab).
This is not a comprehensive review of the book. The source available for this article is MIT Press’s editorial description, supplemented by a CIPD guide. The analysis is limited to that public thesis and its application to a work architecture.
Between the skill and the outcome lies demand
A skill describes a capability that can be expressed in different contexts. An outcome states what the organization needs to achieve. Between the two lies work: decisions, activities, constraints, interfaces, and responsibility for consequences.
If we omit that layer, a semantic match may seem sufficient. Someone has “data analysis” and an initiative requires “data analysis.” The assignment still needs to determine which data, for what decision, under what uncertainty, by when, and alongside which other contributions.
Work is not an undifferentiated bag of tasks. A useful unit of work must retain enough context to decide who can contribute and under what conditions.
Decomposing does not mean atomizing
Consider a reimbursement process. A traditional job might combine intake, validation, exception analysis, customer communication, and authorization. Decomposition reveals that these contributions do not all require the same mix of experience or occur with the same frequency.
The organization could automate repetitive validation, concentrate infrequent exceptions in an expert community, and move certain decisions closer to the team that speaks with customers.
The risk lies in taking decomposition too far. If every activity becomes an isolated task, continuity, learning, and accountability for the complete outcome are lost. The smallest unit should not be defined by administrative convenience, but by the meaning it needs to retain.
The CIPD guide defines job design as establishing roles and responsibilities to optimize work processes, create value, and safeguard the quality of work. That perspective introduces an important limit: reconfiguration is not only about increasing efficiency; it must also consider the experience of the people doing the work. CIPD, Job design (opens in a new tab).
Recomposition requires rules, not just a marketplace
Once the units of work have been described, the harder question emerges: how should they be assigned? Skills are one input, not the complete criterion.
The decision may require evidence of proficiency, experience in similar contexts, availability, interest, regulatory requirements, and operational continuity. It must also identify who is accountable for integrating distributed contributions.
Recomposition needs workload limits, priority agreements, development mechanisms, and recognizable accountability for the whole.
What changes in a skill architecture
A skill architecture centered only on roles answers which capabilities a position is expected to have. An architecture connected to work can also answer where a skill is used, in which decisions, at what level of autonomy, and alongside which other contributions.
That changes several applications. Mobility no longer depends only on the distance between two roles and can begin with a bounded assignment. Development focuses on experiences in which the skill must be applied. Planning compares demand for contributions, not only headcount.
Not all work should be separated from the role. Roles provide identity, continuity, belonging, and contractual clarity. The useful question is not whether they should disappear, but which components need to remain grouped and which would benefit from moving differently. The choice among breadth, depth, and integration helps decide which configuration responds to each demand.
A small test before redesigning the organization
Choose an outcome with variable demand and known boundaries. Describe five to ten units of contribution without turning them into microtasks. For each one, record its purpose, evidence of completion, decisions, conditions, risks, and interfaces.
Then compare that demand with the capabilities available. Observe which new assignments become possible and which protections are needed. Do not change jobs or contracts yet.
The test should show whether the added resolution improves assignment or merely creates complexity. It may also reveal that the original problem was not about skills, but about authority, information, or priorities.
This interpretation extends The organizational chart is not a map of the work and When to create a new role and when to redesign an existing one. The organizational chart represents a structure; the role brings contributions together; the work shows what must happen. No layer fully replaces the others.
The most useful promise of working beyond the job is not the elimination of positions. To explore it, the organization must first test a bounded unit of work and determine whether it improves the connection between human capability and demand.
To extend this reading, see Dynamic Capabilities: why a collection of skills does not create organizational capability and Designing the interfaces between teams is also designing capability, which develop complementary dimensions of the problem.
Keep exploring
Generalists, specialists, and hybrid roles: what the architecture should decide
Does the organization need breadth, depth, or integration? Generalist, specialist, and hybrid are possible answers, not identities the architecture should fix permanently.
Not every critical skill is strategic: importance, scarcity, and advantage are not the same
Although importance, scarcity, and advantage are often compressed into the label “critical skill,” each dimension requires different evidence and investment. Separating them changes what must be protected, sourced, or built as a system.
Build, hire, move, partner, or automate: five responses to a capability gap
To choose among building, hiring, moving, partnering, or automating, compare the demand, the time horizon, and the dependencies each response creates.
From a skills gap to a capability gap: individual development is not always what is missing
Before recommending training in response to a gap, compare four possible sources: individual proficiency, team coverage, interfaces, and the operating model.
From headcount to capability: what should change in workforce planning
Staffing decisions require knowing how many people there will be. Capability planning also requires understanding what work they can sustain, under which constraints, and with what coverage.
Leadership is not always management: how to represent cross-functional contribution
Some people change decisions, raise standards, and expand others' capability without managing a team. The architecture needs to represent that contribution without inventing informal authority.