Vertical and horizontal work: the distinction planning tools miss

Ask a planning tool to represent "build the new checkout" and "get the new checkout through security review" and it will offer you the same object for both. An epic, a project, a parent ticket — one shape, two very different kinds of work.

That collapse is convenient for the tool and expensive for the plan, because the two kinds of work consume capacity differently, fail differently, and need different questions asked of them.

The two shapes

Vertical work is a delivery stream owned by a single team or discipline that produces end-to-end value inside its own lane. Frontend, backend, data, mobile, platform, DevOps. A vertical runs in parallel with other verticals and has its own cadence. Its capacity profile is continuous: it occupies some fraction of a team for some number of weeks.

Horizontal work is a cross-cutting concern that pulses into several verticals at specific gates. Security review, legal, compliance, design, accessibility, internationalisation, privacy. A horizontal is rarely a standalone deliverable. Its function is to gate other people's progress, and its capacity profile is bursty: nothing, nothing, nothing, then a hard demand on a small specialist group, usually at the point where several verticals arrive at the same gate in the same week.

Why the distinction changes the plan

Four things behave differently once you stop treating both as epics.

Capacity planning. A vertical can be planned as a rate — this team, this fraction, these months. A horizontal cannot, because its load is driven by other people's schedules. If four verticals plan to reach a security gate in the same fortnight, the security group's month is decided by four plans none of which mention it. This is the single most common cause of a "surprise" bottleneck, and it is fully predictable in advance if the horizontals are modelled as horizontals.

Dependency tracking. Vertical-to-vertical dependencies are usually one-to-one and visible: backend needs the schema before frontend can finish. Horizontal dependencies are one-to-many and invisible, because each vertical experiences its own instance of the dependency and nobody sees the aggregate. Asking "what does this demand need from elsewhere" per demand is necessary but not sufficient; someone has to look down the column.

Risk. A vertical slipping delays a lane. A horizontal slipping delays every lane it gates, and it does so late, because gates sit near the end. This asymmetry means horizontal risk deserves to be surfaced earlier and weighted harder than its size suggests.

Reporting. Verticals report progress — how far along the lane is. Horizontals report coverage — which of the things that need review have been reviewed. Reporting a horizontal as "60% complete" is close to meaningless; reporting it as "9 of 15 demands have cleared privacy" is actionable.

The failure mode this produces

When both are epics, an entirely typical quarter looks like this. Every lane reports green through week eight, because within each lane things genuinely are green. In week nine the first vertical arrives at the security gate and discovers a two-week queue. In week ten the second arrives and the queue is three weeks. By week eleven the programme is late and the retrospective concludes that "security was a bottleneck".

Security was not a bottleneck. Security was a two-person group whose quarter was allocated by four teams who never told them, using a planning model that had no way to express the thing that was about to happen.

What to do about it without buying anything

You can get most of the value with a habit rather than a tool.

• When a demand is planned, ask explicitly: what does this need from a cross-cutting group, and at roughly which week? Not "are there dependencies" — that question gets a no. Name the usual suspects: security, legal, privacy, design, accessibility, data protection, procurement.
• Keep one view per horizontal group across all demands, and read it as a calendar rather than a list. You are looking for clustering, not volume.
• Give the horizontal groups a veto on the timing of gates, not on the work. They are the only people who can see their own aggregate load, and currently nobody asks them until the queue exists.
• Treat an unconfirmed horizontal dependency as a genuine blocker to committing, in the same category as unconfirmed capacity. It is one.

Where DeliverySheet sits on this

Being straight about the boundary: the vertical / horizontal distinction is part of how DeliverySheet models delivery, and it shapes the decomposition model — Initiative → Vertical or Horizontal → Work Package → Task, three levels and no more, because two is a bag of tickets and four is procrastination with a Gantt chart.

What is shipped and in daily use today is the governance half: a demand's Plan stage holds dependencies, decisions, capacity per team and risks, each one able to be honestly marked none known, and a demand cannot be recorded as committed while a high or critical risk is still open unless someone signs an exception. The full component-level execution tree exists in the codebase but is deliberately not the product's front door — DeliverySheet does not yet replace Jira or Linear for day-to-day execution, and I would rather say that here than let you find out after paying.

The distinction is worth adopting whether or not you ever use my product. It costs one extra question at planning time and removes the most reliably surprising failure in delivery.