The Analog Incident Story Cargo Port: Designing a Paper Dockyard Where On-Call Workloads Actually Unload

Modern teams are drowning in dashboards, yet still struggle to answer simple questions:

Who is on call, right now, for what?
What’s in progress? What’s stuck?
Where can we safely unload the next critical task?

This is where a nearly-forgotten, analog tool can quietly change the game: T-Cards.

In incident command systems (ICS), T-Cards (ICS 219) are used to track resources in real time: who is where, doing what, and in what status. Think of them as physical Kanban cards for emergencies. Now imagine bringing that same discipline to your on-call and triage workloads by designing a paper “cargo port” where incoming work actually unloads — visibly, predictably, and in line with real capacity.

This post walks through how to design that analog dockyard, how it complements digital tooling, and how to tie it into practical capacity planning (like Sprint planning) so your team doesn’t just handle work — it handles work safely.

Why an Analog Dockyard in a Digital World?

At first, paper systems can sound quaint or backward. But analog tools like T-Cards have distinct advantages under pressure:

Instant visibility
A physical T-Card rack at a central location becomes a live, at-a-glance dashboard of what’s happening: who’s busy, what’s blocked, and what capacity remains.
Low cognitive overhead
No logins, no menus, no modal windows. In the middle of a high-pressure incident or triage storm, you can move a card in under two seconds and everyone can see the change.
Resilience when digital fails
During outages, network blips, or tool overloads, a physical board just keeps working. It’s your “layer zero” operational view.
Shared situational awareness
When everyone literally stands around the same board, they build a shared mental model of the work. This reduces handoff friction, missed context, and duplicated effort.

Analog does not replace digital; it anchors it. Think of the T-Card board as the physical front-end to your on-call and triage model.

Meet the T-Card: Your Analog Container for Work

In ICS, T-Cards track resources (people, vehicles, teams) and their status. For knowledge work, your “resources” are usually people and your “cargo” is work units.

Each T-Card becomes a small, structured story:

Who is this card about?
- A person: "On-call engineer – Backend"
- A role: "Triage lead" or "Incident commander"
- A workstream: "Database triage queue"
What is it doing?
- Free / Available
- Busy / Handling incident
- In handoff / Awaiting review
Where is it?
- On-call board
- Escalations rack
- Recovery / Post-incident

You can also use separate T-Cards for individual pieces of work (e.g., incidents, support tickets, triage tasks) and use racks to show how they move through the system.

The design choice is: do cards primarily represent people/resources, or work/cargo? For a “cargo port” metaphor, it often works best to:

Use one color of T-Card for people/roles (the ships).
Use another color for work items (the containers).

Then your wall becomes a living model of ships docking, loading, unloading, and departing.

Designing Your Paper Dockyard: The Core Layout

Think of your wall or whiteboard as a cargo port diagram. You want to answer two questions instantly:

Where can we safely unload more work?
What’s blocking ships from leaving the port?

Here’s a simple layout you can start with.

1. Arrival Bay: Incoming Work

A column for all new, untriaged items:

Columns:
- New / Untriaged
- Sifted / Needs owner
Cards: Work T-Cards only.
- Quick fields: ID, type (bug/incident/request), severity, time received.

This is your raw intake queue. You should be able to see:

How much is waiting.
How long items have been waiting.

2. Dockside: On-Call & Triage Capacity

This is where your on-call and triage staff live as T-Cards.

Rows or swimlanes for each role:
- Primary on-call
- Secondary on-call
- Triage lead
- Incident commander (if active)
Columns for capacity state:
- Available (can take work)
- At capacity (fully loaded)
- Overloaded (too many open incidents)

Place each person’s T-Card in the column that reflects their current load. Any Available slot is a free dock where cargo can unload.

3. Work Berths: Active Incidents & Tasks

Now give the cargo itself a set of berths:

Columns:
- In triage
- Under investigation
- Fix in progress
- Waiting on external team
- Resolved / Monitoring

Each work T-Card moves left-to-right as the situation evolves. Optionally, associate each work card with a ship card:

Attach the resource T-Card for the current owner next to or underneath the work card.
When ownership changes, you physically move the resource card to the new work berth — making handoffs visible.

