From Job Responsibility Analysis to Role Handbooks: Helping Contributors Understand Their Work

Someone is willing to contribute to a business activity. How do they get started?

If we only say, “You handle the requirements” or “Help us with the content,” practical questions soon follow. Who should they speak to? Which materials can they use? What needs to be ready before they hand the work over? Who decides when people disagree?

The same thing happens inside a company. Job responsibilities are documented and processes are mapped, yet when someone new takes over, the previous person still has to explain everything repeatedly.

I think a handbook should make clear how to carry out the work once a responsibility has been accepted. Contributors need to know what they can contribute, what conditions they need, and how their work connects with other people's work.

1. Start with the result this work needs to support

Before writing a handbook, choose a real business activity and identify the result it currently needs.

For example, a company is preparing a business overview. What it needs first may be a confirmed requirements brief that enables writing and design to begin. It should also be clear which customers the material serves, where it will be used, and what it should help customers understand.

Starting with “Who has time right now?” can turn a temporary arrangement into a lasting responsibility. Working only from existing job titles can also leave out work the business genuinely needs but no one currently handles.

The earlier research document, Methodology for Mapping and Designing Standard Operating Procedures (SOPs), already connected business processes, job tasks, specific actions, standards and handovers. It also called for trials before further improvement. We can develop that approach by first identifying the result needed, then checking how existing work supports it. Effective divisions of work can stay. Overlapping responsibilities, missing handovers and inadequate conditions need another discussion.[1]

Two levels of results need to stay distinct. A confirmed requirements brief is a work deliverable. Whether it makes the material clearer or helps customers make decisions must still be observed in later business activity. A complete handbook and an on-time task do not, by themselves, establish that business outcomes have improved.

2. Be clear about the role, the person and this particular task

Job analysis provides a starting point for understanding the work. For collaboration across teams and organizations, contributions that can be undertaken relatively independently also need to be defined as roles.

Here, a value contribution role is an agreement about a type of contribution and the responsibilities attached to it. For example, a “requirements documentation contributor” may gather and check requirements and prepare a requirements confirmation sheet for later use. An employee or an external professional partner could undertake this role when the conditions are suitable.

One person can hold several roles, and several people can share a role. Each task still needs named people to undertake the work, collaborate and review it for acceptance. Writing “the requirements role is responsible” is not enough. Where several people share the work, their individual scope also needs to be clear so that everyone does not assume someone else has handled it.

Resource, operations and management, customer, and capital ecosystems are four perspectives on participation relationships. Work arrangements should not mechanically assign a separate set of roles to each ecosystem. All kinds of participants can offer contributions proactively or respond to specific needs. A lean operations and management team handles the relevant decisions and rules, and coordinates value production, sales channels and customer relationships. Who can decide a particular matter must still be specified according to the authority actually granted.

A handbook corresponds to a value contribution role that someone actually undertakes. Customers, in their capacity as buyers or users, participate through purchasing, use, feedback and after-sales processes. Those participating solely as investors follow the relevant investment and information communication processes. Neither status, on its own, requires a handbook for collaborative work. If they separately take on product co-creation, professional research or another defined contribution role, they use the handbook for that role.[2]

Scroll sideways to explore, or open the full diagram.

Open full diagram ↗Download editable SVG ↓

3. A handbook should help people answer eight questions

A responsibility statement can explain what someone undertakes. The handbook also needs to explain how to start, handle and complete the work.

These eight questions can serve as a checklist for the first version. Adjust the length to the complexity of the work. There is no need to create material just to fill a contents page.

Describe responsibilities so that others can see what is actually done. “Responsible for requirements management” is still too broad. It can be made more specific: “Check the production purpose, use context and content scope; prepare a requirements confirmation sheet; identify sources and matters awaiting confirmation.”

Standards should relate to the work as well. If facts need to be checked, say which statements require sources and which gaps prevent progress. Do not replace requirements with phrases such as “be responsible” or “work promptly and efficiently.” For exploratory work, leave room to choose methods. Specify the questions to answer, the evidence required and the points for discussion without fixing every step in advance.

SOPs and role handbooks can refer to one another. The handbook starts from a role and tells me which process to use in which circumstances. An SOP starts from a piece of work and explains the roles, steps and standards involved. Maintain one current, applicable version of a shared process and link to it from the handbook. That reduces the chance of copied versions changing independently in different places.

4. Build the content from real work, then ask someone else to try it

The first version can start with a task that has already been carried out or is about to begin.

Ask the person who actually does the work to explain where it comes from, which materials they look at first, which judgments rely on experience, whom they usually ask to check things, and what they finally hand over to whom. Then ask the upstream and downstream participants to check it as well. This often reveals whether work the contributor considers finished is really usable by the next person.

When documenting it, distinguish three states: practices already checked, arrangements proposed for trial, and questions still awaiting a decision. A longstanding practice is not necessarily a sound standard. A promising new approach also needs to be used before it can be assessed.

Next, choose a collaborator who has the basic capability but is unfamiliar with the work, and ask them to use the handbook on a task with a manageable scope. Someone can guide them the first time. Record where they stop, what needs extra explanation and which inputs they cannot obtain at all.

When these problems arise, first check the handbook and the conditions for doing the work. Are the instructions unclear, or does the task exceed the person's capability? Is something missing from the process, or are authority, materials and time unavailable? Establish what is happening before deciding whether to add training, change the division of work, adjust the conditions or revise the handbook.

If the work remains highly uncertain, begin with a short role description and a task sheet, recording what happens as you go. Forcing it into fixed steps too early can lead people to keep working from assumptions that no longer hold.

