The role-playing chapter established that coordinated work begins when a participant takes on a role. The responsive-loop chapter established what runs while the role is held: observation, evaluation, and action. The composer and orchestrator chapters established the two sides of the input boundary. This chapter describes what the performer does with the role once it has been accepted. A role becomes executable when its work can be understood as tasks.
The Work Inside a Role
A role is not performed by holding its title in mind. A role is performed by attending to the work the role requires.
The input script defines the role. It names what the role is for, what the performer is responsible for, what authority the performer has, what standards apply, and what completion or release looks like. Once the performer accepts the role, those requirements become the work of the role. The performer has to make sense of that work well enough to act.
The work of a role appears as tasks.
A task is a unit of work the role requires the performer to attend to. Some tasks are small: check the breaker, call the supplier, send the report, test the switch. Some tasks are large: run the classroom, coordinate the repair, manage the incident, write the chapter. Some tasks produce a completion. Some tasks remain active while the role is held. The size and surface of the task vary. The architectural role is the same: a task is work the role requires.
Task management is the discipline of keeping those tasks coherent while the role is being performed.
Role Tasks
A role is executed through its role tasks. The role tasks are the full body of work the role requires the performer to hold in responsibility while the role is active.
Role tasks may contain a single task. A person asked to pick up coffee on the way over may have one simple task: stop for the coffee and bring it along. The role is small, but the structure is still present. The role has work, and the performer holds that work until it is done.
Role tasks may also contain many tasks. A foreman responsible for repairing a drill press may need to diagnose the failure, source a replacement part, acquire the part, install it, test the repair, keep the shop floor safe, and report anything that exceeds authority. The role tasks are no longer a single item. They are a structured body of work.
Role tasks are not limited to the tasks visible at the moment the role is accepted. Some tasks are present in the input script. Others arrive while the role is held. A request addressed to the role may create a new task. A change in conditions may create a new task. The completion of one task may reveal the next task.
A request does not become a role task merely because it arrived. It becomes a role task only if the role has responsibility for it. The performer evaluates whether the request belongs to the role before adding it to the role tasks.
The structure may be simple enough to fit in a sentence or complex enough to require a written plan. The shape is the same either way. The role defines the work. The role tasks organize it. Tasks and task groups give it structure. Acts carry it into performance.
The performer interprets the role tasks from what the composer authored. The composer is responsible for authoring a role whose tasks can be identified, and the performer is responsible for interpreting those tasks under local conditions.
Ordinary missing details are resolved through judgment. Missing task identity is different. When the performer cannot tell what task the role requires, the task cannot be managed; it must be clarified. At that point, task management stops until the role is clarified.
Tasks and Task Groups
Role tasks are not always flat. Tasks often belong together because they serve the same sub-objective. A set of tasks held together by a shared objective is a task group.
Repairing a drill press is a task group. Inside the group are smaller tasks: diagnose the failure, source the part, acquire the part, install the part, test the repair. Each task contributes to the shared objective of returning the drill press to service.
A task group may contain individual tasks or smaller task groups. The same structure repeats at every level. A large role may contain several task groups. Each group may contain its own tasks and smaller groups. The role tasks are the outer body of work; task groups are the smaller bodies of work inside it.
Standing Tasks
Not all tasks are completed and crossed off. Some tasks remain active while the role is held. These are standing tasks.
A standing task is fulfilled by maintaining held-readiness: the active condition produced when the performer actually attends to the task. Depending on the role, this may require continuous observation, periodic checks, readiness for interruption, or updates to situational awareness.
A standing task is not fulfilled merely by being assigned. A lifeguard watching a pool, a receptionist holding the front desk, and a supervisor maintaining awareness of a shift are all performing standing tasks only while they continue attending to the conditions their roles make relevant.
Held-readiness is not mere presence. A receptionist sitting at the front desk has not maintained held-readiness if voicemail messages sit unnoticed in the queue. If the role requires checking a queue, scanning a room, listening for a call, watching a channel, or remaining interruptible by a request, those acts are part of executing the standing task.
Standing tasks make clear why task management cannot be reduced to checklist completion. Some work is fulfilled by producing a result. Other work is fulfilled by maintaining a condition while the role remains active. When a standing task is performed well, it also creates information: the performer learns what normal looks like, notices what has changed, and recognizes when the role's instructions no longer match the conditions the role is encountering cleanly.
Non-Standing Tasks
Other tasks are non-standing tasks. A non-standing task is performed toward a bounded result. It may be completed, paused, resumed, blocked, assigned outward, or escalated.
Checking a breaker is a simple non-standing task. The breaker is checked, the result is known, and the task is complete.
Repairing a drill press is a larger non-standing task. It may require diagnosis, sourcing, acquisition, installation, testing, safety attention, and status reporting before the repair reaches completion.
Writing an article is also a non-standing task. It may take hours, days, or weeks. The performer may gather notes, shape an argument, draft sections, revise passages, check coherence, and prepare the article for delivery. The task is larger than a single act, but it still has a bounded result: an article that meets the role's standard.
A non-standing task may be broken into subtasks when the task is too large to carry as one stretch of attention. The performer may choose that structure within the latitude the role grants. Breaking a task into subtasks does not change the larger task's identity. It gives the performer a workable structure for moving the task toward completion.
Non-standing tasks are the form most people first recognize as tasks. They have a before and after. They move the role toward a result.
Ordered and Independent Work
Non-standing tasks relate to one another in different ways.
Some tasks are ordered. A task is ordered when it depends on another task, condition, or decision before it can be performed. The repair cannot be tested before the part is installed. The part cannot be installed before it is acquired. The part cannot be acquired before it is identified. Order is not decorative. Order comes from dependency.
Some tasks are independent. A task is independent when it can proceed without waiting on another task in the same set. Independent tasks do not require a fixed order. A single performer may choose their order. Multiple performers may carry them in parallel when the role permits delegation.
Ordered and independent are relationships, not permanent identities. A task may be ordered relative to one task and independent relative to another. A task group may be ordered internally while independent externally.
The drill press repair is ordered internally: diagnosis before sourcing, sourcing before acquisition, acquisition before installation, installation before testing. But from the larger shop's perspective, the whole repair group may proceed independently while other work continues elsewhere.
The performer managing the role tasks does not need a formal scheduling method to recognize these relationships. The performer needs to know which tasks depend on others, which can proceed without waiting, and which groups can be treated as units inside the larger role.
Attention and Focus
A role may contain many tasks, but the performer does not actively execute many attention-demanding tasks at the same time.
The performer may keep several tasks in view. The performer may remember what is pending, track what is blocked, switch quickly between tasks, and remain interruptible by standing responsibilities. But active attention has a focus.
A performer may hold many tasks in responsibility, but can actively execute only one non-standing task at a time.
This is the golden rule of task management.
What is often called multitasking is usually rapid switching of attention. The performer leaves one task suspended, turns to another, then returns. Some people switch well. Some roles require constant switching. But switching is not the same as giving full attention to several non-standing tasks at once.
Standing tasks behave differently. A standing task may remain live while non-standing work proceeds. The receptionist may hold the front desk while updating a calendar. The supervisor may maintain shift awareness while answering an email. The foreman may keep safety in view while diagnosing a machine. The standing task remains active through periodic checks, background readiness, and interrupt response. When the standing task requires attention, it re-enters focus.
Direct Execution and Delegation
A task can be executed directly or assigned outward.
Direct execution means the performer gives their own attention to the task and performs it. The task remains inside the performer's own work. A solo technician on a service call, a student completing an assignment alone, a receptionist working a desk without backup, and a writer drafting a chapter are all performing tasks directly when no other participant is brought in.
Delegation means the performer assigns the task to another participant, if the role grants authority to do so and another performer is available. Delegation creates real parallelism because another performer now holds the assigned task.
Parallel work is not produced by pretending one performer has several full attention streams. Parallel work is produced by orchestration across participants.
A role player may delegate because the role tasks contain more work than one attention stream can carry, because a task can proceed independently, because another participant has better skill or position, because time matters, or because the role player must preserve attention for standing responsibilities.
A role player may also choose not to delegate. No helper may be available. The role may not grant authority to assign. The task may require the role player's own judgment or authority. The cost of briefing another participant may exceed the value of assigning the task. The task may be too tightly coupled to the current focus. Delegation is not automatically better. It is one available move when the role, conditions, and task support it.
Task management identifies that a task may need to be assigned outward. The discipline of delegation governs what that assignment must contain.
Blocked, Suspended, and Completed Tasks
Tasks change state while the role is being performed.
A task is ready when it can be acted on now. A task is blocked when something required for action is missing: information, authority, materials, access, a prior task, a decision, or a response from another participant.
A task is suspended when it has been paused while attention goes elsewhere. Suspension is not failure. A blocked task cannot proceed until a missing condition is resolved. A suspended task is not currently being worked, but it may still be capable of proceeding when attention returns to it.
A task is completed when the work it required has been fulfilled according to the role's standard. Completion does not merely mean that effort was spent. Completion means the task has reached the state the role required.
The performer managing role tasks must know, at least well enough for the role, which tasks are ready, which are blocked, which are suspended, and which are complete. This does not require a particular tool. A written checklist, a ticket system, a whiteboard, a calendar, a notebook, a shared plan, or memory may serve, depending on the work. The architectural requirement is not the tool. The requirement is that the performer keeps the role tasks coherent enough to act responsibly.
The Responsive Loop Over Role Tasks
Every role carries the same kind of standing task before any specific work is named: the role must remain active while it is held. Each performer keeps their own role active by maintaining the responsive loop.
The responsive loop runs over the role tasks. Observation notices the state of the work: what exists, what changed, what is ready, what is blocked, what standing task needs attention, and what new event has arrived.
Evaluation determines what the observation means: which task deserves focus, which task must wait, which task can be delegated, which standing responsibility has become urgent, and which ambiguity requires clarification.
Action performs the next move: attending to a task, continuing it, pausing it, completing it, delegating it, reporting status, consulting, escalating, or returning to observation.
In this sense, maintaining the responsive loop is the universal standing task present in every role. Each role player performs it locally for the role they hold. Other tasks may be standing or non-standing, ordered or independent, direct or delegated, ready, blocked, suspended, or complete. But none of them are performed responsibly unless that role remains active. The role tasks give the loop structure; the loop keeps the role tasks alive through time.
Making Sense of the Role
Task management is not the same as personal productivity. It is not a preference for lists, boards, reminders, or schedules. Those may help, but they are not the discipline itself.
The discipline is making the role executable.
The performer receives a role, identifies the role tasks, recognizes standing and non-standing work, distinguishes ordered dependencies from independent work, groups related tasks under shared objectives, keeps track of what is ready or blocked, gives active attention to one focus task at a time, maintains standing tasks through readiness and periodic attention, delegates when conditions support delegation, and escalates when the work cannot responsibly proceed inside the role as authored.
This is how a role becomes work.
The input script defines the role. The performer makes sense of the role by interpreting its role tasks. The responsive loop keeps those tasks active while the role is held. Acts carry the tasks into performance.
A role that cannot be understood as work cannot be performed responsibly. A role whose tasks can be identified, organized, and attended to can be executed under local conditions.