Your Org Chart Is Not How the Work Happens

To map roles and responsibilities, start from the work instead of the boxes: list every recurring responsibility in the business, put exactly one name next to each line, and let the chart be whatever falls out. A responsibility map is a list of the work with one owner per line. An org chart is a picture of who reports to whom, and it cannot tell you who owns anything.

A COO at a residential cleaning company said it better than we ever have: "Do you also need my org chart? Because I am trying to build things based off our org chart and that is not the way it is built."

She was right, and she had already paid for it: a playbook bloated with three versions of the same process because no single seat owned the real one.

Why does building systems off the org chart fail?

Because an org chart answers a question about authority, and systems are built from the answer to a question about work. Only one of those produces a document somebody can follow on a Tuesday morning.

Take an electrical contractor with around 30 people in the field. The chart is clean: owner, estimators, a controller, a coordinator, a safety officer, superintendents, foremen. Here is the same company in the owner's words: "It is a decent place to work, but it could be aggravating because there is no structure. It is me, me, me."

The chart was not wrong. It was silent. Nobody could say what a good month looked like in the coordinator seat, so when that seat went quiet, projects stalled for years and the owner became, in his phrase, that coordinator's personal assistant.

Charts also move for reasons unrelated to the work: a title invented to recognize somebody, boxes merged the week a person leaves. The recurring work barely changes. Telling a system problem from a people problem needs something more precise than a box.

How to map roles and responsibilities: start from the work, then draw the boxes

The order is fixed: observe the work, name the owners, score the risk, then argue about the chart. When we deliver role-responsibility mapping, it lands alongside the process map and the knowledge risk assessment, because each answers a question the others cannot.

Every document in that table is blind to something, and the org chart is blind to the only thing systemization needs. The responsibility map is also the cheapest of the three, because the raw material already exists once you know what to do with a process map.

List every recurring responsibility, then put one name on each

Build the list in five passes, and expect the first to be slow.

1. Pull the list from the map. Every mapped step that repeats on a schedule or a trigger is a candidate. Job descriptions do not count; they were written to attract applicants.
2. Write each line as a verb. "Purchasing" is a department. "Approves material orders under 2,000 dollars" is a responsibility, and only one of those can be handed to somebody.
3. Put one name in the owner column. Not a department, not two sets of initials with a slash, not "the office."
4. Name the decision, not just the task. Where a line involves a judgment call, write what the right call looks like. Those forks are where documented processes break.
5. Read the list back to the people on it. Their corrections are the deliverable.

That last pass is the one owners skip. On one nonprofit's documentation wave, people in the same department learned mid-session that colleagues ran the same process differently. If two people can honestly claim one line, that line is two responsibilities nobody has separated yet. It is why the practitioner, not the manager, should correct the map, the argument behind who should build your SOPs.

The bucket problem: when a department is really one job title

The clearest failure this exposes is the bucket. That cleaning company had seven office staff behind 900 recurring customers and 85 homes cleaned a day. The chart showed a scheduler, a dispatcher, sales, finance, HR, and an operations manager. The work showed one bucket labeled anyone-who-answers-the-phone, redrawn every few months and unchanged in the building.

Anyone who answers the phone is not a role, it is five roles sharing one desk.

You cannot train a bucket, hire into one, write an SOP for one, or tell whether one is performing. What you get instead is what she got: three versions of one process, and her word for it, cognitive overload.

Breaking a bucket does not require headcount. Sort one week of that group's real work into piles that share a trigger and a skill. Some piles become seats, some become named responsibilities on existing seats. Every pile has to get a name on it, not a person.

What to do with the responsibilities nobody claims

Every unclaimed line is already being done. Just badly, or inconsistently, or by you.

One field services owner covered payables himself for a few weeks after a key employee left, expecting to find it fine. He found 500 to 800 dollars leaking every week through skipped audits, missed part deductions, and overpayments. His math: up to 10,000 dollars a month, just because the process is not followed. A responsibility had lost its owner and nobody noticed.

Every unclaimed responsibility gets a name in the room, or gets deliberately deleted. Clients ask us "what do we delete?" constantly, and the honest answer is this: if nobody will own it and nothing breaks without it, kill the line and record that you killed it. What survives is your queue, which is why deciding what to document first gets easier after this exercise.

How do you know a role is too big?

When one name shows up on the responsibilities that would do the most damage if they stopped tomorrow. Count is not the test. Damage concentration is.

Run the map against a knowledge risk assessment, which asks two questions per line: who holds this, and how replaceable are they. Sort by damage rather than volume, then see whose name repeats at the top.

When one name lands on the responsibilities that would hurt most to lose, you are not looking at a role, you are looking at a single point of failure wearing a title.

Then test your own diagnosis. A role that is too big produces the symptoms of a bad hire: missed follow-ups, no proactive updates, work that stalls until somebody chases it. Owners reach for "right person, wrong seat" and stop there.

Before you conclude wrong person, confirm the seat was ever defined and somebody said out loud what success in it looked like. Adding a layer above an undefined seat, which is what hiring an operations manager usually means, defines nothing.

---

Map the role, then document the role

Documentation built around departments goes stale on somebody else's schedule. That same cleaning company had fused process instructions and software how-tos into one long document, so every time their CRM vendor moved a screen, the whole SOP became suspect. The process had not changed.

Split documentation the way the map splits the work: one owner, one responsibility, one document, with the software clicks in a separate piece. Responsibilities change slowly. Screens change constantly.

The map buys one thing that electrical contractor never had: visibility into whether a role is succeeding. For every responsibility, write one line on what good looks like. That line feeds the review, the 90-day check, and the training plan. It is the map we build at The Systems Effect before anybody writes an SOP.

Redraw it when the work changes, not when the title does

The trigger for updating the map is never the calendar and never a promotion. It is a person leaving or arriving, a tool replacing a manual step, a new location opening, or a process redesigned. A new title on a business card changes nothing about who owns what.

One useful audit is free. An owner we work with planned two weeks away and treated his absence as a measuring instrument. Check the map when you get back: which lines held, which routed to your phone, and which never happened.

Start with one seat this week. Take the role you would least like to lose, write its recurring responsibilities on a page, put one name next to each, and circle every line where only one name is possible. Those circles are your build order.

Frequently Asked Questions

How do you map roles and responsibilities in a small business?

Start from the work, not the chart. List every recurring responsibility as a verb with an object ("approves material orders under 2,000 dollars"), put one name in the owner column, then read the list back to the people on it. The corrections are the point: a first draft only shows how the owner thinks the work is distributed.

What is the difference between an org chart and a responsibility map?

An org chart shows reporting lines, so it answers who you escalate to. A responsibility map shows recurring work with one owner per line, so it answers who is accountable. The chart changes when somebody is promoted; the map changes when work moves. You need both, but only one can be turned into training.

What do you do when two people think they own the same task?

Treat it as evidence that the line is two responsibilities nobody has separated, not a personality conflict. Watch the task run twice, once with each person, and you will usually find different work under one name. Split the line, give each half one owner, and document the handoff.

How many responsibilities should one role hold?

There is no correct count, and chasing one leads to arbitrary reorganizations. The test is damage concentration: sort responsibilities by what it would cost if they stopped tomorrow, then see whose name repeats at the top. A seat holding twenty low-damage lines is fine. A seat holding the company's three highest-damage lines is a single point of failure however short its list.

Should you build SOPs around roles or departments?

Around responsibilities, which roll up to roles. A department-level document has no single owner, so nobody is accountable when it drifts, and it ends up covering process, policy, and software clicks in one file. One owner, one responsibility, one document.