Context
Cool products need a crisp mental model of how work actually moves. Milestone 2 introduced the work chart as the alternative to the org chart, and Milestone 3 gave botseverywhere.ai its look. Milestone 4 goes back to structure and asks four questions:
- What is an org chart for?
- What is a work chart for?
- Why did our first work chart look right but turn out too static?
- What does a better work-chart model look like for BotsEverywhere?
To keep it concrete, I used Pied Piper from the TV show Silicon Valley. I am a big fan of the show: the names and roles are familiar, and the fictional company has enough complexity to stress-test the model without inventing a fake SaaS company from scratch. Pricing and offer packaging are out of scope here. That comes later.
Org chart vs work chart
The org chart: who owns capability and authority?
Board
↓
CEO
↓
Leaders
↓
PeopleThe org chart answers who is accountable, who sets standards, and who has budget and escalation rights. In the Pied Piper example, Richard, Dinesh, Gilfoyle, Jared and Monica define authority, talent, risk and final accountability.
Deloitte's article keeps a hierarchical backbone of capabilities and accountability even while AI flattens coordination in execution. There is no partnership with Deloitte; the article is public research that inspired the idea.
The work chart: what caused work, and how does it move?
What caused work to exist?
↓
What outcome is required?
↓
How does the work move?
↓
Who or what performs it?
↓
What decisions and exceptions exist?
↓
What result occurred?The work chart answers how an outcome gets produced. It is an execution graph, not a second org chart with cooler labels.
What was wrong with our first work chart
The first Pied Piper work chart put five permanent branches under the CEO:
- Build Product
- Acquire Customers
- Customer Support
- Operate Infrastructure
- Close Finance
It looked useful, but it made the work chart read like a replacement org chart: a CEO on top and five standing lanes forever. Those five labels work as standing operating lanes, value-stream-like domains or major business capabilities. They are not automatically workstreams.
A workstream is created around a defined outcome inside a larger body of work:
INITIATIVE
Launch Pied Piper Enterprise
├── Product readiness workstream
├── Infrastructure readiness workstream
├── Go-to-market workstream
├── Legal and compliance workstream
└── Support readiness workstreamThe correction: a work chart should start from work entering the system, not from the CEO branching into permanent workstreams.
Deloitte's sequence is the same idea: map the work, handoffs, bottlenecks, decision rights, telemetry and controls before changing the org chart. Delayering comes after enough workflows have changed, not before.
I am not publishing the first chart. It stays a research artifact, and it is not the product template. A corrected visual, redrawn cleanly, will come in a later pass.
Three layers of the product
1. Intake and intent
Work arrives messy and unstructured: WhatsApp, email, a meeting, a dashboard, a customer, an alert, a management request, a strategy. The first important AI job is to structure the intent, not to invent authority.
Example, in the Pied Piper fiction: "Richard wants Enterprise ready for the Hooli demo next month." It becomes:
| Field | Value |
|---|---|
| Trigger | Management directive / planned initiative |
| Outcome | Pied Piper Enterprise demo-ready |
| Owner | Product + Engineering (accountable human named) |
| Known constraints | Demo date, security review |
| Unknowns | Compliance scope, support runbook |
2. The dynamic work chart
This is the heart of the product: an execution graph selected or constructed for that outcome. Every node carries metadata:
| Metadata | Meaning |
|---|---|
| Executor | Human, bot or system |
| Owner | Accountable human |
| Decision | Yes, no or a threshold |
| Input | Information needed |
| Output | What is produced |
| Exception | Where it goes if something fails |
A sketch for the demo outcome:
OUTCOME
Ship Pied Piper Enterprise demo
│
▼
Check readiness requirements
│
▼
Product / infra / GTM streams (parallel where valid)
│
▼
Decisions and exceptions → accountable humans
│
▼
RESULT → TELEMETRY → continue or escalate3. The governance backbone
The org still wraps the work chart:
| Role | Pied Piper example | Defines |
|---|---|---|
| CEO | Richard | Direction, final accountability |
| Engineering | Dinesh | Build standards, delivery |
| Architecture and security | Gilfoyle | Platform, risk, infrastructure |
| Operations | Jared | Coordination, process |
| Finance | Monica | Budget, close, controls |
AI can remove relay layers in execution. It does not erase governance.
Triggers are part of the design
Work can enter in several ways. These Pied Piper-style examples are illustrative only:
| Trigger type | Example | The system should |
|---|---|---|
| Management directive | "Ship compression for the board demo." | Create or route a temporary work structure |
| Management objective | "Hit X enterprise pilots this quarter." | Decompose it into initiatives and work |
| Problem detected | PiperNet latency spike | Create remediation work |
| Operational request | "Give the contractor deploy access." | Route to an existing workflow or a micro-workflow |
| Incident or exception | Production outage | Activate the incident workflow |
| Recurring event | Monthly close, weekly status | Run a known workflow |
| Planned initiative | Launch Pied Piper Enterprise | Run designed project work |
| External signal | Platform policy change, customer complaint | Trigger an assessment or work |
The intake shape:
WORK INTAKE
│
┌───────────────┬───┼────┬───────────────┐
│ │ │ │
Directive Objective Problem Event
│ │ │ │
└───────────────┴───┬────┴───────────────┘
↓
CLASSIFY WORK
↓
Existing workflow?
/ \
YES NO
│ │
route construct
│ temporary flow
└──────┬────────┘
↓
EXECUTEThe target model
The corrected chart, in text:
ORGANIZATION BACKBONE
Richard / Dinesh / Gilfoyle / Jared / Monica
│
│ governance
▼
WORK INTAKE
Message / Goal / Problem / Event / Project
│
▼
OUTCOME
│
▼
WORK CHART
│
┌──────────────────┼──────────────────┐
│ │ │
Human Agent System
│ │ │
└──────────────────┼──────────────────┘
│
decisions
│
exceptions
│
▼
RESULT
│
▼
TELEMETRY
│
┌───────────┴───────────┐
│ │
normal exception
│ │
continue humanThe core product loop: unstructured work enters, intent is understood, the outcome is defined, an existing or temporary work chart is selected or constructed, humans, bots and systems execute, exceptions route to accountable humans, and telemetry closes the loop.
Only after enough workflows change do you ask whether the org chart itself should change, with role fusion and fewer relay layers, and with explicit governance.
What this means for BotsEverywhere
| Do | Don't |
|---|---|
| Staff seats on dynamic work graphs | Treat the product as a bot directory |
| Start from intake, then outcome, then execution | Draw a CEO over five permanent "work" columns and call it done |
| Keep humans on decisions and exceptions | Invent authority the organization didn't grant |
| Keep the org backbone for accountability | Pretend AI erases hierarchy |
| Ship a corrected work-chart visual later | Publish the first chart as the final template |
The message is unchanged: Bots for Productivity. Leaner & Faster Teams. And the tagline: Org chart for bots. Work chart for humans.
What's next
- Draw Work Chart v2, intake-first, for Pied Piper, as a clean redraw with no third-party marks.
- Map one or two BotsEverywhere seed-team seats onto this model.
- A short post on why our first Pied Piper work chart was wrong and what we learned.