Five views of the same job — map, table, kanban, timeline

The meeting about what the company should run its jobs in usually ends without a decision, and with everyone feeling the others were talking about something else. They were.

The dispatcher wants a map: her question is "who is nearest". Finance wants a table: "what is missing before we invoice March". The manager wants a timeline, because he looks six weeks out. The engineer wants today's list and nothing else. None rules the others out, because none is about the data — each is about how to look at it.

The argument about the tool is an argument about the view#

Nobody in that room disagrees about what a job is: address, customer, date, engineer, status, hours, parts. Ask them separately and the lists come back nearly identical.

The difference sits in the first question each person opens the tool with. Map, table, board, calendar and timeline are five answers to five different questions about the same rows. The trap is that a view comes bundled with the tool: choosing a system means choosing its default view, and everyone else inherits it.

Three truths about one job#

When the company system will not bend to the way a role works, the role builds somewhere else: a whiteboard and a group chat for the dispatcher, a spreadsheet for finance, a slide for the manager before the board meeting. Each updated by hand, each from a different moment.

Two weeks later, "when was that job closed" has three honest answers, and reconciling them takes a phone call — exactly what the service work order workflow is supposed to make unnecessary. Nobody designed it; three sources of truth are the sum of sensible workarounds.

The map#

Answers questions of place: where is it, who can get there soonest, what is on the route. The only view where distance needs no working out.

What it does not show: time. Two jobs at the same address, one at eight and one at four, are a single pin. Nor duration, nor anything without an address: a job waiting on parts, a warranty claim, desk work. Work off the map alone and you see the territory, never the queue.

The map also never complains about missing data. A job whose address was typed loosely into a description field gets no pin, and the map still looks complete. So judge it by whether the pins add up to the day's jobs — which needs the address held as data, the same requirement behind sorting jobs by distance in a field technician's app.

The table#

Answers quantitative questions: how many, how much, what is missing. The only view where rows can be compared, a column added up, and an empty field spotted across dozens of entries.

What it does not show: sequence, and whose move it is. A status is a word in a cell, so finding where work is stuck means reading row by row — and a row below the edge of the screen may as well not exist.

An engineer's list for today is not a sixth view: it is this table with two filters — mine, today — three columns instead of twenty, and a sort by distance borrowed from the map.

The kanban board#

Answers one question better than anything else: whose move is it now. A column where the pile grows is visible before anyone reports it — usually where the company is losing days.

What it does not show: time. A card that has sat in a column two hours looks exactly like one that has sat there three weeks. No due dates, no workload, no sense of effort — a three-hour inspection and a two-day installation are rectangles of the same size.

A board is also only as trustworthy as its column list: a column is a status, and a status two people read differently shows movement that never happened.

The calendar#

Answers questions about capacity: will it fit, who is free on Thursday, does this clash. No other view makes a full day obvious.

What it does not show: anything without a date. The backlog is invisible, so a company run off the calendar alone does what was scheduled and forgets what waits. It hides travel too: two jobs at opposite ends of the county look like comfortable slots an hour apart — which is why the map is its complement, not its rival.

The timeline#

Answers the dependency question: what depends on what, and what moves when one date moves. It earns its place on multi-stage work: an installation, a build, a rollout.

What it does not show: today. Nobody works from a timeline; it answers the manager's question, not the doer's. It also has the highest upkeep of the five, true only while somebody enters every change of date; where that stops paying off is the subject of running projects without a project tool.

The condition: one set of data underneath#

Five views hold together only if they look onto the same records, not five copies. Three things make that true.

One job is one record, with an identifier you can use in conversation and find in every view. If it is also a spreadsheet row, a whiteboard card and a calendar entry, those are three jobs about one breakdown, not three views.

Fields are data, not text. Each view is a function of one field: the map reads the address, the calendar the date, the board the status, the timeline duration and dependency. No field, no view — however many tabs the tool has.

A view is a saved filter, not an export. Change one thing and check the others. If the change is already there, they are views; if it takes a sync, an overnight job or somebody's hand, they are copies — with a delay, and an open question about which one wins.

None of that means one tool for everything: some systems stay for good reasons, so consolidating your tool stack has a floor. The condition is one set of data per job.

Summary#

When the argument starts, check whether anyone is arguing about the data. Usually nobody is. The five views answer five different questions, and somebody asks each one every day. They compete only when each lives in its own tool with its own copy, which turns the choice of view into a choice about whose version of the job is true.

The wider context — organising crews outside the office — is in the guide on managing field teams.