5. Try a draft for a requirements documentation contributor

The following is a hypothetical example involving production of a company's business overview. It illustrates how to use the method and does not describe results already achieved by a particular project.

Role purpose: Organize the production requirements sufficiently for writers and designers to judge how to proceed, reducing repeated guesswork about the use context, content scope and business facts.

Conditions for starting: The project lead has clarified the production purpose, intended audience and broad scope; supplied existing materials that may be used; and identified who can confirm the business facts. The deadline, time available and acceptance reviewer are agreed separately for this task.

Main work: First check who will read the material, where it will be used, and what they should understand or do. Then organize the business content and presentation requirements, check sources for key statements, and list disagreements and gaps for confirmation by someone with the relevant authority.

Deliverable: A requirements confirmation sheet covering, at a minimum, the use context, audience, content scope, key business facts and sources, delivery specifications, confirmed matters, matters awaiting confirmation and the people responsible for them. Record the specific deadline, confirmation status and applicable version with the task.

Authority and collaboration: The contributor can ask questions, organize materials and suggest ways to present the content. Matters such as business scope, product commitments, prices and publication timing are confirmed by people with the relevant authority. Putting an undecided matter into a document does not turn it into a company commitment.

Acceptance and receipt: The acceptance reviewer checks facts and scope. The writing and design roles check whether they have what they need to begin. If a gap affects only part of the content, identify which confirmed parts can proceed first. A gap affecting the overall direction needs to be filled or resolved through a new decision first. “The file has been submitted” cannot replace a judgment about how usable it is.

Handling exceptions: When materials contradict one another, the use context changes or new requirements exceed the scope, record the issue and its impact. Ask the relevant responsible person to decide whether to add information, adjust, pause or cancel. A new scope and deadline need confirmation. The contributor can also propose improvements proactively, but carrying them out requires the relevant authority and conditions.

Completion and handover: Save the final confirmation sheet and necessary supporting material. Explain outstanding matters, limitations and the version to downstream participants. If someone else takes over, hand over unfinished tasks, file locations and access arrangements.

The participant then has more than a request to “help organize requirements.” They can judge whether they have the conditions to undertake the task and know how to move it forward once they begin.

6. Keep a way to adjust once the handbook is in use

At the start, both sides confirm the scope, conditions, deadline and acceptance arrangements. During execution, use the applicable version and raise gaps promptly. At the end, check the delivery and downstream receipt, then report problems with the handbook itself to its maintainer.

For items that do not pass acceptance, explain what needs to be added or reworked, and review them again after that work is complete. Disagreements go to the responsible person or review role agreed in advance. Paused matters remain pending; reconfirm conditions before continuing. Cancelled matters end after the necessary closing work. In a small team, one person may hold several roles, but important commitments and matters involving conflicts of interest still need review under the actual rules.

Revisions also need a basis. A one-off special arrangement can first be recorded as an exception. If similar problems recur or business conditions change, decide whether the general practice should be revised. The new version should say what changed, where it applies and when it takes effect. Explain how unfinished tasks transition between versions, and keep earlier versions for reference.

Scroll sideways to explore, or open the full diagram.

Open full diagram ↗Download editable SVG ↓

To judge whether the handbook helps, start with a few practical questions. Do new contributors have a clearer idea of where to begin? Are key problems found earlier? Is there less explanation and rework? Can downstream participants accept the work more easily? Before and after a trial, record the scope, complexity and participants' experience for comparable tasks where possible. Simpler tasks and more experienced people can also affect the result; not every improvement can be attributed to the handbook.

The handbook can specify the evidence to retain for deliveries and contribution records. Pay, expenses, rights and interests, and the conditions attached to them are confirmed separately under the contracts and rules for the actual business. They do not follow automatically from completing a task in the handbook.[2]

AI can help find applicable content, organize existing materials, draft confirmation sheets and identify omissions using the handbook. It must still be clear who checks the facts, which matters can be decided and who receives the result. Turning reusable steps into a Skill—a reusable guide for AI-assisted work—also requires a defined scope, inputs and outputs, and boundaries for human judgment.

Choose one role that currently needs repeated explanation. Use a real task to set out its purpose, conditions, work, authority and deliverables. Let the next suitable contributor try it, then revise it around the problems they encounter. That gives the handbook a practical starting point.

Basis and further reading

[1] Early research material, Methodology for Mapping and Designing Standard Operating Procedures (《SOP梳理设计方法论》, in Chinese). The main references are the relationship between job responsibilities and handbooks on pages 3–4, and documentation, job research, trials and iteration on pages 6–9. The document retains its 2023 version and collaboration records. The ecosystem contribution roles, the distinction between roles and tasks, and the trial suggestions in this article develop those materials further. Two historical diagrams of responsibilities and processes were used only to identify the original relationships; their performance assessment and rights arrangements have not been carried over.

[2] Four-Ecosystem Governance Model: Contributions, Rights and Interests, and the Collaboration Cycle (in Chinese) discusses participation relationships, contributions, rights and interests, and authority over specific matters. This article examines how role handbooks organize work, without assuming a uniform allocation method.

For further reading, Ten Steps for Enterprise Planning: Connecting Direction, Resources and Execution (in Chinese) discusses business objectives and collaboration conditions. What Can a Business Retain After a Transaction? (in Chinese) considers how experience can be used in later work.

This article proposes a method for testing in practice. It does not provide evidence of its effectiveness across different companies. The diagrams and hypothetical example explain the mechanism.