KanBo Perspective

The Specialist Coordinator

The role that holds cross-functional work together, why it has become harder than it used to be, what breaks when the person doing it is equipped with nothing but an inbox and a spreadsheet, and what the work looks like once coordination lives in the record instead of in one person’s head.

The role nobody put on the org chart

Look for “Specialist Coordinator” in a job architecture and you often will not find it. Look inside any large programme and you will find the person within about ten minutes.

They are the one who knows that the supplier’s revised drawing has not yet been through design review, that the regulatory question raised three weeks ago is still open, that commissioning cannot start until two other departments finish something neither has scheduled, and that if next month’s date moves, four commitments quietly become impossible.

Their formal title varies — programme coordinator, planning coordinator, technical coordinator, project coordinator, operations coordinator, sometimes just “the person who runs it.” The function is constant: responsibility for an outcome produced by specialists they do not manage.

That sentence contains the whole difficulty. Accountability without authority is not a career complaint; it is a structural condition, and it dictates how the job has to be done. A coordinator cannot instruct another department’s engineer. They can only make the situation clear enough that the next step becomes obvious to everyone looking at it.

Mary Parker Follett described this in the 1920s as the law of the situation: the most durable authority is not one person telling another what to do, but both taking their instruction from the facts in front of them. A century later it remains the most accurate account of how cross-functional work actually moves. It also explains why the coordinator’s real product is not a task list. It is shared understanding — and shared understanding, produced by hand, is expensive to make and impossible to store.

This work is not administration. It is the mechanism by which specialized work becomes organizational output. Engineering can be excellent, procurement can be excellent, quality can be excellent, and the programme can still fail, because excellence in the parts does not produce a result unless something holds the sequence together. In most organizations that something is a person, and the organization rarely names what it is depending on.

What coordinators actually do all day

Job descriptions for this role list deliverables — plans, reports, meeting minutes. The actual work is better described as five recurring activities. Recognizing them matters, because three of the five are largely mechanical, and mechanical work is precisely what should not be living inside a skilled person.

Intake and triage. Requests, changes, questions and problems arrive from everywhere: email, chat, corridor, meeting, a supplier portal. Each has to be understood, judged for importance, given an owner and a deadline, and connected to whatever it affects. On most stacks this conversion is manual, and it is manual every single time.

Sequencing. Deciding and maintaining the order in which things must happen, and knowing which orderings are hard constraints rather than preferences. This is the part that requires genuine expertise, and the part that gets the least time.

Chasing. Following up on what has not moved. Almost pure overhead, and the activity most likely to consume an afternoon.

Translating. Rendering one function’s output into another function’s input — explaining to procurement what engineering actually needs, explaining to engineering why the compliance question is not optional. Part expertise, part repetition of things already said.

Evidencing. Being able to show later what was decided, when, by whom and on what basis. Increasingly demanded, almost never resourced, and usually reconstructed after the fact.

Sequencing and translating are why the organization hired a person. Intake, chasing and evidencing are why that person has no time to do them.

Why the job is harder than it was five years ago

Nothing about the role changed. Everything around it did.

More specialists, more interfaces. Organizations have deepened specialization — sustainability, data protection, cyber, regulatory affairs, supplier quality, AI governance. Every added specialism adds interfaces, and interfaces are where coordination is consumed. The number of possible interactions between functions grows far faster than the number of functions. Coordination capacity grows one hire at a time.

More systems, not fewer. ERP, PLM, document management, ticketing, procurement, scheduling, plus whatever a department bought for itself last year. Each holds part of the truth. None holds the state.

Distributed by default. Hybrid and multi-site working removed the informal channel that used to carry perhaps half of all coordination — overhearing, the corridor, the desk visit. Nothing was deliberately put in its place, so the load moved into messages and meetings, which are worse at it.

Faster cycles, less slack. Shorter delivery windows and thinner buffers mean a dependency discovered late is no longer an inconvenience to absorb. It is the schedule.