4. Departure Lane: Completed & Learning

When work is truly done, it should leave the active port:

Columns:
- Completed this cycle
- Needs post-incident review
- Documented / Lessons captured

This reinforces that the port is for live traffic, not archival history — and surfaces work that still needs learning or follow-up.

Making On-Call Actually Work: Match Cargo to Ships

On-call and triage models often fail not because of the idea, but because of local reality:

Too many conflicting demands on the same people.
Unclear handoffs between teams.
No shared view of who is really available.

Before you change your model, take time to understand local barriers and facilitators:

Barriers:
- Is on-call work constantly interrupted by project work?
- Do some teams ignore the triage process and go straight to their favorite engineer?
- Does leadership expect “hero mode” during incidents without acknowledging capacity limits?
Facilitators:
- Are there already natural “triage hubs” (like a help channel) you can formalize?
- Is there a culture of daily standups or ops reviews where the board can be used?

Use your T-Card board to expose these realities instead of hiding them. When the board shows:

Repeated overloading of the same role.
Work consistently skipping triage.
Incidents piling up with no owner.

…you now have concrete, visible evidence to drive process improvements.

Connecting the Dockyard to Capacity Planning

A visible dockyard is powerful, but it only truly pays off when you connect it to capacity planning for your regular work cycles (Sprints, weeks, rotations).

1. Start with a Simple Capacity Model

For each on-call period or Sprint, estimate:

Total available hours for the team
(e.g., 5 people × 30 focused hours = 150 hours)
Reserved capacity for on-call / triage
(based on historical data: e.g., average of 30 hours per week of interrupts)

That leaves planned capacity for project work.

Example:

150 total hours
30 hours reserved for interrupts
120 hours left for planned Sprint work

Now use your dockyard to validate this assumption in real time.

2. Use the Board as a Living Capacity Instrument

Over a Sprint or rotation, track:

How often are on-call people in the Overloaded column?
How many work cards are stuck in Waiting on external team?
How much time are people pulled off project work to handle unplanned cargo?

After a few cycles, compare what actually happened to your plan:

If on-call lanes are overloaded most days, you underestimated interrupt capacity.
If the board shows idle on-call capacity, you may be over-reserving capacity.

This tight feedback loop helps you adjust your capacity planning numbers with evidence, not guesswork.

3. Turn Visual Evidence into Planning Inputs

Bring the physical board into your planning session:

Take photos of the board over the last week or Sprint to show patterns.
Count how many work items flowed through each lane.
Note how often ships (people) were at capacity or overloaded.

Use that data to answer questions like:

How many on-call shifts do we truly need per week?
Do we need a dedicated triage role during peak hours?
How much buffer should we reserve in the next Sprint for interrupts?

Teams often find that 10–30% more explicit buffer for interrupts makes on-call feel dramatically less chaotic while preserving project velocity.

Practical Tips to Get Started

You don’t need a perfect design to start. Aim for a minimum viable dockyard:

Buy or build a basic T-Card rack
Or use index cards and painter’s tape on a whiteboard.
Define 3–5 simple status columns
For both people and work; you can refine later.
Run it in parallel with your digital tools for 2–4 weeks
Keep your ticketing system as the system of record; the board is your operational front-end.
Review the board daily
Use it in standups or ops reviews to update status, spot overload, and discuss flow.
Adjust based on friction
If nobody moves cards, the design may be too complex. Simplify until the board reflects reality with minimal effort.

Conclusion: Build a Port, Not a Pileup

On-call and triage work are supposed to increase availability and make better use of scarce expertise. In practice, they often become invisible, unbounded streams of stress.

A simple, analog T-Card dockyard gives your team:

A shared, real-time picture of who is doing what.
A physical place where work arrives, docks, gets processed, and departs.
Concrete data to inform capacity planning and on-call design.

In other words: it’s a story cargo port where incidents and interrupts don’t just crash onto the shore — they actually unload, move, and leave.

You don’t need more dashboards. You need a clearer port. Start with paper. Let the work become visible. Then use what you learn to design an on-call model that your team can sustain, not survive.