A rising evidentiary burden. Regulation, audit and customer requirements increasingly ask not only what was done, but what was known, when, and by whom. Coordination now has to leave a record rather than only a result.

AI raising output faster than coordination. Assistants are helping specialists produce more, faster, from more places. More output coordinated by the same means as before does not feel like progress to the person in the middle. It widens the very gap it appears to close.

Each of these is individually manageable. Together they mean the coordination load has grown substantially while the method of handling it has not changed since the arrival of email.

What actually happens on the old stack

Most coordinators are equipped with four tools and a habit. It is worth being precise about what each is really doing, because the failure is structural rather than a matter of discipline. Nobody is doing this badly. They are doing something impossible, carefully.

Email is the work queue. Requests, approvals, changes and questions arrive as messages. A message has no owner, no status, no due date and no relationship to anything else. It has a sender and a timestamp. Turning a message into work — deciding what it is, who owns it, when it is due, what it affects — is a manual act of translation performed dozens of times a day, and the result is stored nowhere except in the coordinator’s head and possibly a reply.

A spreadsheet is the master plan. It is the only place the whole picture exists, which is exactly why it is dangerous. It is a snapshot of what one person believed on the morning they last updated it. It has no live connection to the systems where the work happens. Everyone else is looking at a version they were sent, and the moment it is sent it begins to be wrong. Dependencies inside it, where they exist at all, are expressed as adjacent rows and remembered relationships.

A shared drive is the archive. The documents are there. Which one is current is decided socially: someone remembers, or the filename says FINAL_v3_rev2_approved. Version confusion is the most expensive small problem in this job, because it does not announce itself — work proceeds confidently on the wrong basis until something physical or contractual reveals it.

Chat is where the reasoning went. The most valuable content in the entire stack — why a decision was made, what alternatives were rejected, what condition was attached — sits in a channel. It is unsearchable in practice, invisible to anyone who joined afterwards, and lost entirely when the channel is archived or the person leaves.

Meetings are the synchronization mechanism. A recurring call exists because there is no other way for eight people to arrive at a common picture. Most of its duration is spent establishing facts a system could have supplied. Decisions, when they happen, happen in the last ten minutes.

This is not an unusual setup. It is the default in most large organizations, including sophisticated ones with substantial technology estates. Those systems are excellent at storing things. None of them holds state.

Four failure patterns, named

The old stack produces the same patterns everywhere. Naming them helps, because each has a structural cause rather than a human one.

The spreadsheet of record. The authoritative plan is a file one person maintains and everyone else consumes as an attachment. Cause: no shared structure that can hold sequence and dependency. Symptom: the plan is always slightly out of date, everyone knows it, so people stop trusting it and ask the coordinator directly — which increases the load that created the spreadsheet in the first place.

The shadow status meeting. A recurring meeting whose real purpose is to tell people things they could have read. Cause: status lives in people, not on the work. Symptom: the coordinator’s calendar fills with sessions where they narrate, and the actual coordination happens in the ten minutes afterwards.

The hero coordinator. One person becomes genuinely irreplaceable and the organization quietly reorganizes around that fact. Cause: the record is a person. Symptom: handover takes months and never completes; holidays generate escalations; promoting that person is treated as a risk event.

The handover cliff. When the coordinator changes — promotion, resignation, restructure — the programme loses months. Cause: history, rationale and open questions were never externalized. Symptom: the successor spends a quarter conducting interviews to reconstruct what was already known.

There is a fifth, newer and increasingly expensive: the stalled assistant. An AI pilot is introduced to help with exactly this work and produces confident, context-free output, because purpose, ownership, history, dependencies and constraints were never written down. The model is not the problem. It is being asked to reason about a state of work that exists only informally.

What it costs, and who pays

The coordination gap rarely appears as a budget line, because it is not paid in money first. It is paid in four other currencies.

Coordinator attention. The scarcest input in the system is the judgement of the person who understands the sequence. When that person spends most of the day on intake, chasing and reconstruction, the organization is using a specialist as a router.

Decision latency. Every question that requires asking a person adds hours or days. Individually trivial; in aggregate it is the difference between deciding inside the window and deciding after it.

Rework. Version confusion and late-discovered dependencies produce work done twice. This one does eventually appear in the budget, attributed to the department that did the rework rather than to the coordination failure that caused it.

Continuity risk. An undocumented dependency on individuals. This cost is zero until it is very large, which is why it is almost never managed.

None of this requires inventing a statistic. Any coordinator can estimate their own split across the five activities described earlier, and any programme director can ask what would happen if their best coordinator were unreachable for a fortnight. The answers are usually enough.

What the role needs, specifically

Not another task tracker. Task tracking is not the problem — the tasks are usually clear. What is missing is state: a shared, structured record accurate enough that someone can act on it without asking a colleague first.

Four things have to stop being properties of a person and become properties of the work.

• State. Status, owner, contributors, dates and history carried on the work item itself.
• Dependencies. Recorded as links between items, including across departments, rather than remembered.
• Obstacles. Named, owned objects rather than sentences repeated in meetings.
• Documents and reasoning. Attached to the work in their current version, together with the discussion that produced them.

One constraint governs all four: this has to hold at organization level — governed access, consistent structure, a deployment the security function will accept — while still letting each department shape its own process. A coordination layer adopted by a single team is another silo. This is the point at which most team-level tools stop being candidates.

What the work looks like once that exists

Here is the same day on a coordination platform rather than an inbox. The specifics describe KanBo, but the test to apply to any candidate is the same: does it hold state, or only content?

You start with exceptions, not with a list. Your personal space collects the cards you care about from every space in the organization. You filter for what is blocked, what is overdue, what is due this week, and what the platform has flagged as a conflict between dates and dependencies — a predecessor still incomplete, a child task due after its parent’s deadline, a date range that cannot happen. You are looking at the fifteen things that need you rather than the four hundred that do not.

Nobody asks you for status. Each card carries its own state. Statuses are named in your department’s own vocabulary and each is assigned a type — Information, Not started, In progress, Completed or Cancelled — so a team keeps its own workflow language while progress still aggregates correctly for the programme above. This is the mechanism that makes local vocabulary safe. Without it, custom statuses break reporting, which is why so many organizations end up standardizing words that should never have been standardized.

A date change shows its consequences immediately. Dependencies are real links, and they work across spaces — so a card owned by procurement can be the thing your milestone waits on. When a date moves you see what it breaks before you agree to it, and you can say so with a specific list rather than a feeling.

Obstacles become countable. A blocker is an object with a name, a reason and a responsible owner, and it can be defined once and reused across the organization. Define “waiting on external legal review” once and someone can finally answer how often it occurs and what it holds up. That is the conversation that changes a process, and it is structurally impossible on the old stack, where the same obstacle is a different sentence in a different meeting every week.

Documents are the current version. Files reach cards through a managed connection to the document library the organization already uses, so the file on the card is the file in the library rather than a copy that began diverging the moment it was attached. When a library is moved or renamed, the connection is repaired rather than silently breaking.

Requests arrive as work, not as messages. A space or an individual card can be given its own email address, so a request forwarded from Outlook becomes a structured card with an owner and a due date — and who may create work that way is controlled. Specialists who live in email do not have to change tools in order to be coordinated.

Reasoning stays with the work. Comments, mentions and activity history sit on the card. A question answered in March is still answered in September, and it is answered where the next person will look.

Stakeholders look for themselves. Reader access lets sponsors and adjacent departments see live work without consuming full seats and without you assembling anything.

Three situations, before and after

Abstractions are easy to agree with and hard to act on. These three occur in almost every programme.

A change request arrives from a supplier

Before. It arrives as an email with an attachment. You read it, work out what it affects, forward it to two specialists, note it in the spreadsheet, and hold the fact of its existence in your head until someone responds. If you are away, it does not exist.

After. It arrives at the programme’s intake address and becomes a card with an owner and a due date. You link it to the items it affects. The specialists see it in their own views. The activity history records what was decided and why. Nothing depends on you being at your desk when it lands.

A date slips by two weeks

Before. You hear about it in a meeting or in passing. You open the spreadsheet, trace what you believe is affected, email the people you think are involved, and hope your mental model of the dependencies is complete. Something surfaces later that was not on the list.

After. The dependency links are already recorded, including those crossing into other departments. Conflicts appear as flags rather than as recollection. The conversation starts from a specific list of what breaks, which converts an argument about optimism into a decision about sequence.

A new person joins the programme in month seven

Before. They spend their first weeks interviewing people, reading forwarded email threads, and slowly rebuilding a model of the work that already exists in someone else’s head. Their questions consume the coordinator, who is the only source.

After. They read the spaces. State, ownership, dependencies, open blockers, documents and the reasoning behind past decisions are attached to the work. Their questions are about judgement rather than archaeology — which is also the difference between a handover and a reconstruction.

A practical way to start

Do not roll this out. Take one programme and give it two weeks.

1. Map the real structure. One workspace for the programme; a space per workstream, phase or process — the way the work is actually divided, not the way the org chart is drawn.
2. Name statuses in your language, then set their type. Keep the words your team already uses. Assign each to Information, Not started, In progress, Completed or Cancelled so reporting works without anyone changing vocabulary.
3. Put one name on every card. A Responsible Person is a person, never a team. This step alone surfaces more unowned work than most workshops do.
4. Record the ten dependencies you currently carry in your head. Predecessor and successor links, including the ones that cross into other departments. This is the highest-value hour in the exercise, and the one most often skipped because it feels like documentation rather than progress.
5. Turn your three recurring excuses into named blockers. Whatever you find yourself saying every week in the status meeting. Give each an owner.
6. Connect the document library rather than uploading copies. Point the spaces at the repository the organization already uses.
7. Open an intake address. Give the programme an email address and stop retyping requests.
8. Build three views, not thirty. Kanban for the team, Gantt for you, a timeline for the sponsor — the same cards at three altitudes.
9. Automate the chasing, not the thinking. A space owner can configure rules for the repetitive steps, and can pause a rule without deleting it.
10. Then stop three things. The status-collection email, the master spreadsheet, and the first fifteen minutes of the weekly call. If the record is doing its job, nobody will ask for them back. If they do, you have learned something specific about what is still missing.

Weeks three to eight, if the first two hold: turn the structure that worked into a space template so the next programme starts from it; give sponsors and adjacent departments reader access instead of sending reports; move a second programme in; and only then discuss anything resembling a rollout. Templates are how a working structure becomes organizational practice rather than one coordinator’s private setup.

Working alongside AI

The coordinator is, counter-intuitively, the role with the most to gain from AI assistants and the one currently least able to use them.

The reason is simple. An assistant can only reason about what is written down. The coordinator’s value has always been holding what is not written down: purpose, ownership, history, dependencies, constraints, what has already been tried and rejected. That is exactly the context an assistant needs, and exactly the context that does not exist in retrievable form on the old stack.

Once state lives on the work, that changes. An assistant can summarize a situation across spaces, draft an update from the actual record, flag what looks at risk, or point out that a card has not moved while its successor’s date approaches. What it should not do is decide. The card still shows who is responsible, who must approve and where human confirmation is required, which is the difference between a useful assistant and an unaccountable one.

The sequence matters, and it is the reverse of how most organizations approach it. Write the state down first; introduce the assistant second. An assistant deployed onto an undocumented process produces plausible output nobody can check — worse than no assistant at all, because it consumes the credibility the next attempt will need.

What this does not fix

A tool cannot resolve a problem the organization has not decided.

It will not fix unclear ownership at executive level. If two directors both believe they own a decision, making that visible on a card produces a confrontation rather than a resolution. That is usually an improvement, but it is not a fix, and it should be expected.

It will not fix a plan nobody believes. If dates were set politically rather than physically, recording the dependencies will demonstrate that the plan is impossible. Some organizations want to know this. Not all do, and it is worth understanding which kind you are in before you start.

It will not fix a genuine capacity shortage. Making load visible tells you a team is over-committed. It does not add anyone.

It will not fix a culture where reporting bad news is punished. Visibility mechanisms are gamed in exactly the environments that most need them. If a blocker with a named owner is treated as an accusation rather than a fact, people will stop naming blockers.

Being honest about these boundaries is not a caveat. It is the difference between a change that survives contact with the organization and one quietly abandoned in month four.

How you know it worked

Avoid dashboards for this. Four observable signals tell you more, and none needs a measurement programme.

The status question stops arriving. Count how many times in a week someone asks you where something stands. That number is the most direct measure of whether the record is carrying its weight.

The weekly meeting gets shorter or changes shape. When establishing facts stops being necessary, the remaining time is decisions. If the meeting is the same length and shape, the record is not yet trusted.

Somebody else answers a question about your programme. The first time a colleague answers correctly without asking you, the coordination layer has moved out of your head.

A handover works. The real test, and the one worth waiting for. An absence, a holiday or a new joiner reveals within days whether the record is complete.

What the role becomes

The purpose is not to need fewer coordinators. Organizations that do this well do not reduce the number; they get far more from the ones they have, because judgement replaces retrieval as the content of the job. Time that went to locating the current file, chasing the open question and reconstructing why a decision was made goes instead to sequencing and translating — the two activities that actually required a skilled person.

There is a quieter benefit that matters more than it sounds. A coordinator whose value is being irreplaceable is a risk the organization is carrying: in handovers that never complete, in escalations during holidays, in audits that require reconstruction, in the promotion that never happens because nobody can replace them. A coordinator whose value is that the process runs visibly, without them in the middle of every message, is something the organization can build on — and something the individual can be promoted out of.

Coordination is not overhead. It is the mechanism by which specialized work becomes organizational output. It is worth building deliberately rather than paying for by accident, one person at a time.

FAQ

Is a Specialist Coordinator the same as a project manager?

Related but not identical. A project manager typically owns scope, budget and schedule with some degree of formal authority. A coordinator is defined by the opposite condition: accountability for how work moves across functions, with influence rather than authority over the people producing it. Many people hold both descriptions at once, and the coordination half is usually the one without tooling.

Our teams already use several systems. Why add another?

The existing systems hold documents, messages and tasks. What they do not hold is state across them — what is blocked, what waits on what, what breaks if a date moves. The test is practical rather than architectural: if answering those questions still requires asking a person, the gap is real regardless of how many systems are in place.

Will this create more administration for the coordinator?

It moves administration rather than adding it. Status stops being collected because it is already recorded; documents stop being circulated because they are connected; status, dates, ownership and labels can be changed across many cards at once; email requests arrive as cards instead of as text to retype. The first two weeks cost real effort. After that the question is what you stop doing.

Does every team have to work the same way?

No, and requiring it is the most common way this fails. Each space defines its own statuses, views and structure; the anchor is that every status is assigned one of five types, so progress aggregates correctly whatever the local vocabulary. Teams differ on the surface and stay comparable underneath.

Where does this fit for a large or regulated organization?

KanBo is adopted at organization level, with access governance and deployment decided centrally — including on-premises and hybrid arrangements — and departments shaping their own processes inside that frame. The coordinator is usually the first person to feel the difference, because coordination is the whole of the job rather than a part of it.

Where should we start if we have twenty programmes?

One. Choose the programme with the most cross-departmental dependencies rather than the easiest, because that is where the difference will be visible within two weeks. Turn what works into a template before touching the second.